* Daniel Gultsch <dan...@gultsch.de> [2017-07-13 17:53]: > Maybe we are obsessing a bit too much about hints. Maybe we should > take a step back and think about what we need hints for in the first > place and if we can maybe replace hints with some more well defined > server side rules.
That's a very nice idea indeed! From my pondering, we have the following three use cases: (a) ephemeral message - there is no need to store this message or to deliver it to devices that are not currently online (<no-store/>). It is worth considering whether we could use the same logic to strip/delay ephemeral messages on CSI-inactive sessions. This might affect CSNs, Jingle initiation (maybe? Maybe we also want to have some missed-call logic?), ...? (b) lasting message - the message should be archived, even if it doesn't have a body (<store/>), e.g. 0184 ACKs. (c) single-resource message - the message should not be delivered to another resource than the full JID it's addressed to (<private/> or <no-copy/>, might imply <no-archive/>). This affects OTR, maybe MUC-PMs, ...? I have attempted to write down just the Carbons-related rules in https://github.com/xsf/xeps/pull/434 - and it's a complex mess already. Still, somebody needs to walk through all XEPs that use messages and tick off whether those need to be archived and/or carbon-copied, and only then we can create a comprehensive set of rules. > Fom my perspective hints could go away if MAM learns about OMEMO > messages (Or maybe all messages with an EME tag) and we stop sending > OTR messages. However, that means we need to update the MAM (and Carbons) rules every time there is a new kid on the block. I think we also need to think about a common ruleset for MAM / Carbons, or rather MAM-subscribed-session in this context, and I think that hints provide a better solution than codifying all rules for all message-based XEPs in MAM and in Carbons. IMHO, it would be really great if we could achieve a solution for this use case: - the user has two clients, A and B, both support MAM+carbons. - A is connected, B is disconnected. - the user receives and sends any number of messages of any kind. - B connects and synchronizes from MAM - both A and B have the same final state. 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: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
