* 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 ||_________________________________________________||
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________