[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)
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
(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
- 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...
Size: 833 bytes
Desc: not available
More information about the Standards