[Standards] Call for Experience: XEP-0198: Stream Management
jonas at wielicki.name
Sat Feb 22 09:49:33 UTC 2020
On Donnerstag, 20. Februar 2020 20:57:48 CET Andrew Nenakhov wrote:
> What other problems we have with reconnection? Roster and presences. Roster
> is mostly not a problem thanks to roster versioning. Presences. It's a big
> problem I'm still on the fence for this one. Receiving all presence
> information on each reconnect is not the ideal solution. I'm thinking of
> using a presence versioning, akin to roster versioning, or maybe to
> eschewing presences at all. The idea of 'always on' messaging has some
> merit to it with always connected modern mobile devices, however,
> personally, I am not ready to give up on green light bulbs on contacts just
Interestingly, stream management can be thought of as a kind of presence,
message and even IQ "versioning". If we think of stanzas as transferral of
state, the initial state before the stream was established + the counters
define the state at resumption on both sides.
The re-transmission of lost stanzas during resumption is catching up on lost
Instead of dropping SM and introducing explicit versioning protocols
everywhere, wouldn’t it make more sense to increase SM timeouts to something
useful for mobile clients?
That leaves the problem that a server may not want to hold an indefinitely
growing stanza queue for a client for a long time. To make this less
expensive, we could define a sloppy fallback version of SM which the server is
allowed to degrade to once it lost its patience with the client. That sloppy
version could have relaxed requirements compared to normal SM or even normal
XMPP streams, but in a way which isn’t hurtful (i.e. delivers an experience
similar to a full reconnect, but potentially faster and with less traffic).
- Deduplicate presence stanzas
- Relax stanza ordering requirements between presences and message stanzas, so
that message stanzas can be replayed from an archive on resumption
- Reply to IQ requests as well as XEP-0409 directly-addressed (ephemeral)
messages with an error once the sloppy period starts
Much of this sounds familiar to thoughts I think MattJ had about per-device
offline messages, just plus some defined handling of offline sessions and
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards