[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

Georg Lukas georg at op-co.de
Thu Jul 13 16:26:24 UTC 2017

* Daniel Gultsch <daniel at 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.

|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170713/3103a22f/attachment.sig>

More information about the Standards mailing list