XSF Discussion - 2024-02-19

Is there any PR (or better yet, lobby work) being done on pushing XMPP forward as the standard protocol for interoperability in the EU?

Yes

I'd be interested in any links to information regarding this ✏

I don’t think there is a lot of public information about this

the gatekeepers (primarily Meta) are pushing for "let's open up (a variant) of our c2s api" (see https://gultsch.social/@daniel/111528938093114289 or the wired interview that was posted here a couple of days ago. and while our voices wrt "open standard and s2s federation" have been heard it is my personal opinion that the EC seems to be fine with the Meta approach (for now)

The EC interviewed me as a stakeholder. I didn't get to ask them questions. So my interpretation of their position is an extrapolation of how they phrased certain questions

Daniel, cool, thanks for the link.

But given that other providers are more centralised (and actively pushy), I wonder how the decentralised XMPP should approach this.

Is there a way to make calls via xmpp?

Yes, you need to either set up a STUN/TURN server which is embedded in your xmpp server or point your xmpp server at something like coturn

GregorTacTac: certainly. Various clients support audio and video calling

I was quite amazed by Goffi's implementation of a video call in a terminal, that he showed last week. :D

I should really just drop our entire infra in some public git and redact it so I can just point people to a single file to set up xmpp with all this stuff

Are calls implemented in Conversations?

I dont have android but I think so, it’s one of the most feature rich clients afaik

yeah they are

It was (one of the) (the) first? With the modern approach, utilizing encryption with webrtc.

Do you remember video calls in Gajim? Pepperidge Zash remembers.

That's why I wrote about the "modern" approach 😛.

I mean, the modern approach is the same as the old approach, except that dtls-srtp is mandatory now

I can't find the button to call someone on Conversations.

its shown only if the person has a call capable device and they are online. not sure if you have to be subscribed to their presence too

(otherwise you can't see that they're online, so if online-ness is a criterium, then yes, you have to.)

Why would online-ness be a criterium here?

moparisthebest, disco#info in order to obtain "can the contact even do this" information.

and XEP-0115 / 0390 to obtain that information efficiently

jonas’: ugh that's terrible

(disco#info needs a full JID, you only get those when you're presence-subscribed)

also I think there used to be an IQ-based call flow which obviously also required a full JID, but I think these days we have JMI (jingle message initiation) which also works with bare JIDs.

Why shouldn't we be able to call anyone just like we can message anyone? If they don't answer or aren't online they'll see the missed call later

moparisthebest, if their clients don't support calls, they'll not even see the missed call. ✏

If the client can't see that they have a JMI supporting client, then send a message that someone tried to call?

This detecting that a call can be answered seems like a huge misfeature

https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#where-is-the-call-button > The contact needs to be online. This is indicated by a colorized (not gray) send button. Depending on the recipients setup you might be able to send a regular message first to wake up the recipient’s device. (In the future Conversations might gain the ability to do this automatically. There is experimental support to remember and display the A/V compatibility of the last seen device when the contact is currently offline.)

I understand all the legacy reasons but those aren't applicable today

and no tor. and needs presence

For example say you want to call someone using an iPhone, you have to: 1. Have them on your roster 2. Know they are using an iPhone 3. Send them a message to wake it up 4. Press call very quickly

This is somehow acceptable?

vs a phone number where I can just... Call it?

moparisthebest, yeah, pretty much. Unless you use Snikket.

(where the assumption is that you only use snikket clients -> call button is always there)

moparisthebest, flip it and think about sms or other phone features other than calling

like you can't just fax anyone, or sms landlines etc

you *can* sms landlines.

no, becasue nobody has landlines anymore

here you get a robovoice reading you the text message

it is very confusing.

Tbf until very recently there was a high chance that your iOS contact didn't have calling support

s/landline/voip/

So displaying a call button would have been misleading

Zash, I'm about 80% sure that the robovoice thing even happened at a time where we still had ISDN

which is "close enough" to landline.

anyway, point is that messaging is the original core feature of xmpp, so it's unsurprising that it always works, while calling doesn't

> Zash, I'm about 80% sure that the robovoice thing even happened at a time where we still had ISDN Can confirm.

JMI with a fallback <body>I'm trying to call you</body> would make some sense tho.

Zash: you can absolutely text or fax any phone number

can you

Why shouldn't I be able to call any JID

but is it sensible to do so?

I do recall talking to fax devices, it wasn't fun.

sure, but like a JMI to someone who doesn't have a call-capable cilent, it goes into the void

but I knew a guy who could at least get past the first pilot tone stage once.

Ok, so if they don't get an answer or response they'll text? What's the problem

by whistling

> If the client can't see that they have a JMI supporting client, then send a message that someone tried to call? Clients could do this ↺

moparisthebest, maybe they will, maybe they won't think of it but try again and try again and then heartache and hurt results.

Or display a message saying "hey they might not see you called, send a message?"

that would be a good idea actually

I like that.

Isn't that already there?

(in Conversations)

Zash: when busy yes

But yes this could potentially be expanded to 'we never got a 'ringing' response to our jmi'

It'd be interesting to know how things react to a JMI with fallback body

inb4 robo voice reading the fallback body out loud

I don't disagree with moparisthebest it's just that we had a/v calling in Monal for literally a week or so

I also remember some bit of UI guidelines that oppose conditional widgets, saying it should always be enabled.

Hard to understand when or why it does or doesn't show up otherwise.

Task for council: Deprecate Disco

oh no

> It'd be interesting to know how things react to a JMI with fallback body fallbacks everywhere!

Wasn't the unwritten plan to use the bind2 device tracking to somehow persist disco#info ?

> Wasn't the unwritten plan to use the bind2 device tracking to somehow persist disco#info ? Yes

+1 on being able to just call with a "seems like this failed, send a text message?" kind of prompt. i've noticed that only monal allows me to do something like that, and found it pretty handy

https://github.com/snikket-im/snikket-server/issues/86 is relevant here... the UX of sending JMI to a user with no call-capable devices isn't ideal

But I generally agree that hiding the call button is not good UX either, users get so confused when it's sometimes there and sometimes not

and sometimes when it's not there it would actually work (thanks to push notifications), and sometimes when it's there it won't work (because a device recently disconnected, or whatever)

Yeah, just try to call. The worst thing that can happen is the call going to the void but having no call button to at least try is annoying. I had this when my wife used Monal (with call functionality) for a short while when she couldn't open my messages on snikket iOS and switched temporarily to Monal. I knew she had a call capable device but couldn't call her and my local simcard had no credit to call her via phone.

As an analogy, my phone also doesn't hide the call button when the other person is in area without connectivity. Having a failed call is IMO less confusing than a disappearing call button.

> As an analogy, my phone also doesn't hide the call button when the other person is in area without connectivity. Having a failed call is IMO less confusing than a disappearing call button. 100% agreed. the call button disappearing makes me worry that my STUN/TURN setup broke.

i know it essentially boils down to the same thing if the callee truly is not available, but just the general experience of there not being a call button is very off

> 100% agreed. the call button disappearing makes me worry that my STUN/TURN setup broke. STUN/TURN is not involved before you start calling.

Tho it can be smart to start with that before the call gets to the point where you might need it, for SPEEEEEEED

But how do you predict that the user is going to call contact XYZ soon?

I mean start the STUN/TURN stuff at the same time as the JMI goes out, but nothing stops you from doing it before that.

OK, makes sense.

> Task for council: Deprecate Disco Roughly agreed, it's almost always the wrong thing to use nowadays, at least with clients ↺

This was (apparently not 'clearly') a joke

I hope "deprecate disco" is intentionally exaggerated. It's clearly between useful and essential for many things, but it is (currently) not ideal for client-to-client feature discovery, indeed.

:)

Without disco, XMPP is just faster email with angle brackets! :(

I assumed it was at first, but moparisthebest's response had me worried about Council :P

Task for council: Improve Disco with Disco ball.

Then we can boogie like no other.

I don't think new protocols have been utilizing client-to-client disco for many, many years. Calls has been an exception, and given that Conversations was somewhat alone when it first implemented the "new calls" I don't think that was wrong

Jingle is pretty old by now tho

But now we're just past the tipping point, e.g. with Monal's latest releases

disco is clearly needed. a recent example would be figuring out what transport to use for p2p file transfer (with Conversations, but nobody else, supporting webrtc datachannels)

Jingle being '166 is quite a bit before Carbons '280 and MAM '313

how you use that information in the UI is a different question

So I think it's safer now than ever to just assume the other side supports calls. Sensible error handling, smart servers, and a potential future persistent disco mechanism will all improve the UX further.

> I assumed it was at first, but moparisthebest's response had me worried about Council :P Hehe no that's why I said "roughly", I think we are all on the same page here ↺

yes disco where it makes sense, but it no longer makes sense for client features (ever?)

(or at least whenever you aren't talking directly to a full JID that is online, which is surely most of the time)

Disco is useful though.

Disco disco disco. I'm getting curious about what this means

Disco again!

Just get down and boogie with it.

I beg you to tell me what this means :D

topgun: tl;dr you ask a remote JID the features it supports

Perhaps not directly within XMPP does its use shine, but with the extendable portion of the protocol, it's much appreciated.

> topgun: tl;dr you ask a remote JID the features it supports Nice ↺

Alex: Memberbot told me voting has begun, but doesn't talk to me anymore after I sent a "yes".

Ghosting

;-(

Ok, it came back to me. :)

If you love them, let it go... and if they love you too, they'll come back.

Memberbot is online for our current XSF application period Q1-2024: https://wiki.xmpp.org/web/Membership_Applications_Q1_2024

> Alex: Memberbot told me voting has begun, but doesn't talk to me anymore after I sent a "yes". I have your votes. When memberbot starts up the first time for voting it takes a long time until it gets responsive. Too much stuff to process on startup ;-) ✏

What does it have to do on startup?

lots of pep updates, Disco etc...

and I run it on tiny hardware

🤣️

And offline messages like yours

^^

I like the "feature" that it proactively tells you about voting when you messaged it when it was offline. :)