jdev - 2024-11-05

Holger: so is it plausible that with a too-low fsm queue, a single client could exhaust the queue and trigger a policy violation by joining a lot of MUCs and receiving a large burst in response?

(Especially when bridged to telegram, irc, matrix)

wgreenhouse: It's not a global queue, it's a queue per 'process/thread', and there's one process per client. But yes a client joining a large MUC could exhaust that queue. If the 0198 queue is hit, the stream is closed with a policy violation; if the FSM queue is hit, the client is just disconnected. Setting the latter larger than the former makes sure there's no such silent disconnection.

And yes that's probably not the smartest way to manage queue sizes …

that's simply the downside of XMPP's push/fan-out/little-server-state architecture, and there is no fix, besides changing the architecture to something else (e.g., what imap does)

Hi. I'm implementing XEP-0402 (Bookmarks 2), and I try to test with Gajim, Dino and Conversations. All indicate support, but they use private storage instead. Is there anything to do to activate bookmarks 2?

goffi: I guess they fall back to private storage if the server doesn't announce `urn:xmpp:bookmarks:1#compat` (and/or `#compat-pep`?).

Oh OK, I don't have this one indeed

But I just want to test Bookmarks 2, I don't need unifying for now.

I'll see what I can do, thanks Holger.

That also means that a server implementation needs to supports both private and bookmarks 2. I guess nowadays, we can try to get rid of private (and XEP-0048 is deprecated).

There's no right or wrong of course, but I guess the popular server implementations support those, so keeping support for another while isn't all that expensive? And UX in the case where interop does go wrong can be perceived as super-meh.

The other problem I see with Bookmarks 2 is existing setups with restrictive max_items limits. ejabberd's default limit has been 10 for a looong time.

Holger: max_items should be set to "max" as publish-options. Also it's expensive to me because I'm not using server implementation.

And it's expensive to new server implementations.

goffi: > max_items should be set to "max" as publish-options. The integer-or-max thing is another thing that's new.

new?

The max_items use "max" for as long as I remember.

> And it's expensive to new server implementations. Sure. As I said 'no right or wrong', it's a trade-off. Just saying that it _is_ a trade-off. I mean we do generally try to avoid interop breakage as long as there's (relevant) implementations doing 'the old thing' …

goffi: Hrm, 0060 changelog mentions the addition of the datatype in 2021: <https://xmpp.org/extensions/xep-0060.html#revision-history-v1.20.0>

Maybe 0060 had `max` before, but ejabberd certainly didn't.

And publish-options didn't work the way they do now until a few years ago.

Holger: the data time has been added after, but the use of "max" is there since the early days AFAIK.

I may misrember. Either way I added this to ejabberd in 2021.

goffi, https://docs.modernxmpp.org/client/groupchat/#bookmarks is my recommendation for clients’ authors.

(For explicit node configuration. I think this didn't work with publish-options initially; and that's definitly something that changed in the [stable] spec.)

goffi: I mean I agree we should just move on to the new world eventually, it's just not obvious (to me) at what point to drop compat.

I just hate seeing users ask why they're in some groups when using client A and in others when using B, and having to respond with 'welcome to XMPP'.

goffi: And `max_items=max` support obviously doesn't help if the max limit is below the number of groups the users would like to join …

Or in some groups with account A, and other groups with account B, or the account would login cycle. Welcome to xmpp!

Or you got yourself into a broken bridge situation you can't get out of. Welcome to xmpp!

Thanks for the answers Holger and Link Mauve