jdev - 2025-11-21

With Jingle, is there any way to signify what "priority" there is to a Jingle call? It's been a long time since I've poked at A/V with XMPP clients, but last I remember: any time someone would initiate a Jingle call, it'd pester *everyone* in the room, like some priority conference call, as if they were receiving a phone call, rather than having any sort of 'silent' ring instead

Or to approach the question differently: is there any way to signal to a MUC of "ready to voice chat", where it'd be a UX flow of: someone wants to start a call, they signal their intent to the MUC, but absolutely no Jingle chatter starts yet, but when a participant of the MUC reciprocates the intent to 'join', then it'd instantly start the Jingle call setup (exclusively between the initiator and new join), etc? ✏

There is no group calling so this is an open question

But also that seems like a Ux question so the answer as always is that an app can do whatever it wants to do

I intend eventually to probably have mumble/discord style "av rooms" where entering them joins you to the call. But this is not the only option obviously

> There is no group calling so this is an open question I don't know if it's Muji or something else? I'm just blindly trying to make sense of what I vaguely remember from probably a couple years ago, with Gajim or some other client ↺

Dino

> I intend eventually to probably have mumble/discord style "av rooms" where entering them joins you to the call. But this is not the only option obviously May not even really need to be a distinctive thing, but couple be purely a procedural thing (where people have a separate MUC room designated for video/voice chat, and the text chat of that room being solely to augment those calls; to separate from text-only MUCs) ↺

> Dino I'm referring to XEP/standard that may have been facilitating some sort of 'group call': https://xmpp.org/extensions/xep-0272.html ✏ ↺

Muji is a neat hack but it doesn't work if you use multiple apps and is unlikely to survive GC3 not to mention the bandwidth issues so yeah. Probably you can still do any UX you want with that protocol but I don't consider it heavily

Then what would be the fair alternative option?

Regular jingle to an SFU component

Because as it stands, I just want this problem 'solved', I'm impatient with "ehh well, that doesn't work", "nah, that's incomplete", etc. I just want actionable results, and will concoct whatever abomination I need to fulfill my needs.

> Regular jingle to an SFU component Do we have any XEPs yet for setting up channels through an SFU? ↺

Just regular jingle calls

They're analogous to anything you can do in sdp land with an SFU so "just" need to translate

What we need is code not XEPs

If we discover XEPs we need in the process of producing code that's easy to do later

Can you point to where in XEP-0166 it provides the mechanism for the client to ask for an SFU relay resource?

That's not really a thing you need to do? You just publish to the SFU and it relays

And sends you everything it has as other channels in the same call (usually... Livekit uses two calls)

Yes, but how is an XMPP client going to discover an SFU relay, unless I'm missing some nuance (like if it's part of RTP or other protocol in the stack, that I'm not aware of), and without having something hardcoded in a webclient or whatever?

To preface, I have not read the whole thing top-to-bottom yet

It would be a jid that either calls you or you call it. That it's backed by an SFU or not doesn't matter to you

because Ctrl+F'ing for 'relay' (2 matches) or 'SFU' (0 matches) doesn't seem to get any results for a specific standard mechanism of discovering that

Right. Relay isn't a concept in webrtc/jingle it's just what we call it

It's just a webrtc session in the end

because, as I'd expect it: there'd be some component discoverable from Service Discovery, for some SFU component addressable through XMPP, that you'd send a request to that component "Hey, can I get two RTP channels?", and component would be reply "Sure, you can use these two ports, use this one-time token for authentication, have your recipients connect to these ports, to receive" or whatever concoction, of however RTP or any of that works. ✏

and hence earlier, I was also fishing around with WHIP/WHEP, since that sounded like some other standardized way to plug things into an SFU, off-the-shelf, since it sounds that TURN relay is only 1:1 ✏

Oh you want to spin up a jid on the fly for the call? Maybe could do that if desired. Or could have a muc component where every MUC is also a call. Or let people use any made up jid and use uuids. But yeah if you want an ad hoc command to reserve a jid or something you could. If we got the actual hard parts done this would not be hard to do in a dozen ways I expect

How can I determine the stanza-id for a message I send? Would I have to query the archive for that or is there a variant of carbons that reflects messages to the sending client too?

There's no good way unfortunately

Well with a MUC you get a reflection and then you have it. But for 1:1 no good way

ok that's what it looked like, good to know

I guess I'm missing the point of Stable IDs then? https://xmpp.org/extensions/xep-0359.html

IDs from RFC aren't required to be globally unique

You well can have a client send different stanzas with same ID if it created a new session

Yes, but I thought the point with Stable IDs is you can affix your own ID as well (<origin-id />), to make it easier to keep track of

whereas UUIDv7 for <origin-id /> would be a simple mechanism to avoid collisions, be sortable, etc

even just highlighting the excerpt: > For example, they can be used together with Message Archive Management (XEP-0313) [1] to uniquely identify a message within an archive. They are also useful in the context of Multi-User Chat (XEP-0045) [2] conferences, as they allow to identify a message reflected by a MUC service back to the originating entity.

Every problem in computer science can be solved by adding another id

... except for the problem of too many ids.

Well, it's the fun of federated systems, especially when cryptography and canonicalization isn't involved

as well as trying to address shortcomings of something that wasn't originally considered, and having to do it in a backwards-compatible way

If this was addressed in XMPP Core, it wouldn't need a XEP

Well, the problem is that server now also needs to support all kinds of XEPs

not "needs" ;)

because as far as I understand, XMPP was to be as stateless as possible, just pass messages through, and not concern about state; now we have server-side storage, history, and other mechanisms to roll into design considerations, so now this is needed

Instead of just storing your roster and relaying stanzas

Most applicable XEPs, as far as I'm aware, is mostly client side. While, yes, cleaning up just roster management, vCard/xCard/whatever representations, translations, is a whole different mess

servers don't even need to support roster

thankfully, considering it's an outdated concept

Nooo, not my roster

Roster is absolutely fine

There is absolutely zero need to artificially make XMPP more like "modern messengers"

do it naturally then :p

I'm saying in regards of how many things there are for just simply representing contact info, roster details, etc;

I'm not implying anything further needs to be done on it

imho having server store all your contacts in plaintext is unacceptable in ~2025~ 2013

But yeah, vcard-temp and user/muc avatar stuff is a total mess

also imho presence is completely useless and no one I know wants it or even knows it exists

but the nice bit about XMPP is I can do what I want and you can do what you want and we can still communicate (:

The fact that the most popular vCard format in XMPP is baaically a non-standard one is insane

basically*

c'mon guys, we need to get with the times: jCard is now the bees knees, gotta rebuild all protocols, formats, etc in JSON now. :P

Not the json, i beg you

and to modernize it even more, it needs to be queried and updated via an HTTP RESTful API. :P

I'd agree even with S-expressions, just not the damn json

(I can assure I'm being completely comedically sarcastic)

Even HTTP/SMTP/IMAP/etc like plaintext commands would be better than JSON

XPMP anyone?

> also imho presence is completely useless and no one I know wants it or even knows it exists i love presence and wish more things had presence 🤷‍♂️ ↺

> servers don't even need to support roster I mean it's in the RFC so they kinda do ↺

nah the RFC says it's optional

i also intend to make use of xmpp's chatstates feature to (optionally) indicate to others when you have a chat open etc etc

> The fact that the most popular vCard format in XMPP is baaically a non-standard one is insane vcard-temp is hardly most popular. It's dead except for MUC avatar stuff ↺

>> also imho presence is completely useless and no one I know wants it or even knows it exists > i love presence and wish more things had presence 🤷‍♂️ Is there anything that doesn't? Just signal AFAIK ↺

> i also intend to make use of xmpp's chatstates feature to (optionally) indicate to others when you have a chat open etc etc Yaaaaassss ↺

> Is there anything that doesn't? Just signal AFAIK signal, imessage are the 2 that come to mind ✏ ↺

also matrix has presence but it doesnt really count since enabling it will practically topple your server

and only 1 client supports rich presence

>> i love presence and wish more things had presence 🤷‍♂️ > Is there anything that doesn't? Just signal AFAIK none of the most popular communication tools have presence right? Email & SMS ↺

Neither of those are popular

WhatsApp, telegram, Facebook Messenger, discord all do

might depend where you are, 100% of the people I know only use email and SMS, and none of those others

other than the ones I converted to XMPP of course

email is still big in the business world at least

I have a few clients that practically treat email like instant messaging, even

You should get them delta chat 😉

I'm aware of DeltaChat as well, but unfortunately they're on that horrendously slow email provider known as Gmail

> might depend where you are, 100% of the people I know only use email and SMS, and none of those others almost everyone i know uses discord, snapchat, and imessage ↺

I'm on my own mailserver, and per email notifications, I apparently have a couple second lead, to jumping into a livestream, ahead of people on 'mainstream' email providers

discord arguably is a good standard for what rich presence looks like, but neither snapchat nor imessage have much presence

Wow snapchat. Blast from the past. But it indeed also has presence

imessage only recently added an optional indication if you have dnd on

> Wow snapchat. Blast from the past. But it indeed also has presence not really that ive found? ↺

it has chatstates

but not just general online/offline

imo chatstates is one of the things it gets right, not that its mandatory though

https://help.snapchat.com/hc/en-us/articles/17980426873492-What-does-the-green-dot-in-my-Friends-avatars-mean#:~:text=The%20green%20dot%20shows%20up,up%20unless%20they%20disable%20it.

> https://help.snapchat.com/hc/en-us/articles/17980426873492-What-does-the-green-dot-in-my-Friends-avatars-mean#:~:text=The%20green%20dot%20shows%20up,up%20unless%20they%20disable%20it. huh ive never seen that ↺

but fair enough

and imessage i suppose it doesnt really make much sense since its generally (perhaps falsely) expected for your phone to always be able to recieve imessage

iMessage was started as basically sms yeah

Though even RCS has presence haha

> Though even RCS has presence haha not on iphone it doesnt 😕 ↺

though my carrier also fucks up rcs, if you try to send an attachment over like 20kb during peak traffic hours it will fail after 5 minutes and you have to retry as sms/mms ✏

Your carrier has their own RCS? Not just using Google server?

apparently? im not entirely sure

all i know is that i didnt get rcs until mint mobile emailed me saying they enabled it

i cant find anything much in settings but the fine text indicates that its my carrier who gets the identifiers?

https://downloadable.pain.agency/file_share/019aa899-2a2f-78c6-8017-b58f6adbd630/signal-2025-11-21-124533.png

learn more leads to https://support.apple.com/en-us/104972 > RCS is a carrier-provided service. When your device connects to your cellular network, it communicates with your carrier and their partners to set up RCS. User identifiers are exchanged for your carrier and their partners to authenticate your device and provide a connection. These identifiers could include but are not limited to your IMEI, IMSI, current IP address, and phone number. Your current IP address might also be shared with other RCS users.

Yes but most carriers have contracted with Google to do the providing for them

fair enough

all i know is that its a worse experience than raw sms/mms for me, as most the time i cant even successfully send attachments

and no i dont get any presence, just read receipts and typing indicators

even reactions fail to properly apply, however thats surely apples fault

> nah the RFC says it's optional As per §12 Conformance Requirements in RFC 6121, support for roster-get, roster-set, and roster-push are all "Client MUST, Server MUST." Of course, you're not required as a user to add anything into your roster, if you want to use that to argue that "it's optional" ↺

~will jmp.chat have rcs?~

theTedd, how do you explain https://www.rfc-editor.org/rfc/rfc6121#section-2.1.4 ``` If the roster does not exist, then the server MUST return a stanza error with a condition of <item-not-found/>. S: <iq id='bv1bs71f' to='juliet@example.com/chamber' type='error'> <error type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq> ```

I interpret this as: server does not need to support roster

plus an XMPP server need not even support 6121 at all right? only 6120?

The server would have to support rosters to be able to reply that a roster doesn't exist for the given JID. Why a JID doesn't have a roster is a different question (maybe as simple as it's not created until a first thing is added?) but the server still supports roster.

You can implement just 6120, but then you're not supporting IM or much else

if you just had enough support to respond with item-not-found I think that would be RFC compliant, but a generic IQ error would probably be handled fine by everything

If you don't support roster then you'd reply with a simple iq-error, but your argument was that the RFC says roster is optional - while it says the opposite

and 6120 does instant messaging just fine, roster & presence subscriptions aren't needed in any way for that, and imho are actually pretty outdated

Who are you IMing, and are you typing in their JID each time?

only your client needs to know, we are only missing a XEP for encrypted contact list in PEP or so

or maybe you only have 1 client or sync contacts a different way, like address book on your phone

Both message type='chat' and message body are defined in 6121, so you're not going to get far without those (they are only used in 6120 for illustration in examples)