XSF Discussion - 2024-06-30

Hi, in XEP-0484, why are there two quite different <fast/> elements, one being used in the inline sasl2 features, and the other to transmit the count in <authenticate/>?

Wouldn’t it be more sensible to have them use a different element name?

I’m writing the schema for that XEP and it makes it needlessly complex.

Anyway, https://github.com/xsf/xeps/pull/1352

Why would a different element name be needed? They're in very different context

singpolyma, IIRC it is either hard to make XML schemas context sensitive (or maybe even impossible). but I think it is "just" hard

using the same elemnt name and namespace with different content depending on the context is just causing pain on so many different levels

i'd say it should be considered an anti-pattern

but this discussion pops up every 3-5 years

singpolyma, I don’t use XML Schema validation, I have a more XMPP-targeted DSL, but it makes it harder to express which parts are truly optional and which ones are just because it is actually a request and a response mixed as the same element in the same namespace.

I usually use the XML Schema to get an overview of what is allowed in each element though, before writing my own DSL.

alone that it is easier to look at the XML schema the xep may provides if those two elements have actually a different name would be enough for me to justify to design it that way

XEP-0386 says: “Upon processing the bind request, the server MUST perform several operations, including: • Clear the offline messages for this user, if any, without sending them (as they will be provided by MAM).”

What about servers which have different retention mechanisms for offline messages and for MAM, especially where the former is kept for longer, does that mean the messages should be destroyed even if they were available, when the user successfully uses Bind2.

Yeah, this is currently something that would be dangerous to implement and guarenteed to cause lost messages

though there are ideas about to fix that

Is it guaranteed to cause lost messages?

Offline messages have always held the promise of delivery to one device

If you have a bind2 client, that's also a MAM client, so it will get those messages

Ah, but you mean if they are older than the MAM retention, got it

is this not a contrived scenario

what is this scenario? You tell your user, we respect your privacy, we hold messages only for 3 days in the archive, buuut there is this other place where we store messages a lot longer

> Ah, but you mean if they are older than the MAM retention, got it Yes exactly. If I use a 7 days retention server and go on vacation for a month ↺

why would you not expect to lose all messages?

thats the whole point of a retention limit

to delete stuff from the server

Not before I get them though :/

Yes ! You now discovered the meaning of retention

But maybe you can invent "retention after it got delivered"

though that might be infinite time, hence no retention at all

That's the current reality in xmpp server software

i doubt that very much, you probably mean a reality in current server configuration?

as mentioned above, seems server operators already set retention limits for offline messages

I don't have a knob to change that in prosody, that's what I mean. Offline messages are stored for infinite time and no config option

hm i dont operate a server, if the retention setting is not applied to all messages, this seems problematic

Yeah if someone has to connect every so often or lose messages, they will simply consider the setup broken. You can explain that the words you use should have indicated to them that it is broken, but that's not gonna make them happier

dont get what you want to say, feels like you search for a solution how to prevent that server operators dont misconfigure there server

but i dont think thats a bind2 or protocol issue

At a protocol level there are related issue, such as that if you set mam to "contacts only" then you will miss messages from non contacts. Both mam as specified and mam as implemented relies on offline messaging to paper over there kinds of cracks. I'm not saying we can't or shouldn't fix both the protocol and the implementations 🙂

i see, so mam needs offline messages when we set specific storage options e.g. per contact

there is a delivery function, and a storage function

Right. Otherwise that setting even being a available would be bonkers (though I think we mostly agree it's fairly bonkers anyway at this point)

Once we have the whole BIND2 family of things deployed, and the server can keep track of what clients are used with an account, it can make better decisions about adjusting retention, e.g. keeping messages until every client has received them.

still dont see how this relates with retention, there should be only one retention setting for both ✏

Zash: right. And if we lived in that world I'd say offline messages can die. But until we have a guarantee that mam is picked up by at least *one* client then we need offline messages to not end up totally broken

But ultimately there has to be a limit somewhere. We can't keep everything forever, something has to give.

You _could_ send a delivery failure when deleting undelivered messages... wait are we slowly turning into email? :/

sounds like problems that nobody needs to have solved

seriously, a normal server will have a retention period of many months or a year

the prosody default is 7 days

sounds like a default value which can be improved

but again, this is not a protocol problem