jdev - 2025-03-31

> Background: swift (or swiften?) is a dependency of spectrum2, and I wonder, if spectrum2 should be build without swift support, if the project is not really alive anymore? Swift the Qt-based client isn't still developed, Swiften the library is still actively maintained, but we've probably not been pushing up since we migrated some internal tooling. I'm sure we can sort out pushing up Swiften again if that's desired.

does a server already support the 490 server assists thingy?

I don't think so

MDS adds a lot of traffic ..

for every message i receive in a chat that i read, i need to send an extra stanza, and then receive an extra event, which i need to process

at least now, without server support

then its one pubsub publish less

im not sure why server send the pubsub event to the person that did the publish

seems like a waste

Gajim still does not support pubsub+rsm

but seems it was never a problem until now, but i guess it could get one with MDS

which brings me again to item expiry, would be really good if we had that

then we could expire old mds entries

its in the spec, but nobody implements it to my knowledge

Old entries? It's just one entry per chat

just? that can easily amount to hundreds in a year, even for normal usage

we need to pull that on each reconnect

its kind of ok, if we need that data, but you dont need to pull a stanza id which is 2 years old, just because you wrote that one moderator a pm in a groupchat

if server would support expiry we could set a 6 months or whatever item expire date

that list of items is only bound by the max item count of the server, which is probably so high you never ever want to pull the max

their is no mechanism described in the XEP how this list ever gets smaller, i guess in 2 years i add a cleanup routine

a note in the XEP to prepare to implement pubsub#rsm, would also be good, because without it your impl has also a expiry date

Because of stanza size limit?

no because you get only half the items and no error

if you request "all" items, server sends you 10 and a rsm element, if a client does not support rsm, he simply will believe there are only 10 items

Really? That seems crazy

> A node may have a large number of items associated with it, in which case it may be problematic to return all of the items in response to an items request. In this case, the service SHOULD return some of the items and note that the list of items has been truncated by including a Result Set Management (XEP-0059) [17] notation.

i dont find this crazy though, works as i would expect it

if you only implement half of a spec (pubsub) then you should think about the consequences

in most cases pubsub XEPs publish only to singleton nodes, you are only interested in the last item

bookmarks is already on the edge, you probably should have rsm support, but most non-power users need probably a very long time to mass that many MUCs

but with MDS you basically will have a item for every jid you ever talked to, so i think this list will grow faster