XMPP Service Operators - 2020-03-24

Hey guys

I think it's especially important to promote xmpp now of all times

Everyone is looking for a way to communicate online with their friends and family

Hopefully they choose XMPP and not some proprietary system

> Everyone is looking for a way to communicate online with their friends and family tom: Yes via audio- and videochat. Not many xmpp-clients and xmpp-servers support that. I think conversejs and monal does. For textchat xmpp is fine, of course.

Which really sucks

Because the protocol is there

Server supports it

Most clients suck though in regards to jingle support

server’s don’t need any special support for A/V

it’s all clients

a TURN service associated with the XMPP server helps though

jonas’: And in practice? Can most people connect to each other without TURN (so it's p2p then, isn't it?

Jeybe, in the worst case, audio via IBB will work (albeit probably with terrible latency)

jonas’: IBB?

In-Band Bytestreams

Jeybe, also, many home routers support UPnP which allows to temporarily open ports for this type of stuff. Clients may not, though.

normally you’ll want to avoid TURN if you can either way, because it adds latency and is costly to the server operator. P2P (possibly with UPnP) should be preferred for small conferences. For large conferences you need something else entirely (like Jitsi Videobridge)

> In-Band Bytestreams So exchanging data via the xmpp-server / xml?

yes

Ok

Another thing, does the specification for audio- and videocalls include conferences with multiple persons or is it 1:1 only?

that’s a very good question

I actually don’t know and it looks as if it does not include multi-user calls ✏

in which case we should kick the jitsi people to get their stuff spec’d, because it’s actually quite sane

https://xmpp.org/extensions/xep-0340.html

that’s the spec ^

Focus agent... sound like the thing jitsi uses

Is it?

yes

Their implementation is jicofo.

» [00:14:55] <jonas’> a TURN service associated with the XMPP server helps though turn? Isn't that supposed to be what the socks5 bytestream proxy is for?

» [00:18:30] <jonas’> Jeybe, also, many home routers support UPnP which allows to temporarily open ports for this type of stuff. Clients may not, though. Unnecessary if they have ipv6

tom, that’s (still) a pretty big *if*. And also many home routers will filter traffic on IPv6 by default, too.

so you still need UPnP to punch a hole in the firewall

» [01:11:51] <jonas’> tom, that’s (still) a pretty big *if*. And also many home routers will filter traffic on IPv6 by default, too. That's stupid

it’s not

given the insecurity of the default windows installation

and given that you still easily get an open rpcbind server on a fresh debian installation

without even knowing

I’m pretty thankful for this type of sane defaults

The rest of the world shouldn't have to suffer network wise because microsoft shits out another terrible proprietary OS

you also don’t want your mdns server being used in amplification attacks

note that all my examples except the first are 100% unrelated to windows

also, android phones

» [00:19:24] <jonas’> normally you’ll want to avoid TURN if you can either way, because it adds latency and is costly to the server operator. P2P (possibly with UPnP) should be preferred for small conferences. For large conferences you need something else entirely (like Jitsi Videobridge) what XMPP clients support av? And just one-on-one or multiuser?

Does jitsi integrate with XMPP?

tom, Jitsi and Jitsi Meet are completely different pieces of software.

Jitsi is a more or less normal XMPP client which does jingle and can be used for 1:1 calls I think

Jitsi Meet is a highly integrated web conferencing suite which uses XMPP in the backend as signalling protocol (via BOSH)

Jitsi Meet doesn’t federate in the default setup though, and I don’t think it can be made to federate

Is there any way to use jitsi meet without a web browser

no

well, yes

there are android and iOS apps

Webrtc never works right

it does ✏

What about a linux or bsd program

» [01:16:12] <jonas’> it does not in any of my testing

used jitsi-meet extensively in the past week, and we had virtually no issues

jitsi-meet does a few things to make webrtc more stable

Last time i had to use something webrtc based it took 53 tries to get it working

like including a turn-like server

I'm really sick and tired and webapps

we all are

it works though

It doesn't work

in contrast to all other free xmpp-based conferencing solutions.

have you tried jitsi-meet?

if not, you can’t say whether it works or not

No, what i'm saying is that webrtc doesn't work

webrtc works just fine

like jingle

it’s essentially the same thing.

Taking 53 tries is not what i call working

sure, that’s what you get without a turn server

because p2p sucks

because firewalls and nats

It wasn't p2p

what was it then?

webrtc is p2p by default.

The browser itself

if you say so

Almost all browsers besides google chrome or firefox (which you wouldn't use if you cared about privacy) turn off webrtc by default because it's implementation is so shotty

And leaks info when using proxies

There really needs to be a solution, that isn't just cramming more bs into a web browser

That probably should never be there in the first place

Which is what i'm asking

tom, wanna contribute WebRTC support to some desktop XMPP client?

So that it is compatible with Jitsi Meet?

I don't want to contribute to anything with 'web' in the name

Too bad then.

What about SIP

Why do SIP when you have Jingle already?

I've had videocalls before with a very old version of linphone

Conferences too

Dial-by-direct-ip

I’ve also had that using Ekiga, but they were fully unencrypted, required another channel to coordinate on, opening a port on each participants’ router, and were generally not very user-friendly.

(the part with the port could be solved by UPnP support in the tools)

But they did work

And work they did without 2gb+ of ram

With modern XMPP clients, using Jingle for signaling and WebRTC for the transport, that can change.

If you put aside your blind hate for a second and look at what it actually is.

That is, a nice set of extensions above RTP.

(Plus a JavaScript API, hence the name I guess, but you can totally ignore that part.)

Oh god

Javascript

Link Mauve: have you ever used tox?

Or qtox

No, but I’ve read about their architecture, why?

Well i was just thinking and asking around

For anyone who has ever had a non-web-browser videocall before. It was something i am sure we had back in the early 2000s

Sure, many XMPP clients also had that.

Apparently not. I guess we are in the stoneage still when it comes to videocalls. Standards suck (or at least implementations) so every company is going off and building their own thing

Empathy, Gajim, I think Psi.

Jitsi of course.

Link Mauve: psi 'has it' but it doesn't actually work. It's just a reference point

But i'm talking about multi-party

Part lines for video

*party

Multi-party is harder to do, especially if you want it to be efficient on the clients’ uplink.

Empathy did it the naïve way for instance, where each participant had a p2p connection with each other.

Link Mauve: I mentioned qtox and tox because that's the only open source thing i have used in recent years where videocalls worked reliabily

That means you send your own streams N-1 times.

tom, IIRC Tox also does it that way, which means it doesn’t scale above a few participants.

Depends on the emitter with the weakest uplink.

In a world where everyone has fiber, it would be fine.

We’re not in that world.

except for the terrible waste of resources

Link Mauve: what if your MANET looked like this: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations

in a world with fiber and working multicast in the internet, now that’d be fun

Your talking UNICAST

multicast in the internet does not work

I know that

But MANETS can be created over an entire region

Town or county

Bridged with VPN tunnels

It would be nice in Cuba, but here in Europe everyone is using Internet with an ISP.

And the batman-adv optimized multicast could ensure effective use of the vpn tunnels

» [02:05:42] <Link Mauve> It would be nice in Cuba, but here in Europe everyone is using Internet with an ISP. It's funny that it's always the regimes with the practically more free internets

I’m sure that the unicast VPN tunnels do not impede the performacne of multicast at all /sarcasm

jonas’: that's where the optimized multicast could come in

Nowadays arm cores are dirt cheap

We could make every node a router

huhu multicast jingleparty over ipsec/something else, *coughs* *buffer*, hi, *buffer*, hello *buffer*, been fun *buffer* :D

Tinc or wireguard

dont cough.. please. or put your hand in front