Modern XMPP project discussion - 2022-02-11

I'm thinking https://docs.modernxmpp.org/client/groupchat/#bookmarks should have some words to the affect of "if `jabber:iq:private` is *not* advertised, but PEP is, go directly to XEP-0402"

Definitely

I think in general that's correct, but I worry that converse.js is the only web client I've ever seen anyone use and it doesn't support 0402. If it were any other single client I'd ignore it, but that one seems kind of important.

What's your point?

I just mean as far as giving advise goes I worry that anything that doesn't include the only webclient is potentially bad advice

I don't understand

The proper fix is servers synchronizing between the three(?) storage methods. With servers that don't (like ejabberd), '402 clients will have their bookmarks synced only with Movim, I think.

Don't worry about it, I think I'm wrong now anyways.

This is advice for everyone, including converse.js. Doesn't matter if it's something an important thing doesn't do.

Also Siskin/Beagle both only do PEP native, so I suspect all iOS/MacOS users have different bookmarks

Holger: do you know if anyone is currently working on sync for ejabberd?

So you are saying that because Converse.js went ahead and did something that is now discouraged, we should ... do what?

I was talking about making the way forward more robust so that everyone doesn't fall back to private xml once we remove the conversion methods

Sam: I added some 0060 changes which I think are preconditions for '402 (e.g. support for `max_items=max`) over the past few months but not actual sync support yet no. (I mean '402 sync. We do sync PEP native with private XML.)

Zash: don't worry about it, you're right, I was wrong, it doesn't make sense to defer this because of converse.js.

Holger: *nods* thanks. I'll subscribe to the issue, I ran into this myself the other day (not just in the thing I'm working on or with the friend I've been trying to find a server for), so I'd definitely love to see it come to ejabberd (and conversations.im)

Another thing which I think is less trivial than it sounds is getting existing setups to bump default max_item limits for PEP. At least with ejabberd the limit has been 10 for many years, as real-world PEP use cases always been using 1 in practice.

XEP-0411 + recommendation to use private xml when there's no bookmarks2#compat advertised should ensure that things are working

Myeah, I wonder if even 256 is enough

So I'm a little worried that multi-item PEP solves a mostly academic issue at the cost of running into ugly breakage in practice.

I have a half-implemented idea about combining per-item size limits with item count limits

(But I do agree that multi-item PEP is the proper solution to these things in principle, obviously.)

With individual Bookmarks 2 items being quite small, allowing more of them seems sensible.

Yeah.

But you wouldn't want to allow over 9000 254.9K avatar data entries

So if one tries to keep per item size limit * max items below e.g. the stanza size limit or so, maybe?

Sounds good.

E.g. allowing 256 1kbyte items, or 1k 256-byte items

So then a RSM-less items request should get trough (modulo margins for wrapper overhead)

And of course xep-0060 already has a pubsub#max_payload_size field

“18:57:49 Zash> I'm thinking https://docs.modernxmpp.org/client/groupchat/#bookmarks should have some words to the affect of "if `jabber:iq:private` is *not* advertised, but PEP is, go directly to XEP-0402"”, the last time I looked at this, jabber:iq:private was specified exactly nowhere, and some servers which do support this protocol didn’t advertise the feature.

So today, we can’t assume the lack of the feature var to mean Private XML Storage isn’t available.

We might need a negative feature, var="¬jabber:iq:private" or something.

“19:44:14 Zash> I was talking about making the way forward more robust so that everyone doesn't fall back to private xml once we remove the conversion methods”, if we ever manage to rid the world of any Private XML client, we can change the meaning of the #compat feature to “servers must advertise it, but it is otherwise meaningless”.

Until we’re there…

“19:47:28 Zash> Myeah, I wonder if even 256 is enough”, I’m at 189 items atm, with a limit increased to 1024.

I might have been an avid MUC traveler, but 256 would feel way too cramped for me, especially given the extremely bad failure case once this limit is reached.

Zash, compression would also be really useful for this usecase. :-°

Remember that it is the uncompressed size of stanzas that limits apply to

failure case is something I wanted to tackle as well..

Telling implementations "Hey it's the end of the thing" instead of not saying anything

What happens when you publish the max_item+1'th item in PubSub?

That's my question!! https://mail.jabber.org/pipermail/standards/2019-October/036503.html