[Standards] Sprint for Message Routing
georg at op-co.de
Wed May 13 16:54:26 UTC 2020
* Jonas Schäfer <jonas at wielicki.name> [2020-05-09 18:36]:
> Please reply to this message on-list or privately to me if you are interested
> in participating within a week.
The rules for Carbons, MAM, CSI and Push are different, partially
implicit (payload), partially explicit (hints). We need to fix those.
Here is a short list of issues that I am aware of:
- what are the "persistent" messages, which need to be stored
permanently and sent to all clients?
- what are "urgent" messages that need to flush CSI and/or cause an
"urgent" Push notification?
- what should qualify as "payload elements typically used in IM" (re
XEP-0280 §6.1; related to "persistent")
- we need a good-enough list of relevant but body-less IM payload
- MUC invitations (direct, mediated)
- Jingle Call messages (looks like there was some activity here!)
- chat state notifications (those should become presence some day)
- chat markers
- XEP-0184 receipts (type=normal, anyone?)
(There is XEP-0226 which would profit from getting updated, and which
might serve as the master registry of IM payloads for Carbons and MAM)
- (how) should we persist/carbon-copy message errors?
- what to do with negative priority clients?
- what to do with system-generated messages like MAM, Carbon wrappers?
- how can we get Carbons from a bridge in a secure way? (when you login
to Signagram from XMPP, and write a message from the native Signagram
- what non-IM uses of XMPP are we breaking/affecting?
I think there are two conceptual parts that we need to cover:
a) Legacy routing rules (we won't get rid of them any time soon)
What are the rules that we need to integrate into Carbons, MAM, CSI and
Push to cover the currently existing corner cases?
Those are the same rules that we will need in the IM-NG legacy interop.
b) IM-NG-only business rules
I think that IM-NG replaces MAM and Carbons well enough, but:
- use hints or some other way to encode urgency, persistence, ...?
- copy,archive --> send to bare JID
- no-copy,no-archive --> send to full JID
- copy,no-archive --> type=headline to bare JID
- no-copy,archive --> forbidden for good reason!
- urgent --> ??? (this has implications on E2EE, also should this
really be driven by the sender?)
- could/should a server filter based on client capabilities? i.e. client
does not advertise CSN support, server strips CSN payloads, drops
CSN-only messages (maybe orthogonal to IM-NG?)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the Standards