jdev - 2025-06-05

Anyone about who knows/writes/etc slixmpp?

So, should anyone pass by: I'm trying to connect to a custom host/port with direct_tls, and that seems to be unsupported now. I can turn off TLS, but not turn it on, because - if I follow the code right - it assumes any custom host/port is plaintext connect with possibly starttls.

xmpp:slixmpp@muc.poez.io?join

Thanks!

a user asked for a feature to hide the app identity, so app name and version

both can be requested via xep 0092, which is rather easy to deactivate

though the app name is also in disco info identity, of course i could remove it there as well, but i wonder if that is viable

don't forget FAST

FAST?

i dont care to hide it from the server operator to be honest

but we dont implement FAST yet so ..

the question is, is it viable to not answer disco requests at all, and if not, would it not be trivial for someone to determine that its Gajim simply by looking at the features in disco info

what breaks if i dont answer disco info requests, is probably the question

ah we need disco info for pubsub subscriptions, so yeah thats out of the question

> i dont care to hide it from the server operator to be honest why not? ↺

because the server operator is probably the 5 % that costs 90% of the effort

or whatever that ratio was :D

i could block disco info requests form jids which are not my own server

then pubsub sub works

> the question is, is it viable to not answer disco requests at all, and if not, would it not be trivial for someone to determine that its Gajim simply by looking at the features in disco info Some clients return disco info sorted into alphabetical order, but Gajim does not

Of course that on its own wouldn't be enough to determine it is, in fact, Gajim

i agree its trivial if you receive disco info even without name to determine its Gajim

thats why im thinking about to not return disco info at all

i think its only problematic for the Jingle XEPs?

but should be fine with JMI?

client disco should have been deprecated ages ago, burn it!

It's always a bug to ask and base decisions on "what features are supported by client(s) they have connected right now"

yes, but i have users that want things to work

so better to ask the question what could break

what would break? I think only things that are already broken

> It's always a bug to ask and base decisions on "what features are supported by client(s) they have connected right now" Based ↺

> client disco should have been deprecated ages ago, burn it! Some of us actually like XMPP 🙂 ↺

I think all of us here do

" I would like to be unable to try to call my contact if my device thinks, often mistakenly, that they don't currently have any devices online that support calls" said no user ever.

doge: not remotely what was being talked about

That's actually exactly what I was talking about

singpolyma, i would also disagree, thats what historically we used disco info for, mostly jingle

some XEPs even say you should check and dont send something like a marker request, or chatstates etc

and in some distant past that made sense, but is now a bug

Having a button for calls or not is a UX decision. Disco is a protocol thing not a UX thing

And we need it for lots of stuff. As already mentioned for pep at least

yes, nobody says burn disco alltogether

> Having a button for calls or not is a UX decision. Disco is a protocol thing not a UX thing 🙄 ↺

the proposal was burn it between user clients

Correct

of course we want disco from a service, or server

There's no reason you should be able to tell if I'm a client or a server anyway

so you think it will cause no problems if Gajim answers disco info requests from other user clients with an error?

that was my initial question

I think that's impossible to do

And also not sensible to want as a seperate thing

im aware you cannot make a statement for the whole world, but maybe for the client you develop

I don't know

will something stop working if gajim answers disco info requests from cheogram with an error ✏

:/

It's not the job of the entity generating the error to handle the error.

the question was, how another client handles the error

Try it?

If an entity replies to a service discovery request saying that it does not support service discovery, then it stands to reason that a client would assume that the entity does not support service discovery. This would naturally preclude other features that require an entity to support service discovery in order to advertise support for it.

lovetox, is the request "I don't want it to be obvious that I'm using Gajim" or is it "it should not be possible for a determined adversary to deduce I'm using Gajim" ? -- the former is easy and limited, the latter is possibly more trouble than its worth. Also consider what does Gajim do if a client returns error for a disco request?

what does that help me, i know what my client does, i want to know what others do :D

it should not be easy to determine that i use Gajim, i think its nearly impossible to hide it completely, it depends how much effort an attacker puts in

<body>hey what client are you using</body>

lovetox, singpolyma, some clients have a unified flow for adding contacts and joining rooms.

It works by doing a disco on the jid, to check the available features and guess if it's a room or not.

But that (should?) work even when the contact is offline. So I guess the server is replying on behalf of the client in that case?

Oh never mind. The client identity should only be returned when doing a disco against a full jid

The scenario I mentioned involves disco queries against bare jids ✏

> it should not be easy to determine that i use Gajim, i think its nearly impossible to hide it completely, it depends how much effort an attacker puts in gajim literally sets the resource name to gajim.randomstring 🤔 ↺

as in jjj333@pain.agency/gajim.something

> It works by doing a disco on the jid, to check the available features and guess if it's a room or not. Not guess. Know 🙂 ↺

> But that (should?) work even when the contact is offline. > So I guess the server is replying on behalf of the client in that case? When you disco (or any iq) a bare jid server always replies to that ↺