jdev - 2026-05-07

If I add a bookmark without autojoin and without setting a custom name for it, other clients only know about it by its JID (unless they decide to somehow disco query new bookmarks for MUCs they don); I don't think any client does that, at least not gajim). This is not great UX-wise, especially for bridges where group JIDs are generally <gibberish>@gateway. So, let's say I join a group from client A, then from client B I only see that gibberish in my bookmarks. Since the beginning of slidge, my workaround for that is that slidge sets (with mod_privilege) a custom name in bookmark item, which is OKish but kind of sucks, because that bookmark name is then not updated based on disco, except if slidge updates the bookmarks. Slidge does not do that for the user to keep the ability to set a custom (different) name, which is very much needed. I would love to improve that smallish, and I see two options: - XMPP clients could disco info groups when new bookmarks are added, even if they don't join them. Obviously there's not way to force them to do that, but maybe it would actually make sense? I open the "new chat" dialog in a client, if it has no disco info for some jids it offers, it could send disco queries in the background and update the UI accordingly. - OR, maybe, slidge could add a bookmark extension, sort of a "fallback name for that bookmark item without needing to query it". Note that I'm mentioning _my_ usecase here, but I can see this being useful in a non-gateway context too. Client developers, any thoughts? Anyone would be up to use such extension? Is this considered a non-problem?

Some illustration in gajim's "new chat" dialog for groups that slidge did not write a name for:

https://chat.slidge.im:5281/file_share/069fc58f-b0eb-7ed8-b19c-ccc263d0895c/e4c32559-6530-4ed1-80bc-ac8a3ea82399.png

(3rd and 4th rows obviously)

In borogove I always do disco before joining a channel. To know if it has mam etc, but I guess I also get name from this

It'd be nice to remove the need for some of this, and compact the disco info into the joining response(s).

Or caps

but I want to disco before I join anyway so I know if it is a muc or something else etc

dwd: yeah don't agree, I want to know what a thing is before I join

I don't do trial and error.

One doesn't preclude the other.

Joining the first time you might want to do the disco in advance, but joining the second time you know it's a MUC, you just want the updated info. Right?

Maybe of course I can imagine cases where I don't care what changed, I can also imagine a lot of cases where I want to know the config before

Super micro optimisation for some specific cases

etags for XMPP requests, problem solved :D

> etags for XMPP requests, problem solved :D caps ↺

Caps is solving a similar problem, but is not the same.

larma, i have a feature request where someone wants to transfer a file and the source should be a magnet link, would you say attaching such a link as source in 447 with url-data is appropriate?

Should be

yeah seems one can attach any url as target for url-data

and clients can discover that its not a http link and act accordingly

Yup. I think. That's true of all three of our solutions but sims and SFS have the advantage that you can put more than one Uri for multiple options

for extra fun magnet links can also include multiple other links including multiple http ones

linkception

yes, you can add a web seed, and point it to the http upload url

but magnet links would not be interpreted by xmpp clients

they would just present a "open magnet link" button

and call whatever default app available on the system

im not sure if 447 is really the right fit for this

on one side, you want to add the metadata, but on the other side the xmpp never downloads a file, it will have no knowledge if the file was ever downloaded or where it is stored ✏

so in that sense its more like a link preview kind of thing, and less like a file transfer

XMPP clients could totally support magnet natively though

> larma, i have a feature request where someone wants to transfer a file and the source should be a magnet link, would you say attaching such a link as source in 447 with url-data is appropriate? You mean Schimon? ↺

They want Gajim to calculate the hash of a file (MD4 for eD2k, etc. insecure hash algorithms)

and put it in the magnet link

I don't think there is any issue with putting a magnet link, although it might break existing clients 😀

To be quite honest, MD4 (and the other hash algorithms they mentioned) are really REALLY insecure and I would be surprised if people still wanna use them

> I don't think there is any issue with putting a magnet link, although it might break existing clients 😀 Yes there isn't, but the Gajim feature request is about making Gajim calculate file IDs for P2P services ↺

Yeah, that sounds stupid to create a magnet link if you don't know the file is actually available via torrent

MD4 is worse than SHA-1, it's 40 years old at this point

And to be honest, I'm not even gonna guarantee someone isn't gonna swoop in and craft a malicious file that matches the same hash and end up compromising everyone

Cynthia, this was not the question and is irrelevant, magnet links exist and are in use, there is no reason why such links should not be sent via xmpp

> Cynthia, this was not the question and is irrelevant, magnet links exist and are in use, there is no reason why such links should not be sent via xmpp Yes there is no reason why ↺

But the feature request specifically mentions that Gajim should be responsible for generating magnet links

And calculate the hashes

but this is off topic here, and i dont know why you bring up feature requests that nobody read here, and is not interesting to anyone here

> larma, i have a feature request where someone wants to transfer a file and the source should be a magnet link, would you say attaching such a link as source in 447 with url-data is appropriate? ^ ↺

we are talking about the protocol to transfer a magnet link

yes what are you trying to say? i mentioned the word feature request?

let's define a way to seed torrents over base64 in xmpp messages 😈

> yes what are you trying to say? i mentioned the word feature request? Was this the request you were referring to? https://dev.gajim.org/gajim/gajim/-/issues/12711 ↺

How is that relevant

why are you derailing my discussion with your opinions about file hashes

Because you mentioned that you have a feature request where someone wants to transfer a file and the source should be a magnet link

thats the context where i asked a question if a magnet link is a valid target for url-data

Oh

you can take only the parts of requests that make sense

Well sorry