XSF Discussion - 2024-06-14

when a new MUC room is created, should the owner be sent an (empty) subject message (presumably to signal that they 'entered' the room)?

Guus, the workflow is described in much detail in the XEP

and subject is not part of it

this has a deeper reason, the subject serves a very important role in the join process

it separates history messages that are sent from the MUC, from real live messages, without the subject inbetween a client cannot differentiate both

this problem does not exist on room creation, neither history messages nor live messages are part of that process

so you can send a subject, but i would argue every client who depends on it is not compliant

I'm looking for security material or an in-depth description of how XML EXI works, does anybody know of resources beyond the void that comes up when googling?

Thanks lovetox

Ge0rG: try reaching out to Arc.

5-6 positive responses regarding an XMPP sprint in the UK, so I think it will happen, and will start planning for it

👏👏👏

Random thought of the day: Has anyone ever thought of or experimented with queuing up outgoing s2s messages for some amount of time smtp-style ? To handle scenarios where a server might have spotty connectivity?

brainstorming... probably just handle presence and IQs like now, and only buffer <message>'s... it would be nice to have a way to respond to clients "hey we can't deliver this *now* but will keep trying for X time" and perhaps send back a confirmation when delivered or dropped

M-Link has a fair amount of logic for dealing with spotting connectivity and stanza queues and the suchlike, yes.

Ah interesting, is there any notifying to the sender of this happening?