Modern XMPP project discussion - 2024-06-20

As I understand it CSI sleep is no connection state but on another level.

arcanicanis: you may want to include XEP-0198 states in there. I.e. some kind of "we had a session but it got disconnected", which allows you to resume after the TCP connection is reestablished

And I agree that you should track CSI state, but probably separately

But that's up to you

One could argue for XEP-0198 state being separate too

as far as the main use for the connection/session state is mainly: that certain stanzas are handled only during certain session states; e.g. <stream:features> goes to a different handler function, depending on if it's before authentication has happened, or after

So I could have a "reconnecting" state, if there's a means of resuming a session from before connection drop, etc

(I have my WIP so far at: https://arcanican.is/demo/tgxmpp/ It's able to handle login flow, and auth/connection errors, next I'll add direct messaging and querying avatars/profiles soon)

(and is also namespace-aware now)

So effectively as implemented in modern clients: direct messaging is still engaged towards a single resource (or rather, full JID, when discovered), and that single resource has to providing message carbons to other devices (plus MAM for offline devices), or else all other devices are out-of-the-loop?

as I was noticing (XMPP IM spec): > Once the user's client receives a reply from the contact's full JID, it SHOULD address its subsequent messages to the contact's full JID as provided in the 'from' address of the contact's replies, thus "locking in" on that full JID. https://xmpp.org/rfcs/rfc6121.html#message-chat

arcanicanis: no, the server is responsible for distribution of the messages

Resource locking is optional, but I would recommend it

But you can also not bother, since it is definitely additional work

Isn't the Modern thing to never do resource locking?

Are you calling yaxim modern? 😅

I wouldn’t, but the recommendation should be to never do resource locking and to always send to the bare JID.

Everything will generally still work if you do that

or rather, there is also the following line of: > A client SHOULD "unlock" after having received a <message/> or <presence/> stanza from any other resource controlled by the peer (or a presence stanza from the locked resource); as a result, it SHOULD address its next message(s) in the chat session to the bare JID of the peer (thus "unlocking" the previous "lock") until it receives a message from one of the peer's full JIDs.

I guess I don't even understand what their intent was, other than to maybe minimize traffic to client devices that aren't participating, but then that probably creates conversation history gaps; but then if you choose to instead only send to bare JIDs, then what is the intent of Message Carbons (or is it relatively vestigal)?

s/intent/purpose/

I guess the intent of carbons is, that even with clients that send to the full jid, you get all messages everywhere. And it was a thing once to only speak to specific devices once...

We even had these priorities one could set up...

With some setup, you could get messages routed to where you were, or everyewhere if it was uncertain and then follow you when you moved and replied from a new client