jdev - 2026-02-11

Is there any way to know if I have "pre authorized" a subscription to my presence? If they accept then my roster will say "from" or "both" but until they accept it just says "to" or "none" even if I already authorized them

https://xmpp.org/rfcs/rfc6121.html#rfc.section.2.1.2.1 ?

In addition to what MattJ says, you would receive a roster-push with `approved='true'` after doing the pre-auth.

I.e. you don't have to query for it.

You SHOULD receive one, since it isn't a MUST

Right

hmm, I'm not seeing this attribute

It's generally acceptable for a client to burst into flames if a server doesn't follow a SHOULD

<presence to="jid" type="subscribed" id="ijm5rIMuDaGrGPQhU9" xmlns="jabber:client"/> I see I send this then I get this roster push: <iq id="CzSXv2bvU4ok" type="set" xmlns="jabber:client"> <query xmlns="jabber:iq:roster" ver="313"> <item jid="jid" subscription="to"/> </query> </iq>

Not true anyway, "the user's server MUST note the subscription pre-approval by setting the 'approved' flag to a value of "true", then push the modified roster item to all of the user's interested resources" - this push is a must. It's just the subsquent ones don't have to have it.

singpolyma, what server are you using?

> <presence to="jid" type="subscribed" id="ijm5rIMuDaGrGPQhU9" xmlns="jabber:client"/> > > I see I send this then I get this roster push: > > <iq id="CzSXv2bvU4ok" type="set" xmlns="jabber:client"> <query xmlns="jabber:iq:roster" ver="313"> <item jid="jid" subscription="to"/> </query> </iq> Did server advertise `<sub xmlns='urn:xmpp:features:pre-approval'/>`? ↺

If it didn't, then your only option is to cry

Advertisement through stream feature, fun

singpolyma, https://hg.prosody.im/trunk/file/tip/core/rostermanager.lua#l70 explains it

MattJ: so prosody lacks this feature?

It has the feature, it just doesn't include that attribute in roster items

ah

I have a feature request ;)

A simple oversight, I imagine

https://hg.prosody.im/trunk/rev/beb5a667c20d

Movim now implemented https://xmpp.org/extensions/xep-0507.html and can share your audio and video simultaneously when doing screen sharing :) I'll announce it more publicly in the upcoming days.

Wow, that's great! :)

Out of curiosity, UX-wise, do any clients warn the user if their server doesn't provide a TURN service? Because I feel like that's a big gap with A/V calling and misunderstanding of expectations. e.g. if there was some "The server of your account doesn't provide a TURN service, you may experience difficulty connecting with some peers of your call, depending on the networking of the call participants", I'm sure it'd bring the state of things lightyears into the future than where it is now, in terms of server deployments.

(but again, I haven't re-evaluated where A/V calling is at for a few years, I don't know how much has changed since)

or bubbling up any errors about if it's unable to connect to any of the candidates for a specific contact, and plenty of other things to make things more diagnosable

clients could do that, but how far do you go? just because a turn server exists doesn't mean you'll be able to connect to it

> or bubbling up any errors about if it's unable to connect to any of the candidates for a specific contact, and plenty of other things to make things more diagnosable that seems like it'd be really helpful ↺

I'm not saying that'd be the end of it, I'm saying that clients need to be more informative about when something goes wrong

Probably the 'easiest' thing is implementing something that works, the hard part is handling and anticipating any of the ways things can break and not work

I don't know if this is still the case but I know conversations used to refuse to show the call button unless there was a turn server