* Tobias Kräntzer <i...@tobias-kraentzer.de> [2017-01-30 23:51]:
> This also applies for other playloads send via a message stanza. If
> such a message does not contain a body element (or maybe an html
> element), it will not end up in the archive.

This is very similar to the struggles I'm having with Carbons currently,
as can be seen in the https://github.com/xsf/xeps/pull/434 discussion.

I think that right now, as we are doing significant changes to 0280
anyway, we should step back and try to get the whole picture. The
current multi-client implementation suggestions consist of:

- MAM for re-synchronization
- Carbons for live synchronization

However, despite following the same goal, MAM and Carbons have vastly
different copying rules. This leads to 'error' messages not being stored
in MAM, or 0184 ACKs not being delivered to all devices.

It was suggested to replace Carbons with a kind of "MAM subscription" in
the past, and such an approach would solve the MAM-vs-offline mess as
well as the MAM race condition mess (that bind2 is tackling as well).

I fear that adding radical changes to the 0280 rules might lead to
breakage in XEPs that I'm not using personally, or to really bad
side-effects (imagine IBB getting CCed). Maybe a namespace bump is not
enough to make authors consider the implications.

> 1. All messages SHOULD be stored, except those containing a 'no-store‘ hint 
> or excluded via the archiving preferences.
> 2. The entire message stanza SHOULD be stored and not only the body element.

I'd love to make the MAM and Carbons rules as easy as possible, but
again, what effect will it have on IBB? Or IoT or other non-IM XEPs?


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to