XSF Discussion - 2024-01-15

Is there only one xmpp talk at fosdem?

And only one day of the realtime room?

Correct

Hey all, here's my personal collection of XMPP specifications that have been lost, and I wish would have been given a chance

https://disroot.org/upload/065a5017-15c1-7c64-8910-75781cc2b090/Lost_XMPP_Specifications.zip

Do you have a summary that's not a zip file?

mmm zip file uploaded by stranger in the internet, I'm sure gonna click that :-)

Right :)

Here's the summary: https://paste.debian.net/hidden/2fcd44db/

I'm curious how these came to be "lost"

I am currently implementing pubsub of user media (audio/video) streams in XMPP using WebRTC-HTTP Ingestion/Egress Protocols (WHIP/WHEP). I wrote an XEP to document what I am doing. If anyone is interested, please have a quick read. Reviews, feedback or comments will be appreciated. The primary use case is broadcasting. https://igniterealtime.github.io/openfire-broadcastbox-plugin/xep/xep-xxxx-user_media_streams-01-01.xml

Dele Olajide: is this supposed to be an alternative to e.g. video streaming in say, Discord, Twitch, or YouTube?

Because I'm working on a similar project that is not XMPP-related

> I'm curious how these came to be "lost" They are archives of lost specifications I took from the wayback machine, originally listed on http://hancke.name/jabber/ ↺

>latex : is this supposed to be an alternative to e.g. video streaming in say, Discord, Twitch, or YouTube? I would say complimentary rather than alternative as most video streaming services will support WHIP and WHEP at some point.

I'm unfamiliar with this WHIP and WHEP

What does it do?

I'm not a fan of using HTTP for real time communications, because TCP is too slow

HTTP signalling protocol for Web-RTC using single request and response of media session data. See https://www.meetecho.com/blog/whip-whep/

I'm quite new to working with WebRTC. Mainly because there doesn't really exist a meaningful server implementation I can immediately deploy, so sorry for any confusion. I hope the media stream isn't transmitted over HTTP or TCP but iirc WebRTC uses some kind of UDP transport, doesn't it?

That article is still confusing to me. I don't know why HTTP plays a role at all here

I have deployed media streaming servers that use RTMP and SRT, neither of which require HTTP. In fact, RTMP has one of the most standard ways to access content from a client like VLC, which is still very experimental within SRT. With WebRTC, there doesn't seem to be any standard way to access a stream

WebRTC defines how two parties can connect to each other, but it requires a signalling protocol to help those parties exchange the necessary information before the WebRTC stream can be started

Hmm

Well, that confuses me. But I have seen real implementations of WebRTC that intrigue me, like for example there's a screen sharing web app called screego

I don't know of any WebRTC server that can be directly consumed with something like ffmpeg

Most WebRTC solutions seem to require an entire web browser

I wish to make video streaming accessible to native computer programs and to be accessible to ffmpeg directly. SRT and RIST seem to support that, but I'm having trouble wrapping my head around WebRTC

Because they mostly use HTTP to a web server for signalling and use the browser's built-in WebRTC implementation to establish the media connection

In XMPP audio/video calls use XMPP for signalling, and most implementations use libwebrtc for the media connection

Is that how Jingle works, or is it different?

The signalling is done via Jingle, yes

SRTP and RTMP showed their age at the last FIFA womens world cup streaimng service. The high latency made coverage of penalty shoutouts very painful with radio coverage. This has trggered an uptake of real-time low latency media streaming using Web-RTC

The signalling is stuff like "here's where to send/receive your UDP packets", and "here's what codecs I support"

> SRTP and RTMP showed their age at the last FIFA womens world cup streaimng service. The high latency made coverage of penalty shoutouts very painful with radio coverage. This has trggered an uptake of real-time low latency media streaming using Web-RTC SRTP and SRT are two completely different protocols ↺

**SRT** not SRTP Too many acroymns 🙂

I'm currently hosting an SRT video streaming server for me and my friends, as an alternative to Discord's Go Live feature. FFmpeg, VLC, and mpv can take SRT streams directly. It's really neat. Latency can be very low, but this depends on codec configurations (most of my friends misconfigure their OBS)

If the codec has been misconfigured, latency is about 1 second

If the codec has been configured for real-time low latency, the latency is about 200 ms

Which seems like it's as fast as WebRTC, but with an actual standard signalling protocol (being SRT itself)

But I'm planning on totally rewriting my current streaming server, because the SRT server software I'm using is unmaintained, has memory corruption bugs, high CPU usage, and is written in ugly C++

I feel like I'm the only one in the world running a real SRT server capable of handling multiple streams from multiple users

Imagine Icecast but video and low-latency

Unfortunately, I'm not releasing this server to the public. My ISP is too shitty

And SRT streams consume quite a bit of bandwidth

With my new server software design, I'm planning to implement multicasting so other nodes can mirror the streams ✏

There used to exist one other public video streaming server, which used nginx-rtmp, but the owner of said server has gone homeless and had to take the server offline due to severe financial issues (it ain't easy living in America)

Now there is no public video streaming server. Not any that I know of anyway

The RTMP server I'm talking about is nuegia.net. They hosted XMPP as well and often used the two in combination with Mumble to provide a full free software stack for instant messaging, voice chat, and video streaming

Unfortunately it's down due to the unfortunate financial reality that plagues the United States

I'm really intrigued by what a lot of new WebRTC-based solutions are trying to do, but a lot of them require a web browser and that really bothers me

I love using my trusty media player https://mpv.io/ and I don't want to replace that with a web browser

Tge 'Web' in WebRTC is misleading, afaik it's a profile of a collection of other standard protocols and codecs

and in that sense, having some standards for the signalling (even if over HTTP) will make it possible for non-browser apps to support them

Perhaps WebRTC can be used without a web browser, but something needs to be able to make it digestible by a media player like mpv or a library like ffmpeg

When the signalling is just some random web app using a custom format, it's problematic

latex, gstreamer already has webrtc support for instance.

How does gstreamer do the signaling part?

Or is that up the the developer?

probably, yeah

That sucks

there's a jitsi thing which uses gstreamer: https://github.com/avstack/gst-meet

I wonder how one could make a WebRTC stream digestible by a conventional media player

Maybe by translating WebRTC to UDP on the receiving end?

WebRTC generally is UDP

Or to a protocol that actually has a standard signaling protocol like SRT or RIST?

Wasn't there also some mechanism that could make WebRTC scale?

In a distributed manner?

Because that's something that RTMP, SRT, and RIST all do not support

>latex : Wasn't there also some mechanism that could make WebRTC scale? Scalability of webrtc signalling can be achieved by using XMPP with Jingle, Rayo or custom protocols. As for media streams, we generally use an SFU (client does the work) or an MCU (server does the work)

What's that SFU or MCU?

selective forwarding unit, and something-something unit

And what is Rayo?

>latex : And what is Rayo? https://xmpp.org/extensions/xep-0327.html

I'm also thinking, does there exist some XEP for an XMPP-based bulletin board?

Because I remember there is an XEP for microblogging. And a more organized form of asynchronous communication is: forums / bulletin boards!

It's better than microblogging in my opinion

it's different use cases

And the current era of Web 2.0 bulletin board software annoys me

I have an itch of writing a custom bulletin board TCP protocol

But at that point maybe I should just use SSH as the modern equivalent of Telnet?

Just use XMPP then you get identity for free 😉 ✏

Libervia has one possible prototype. Really you can do it with just social feed xep

yeah i doubt we need more xeps for a forum interface

isnt forums just messages but long form and with threads anyway :P

latex, an xmpp-based bulletin board could probably re-use many semantics of pubsub, whichs provides you authorization, management, and structuring (see "pubsub collection nodes"). You probably still need a small layer on top, but potentially mostly consisting of defining well-known names (like the entry node to the board)

>latex : does there exist some XEP for an XMPP-based bulletin board? Once upon a time, there was one social web https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-activities.xml https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-inbox.xml https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-relations.xml

They had some interesting ideas. Like extremely granual profile permissions.

smells like a hacker's dream and a UX nightmare

otoh, it sure is nice to have fine grained access control on the protocol level, you can still later decide if and how you want to expose that to the user

> >latex : does there exist some XEP for an XMPP-based bulletin board? > Once upon a time, there was one social web > https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-activities.xml > https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-inbox.xml > https://igniterealtime.github.io/openfire-osw-plugin/spec/1.0/osw-relations.xml Wow, that brings back some memories indeed ! ↺

I had a look at it for Movim back then

flow, I'm decently happy about the separation between avatar and vcard4 permissions tho :)

Zash, sure, not saying individual access control is bad. but, as always, it's hard to find the right balance

and you usally have an idea about where the sweet spot is, after you build something that geared towards one of the two extremes

ITYM after flipping between the extremes for a few hundred years

Hey Link Mauve, will you participate the xmpp summit ?

emus: what makes you think he might not?

Daniel: the statement not sure and no reaction

anyway, see the scam chat

Is there any official xmpp glossary? I'm aware of a few but not an official one.

I know of: https://www.process-one.net/blog/xmpp_glossary/ https://wiki.xmpp.org/web/Usability/Glossary https://docs.modernxmpp.org/terminology/

I don't know who to suggest an additional term to

I don't see the term "whisper" being covered

fjklp: looks like modernxmpp just calls them MUC PMs, probably not good to use that in a modern client though https://docs.modernxmpp.org/client/groupchat/#private-messages it's possible I'm not looking in the right place though, MattJ would know

>looks like modernxmpp just calls them MUC PMs where do you see this?

I don't think I've seen "whisper" outside of Conversations(?)

moparisthebest: I think 'private message' as term is OK. Just don't expose MUC to users.

fjklp: in the link I provided

> moparisthebest: I think 'private message' as term is OK. Just don't expose MUC to users. I tend to agree ↺

Then what should we be calling them, if not MUC PM?

> I don't think I've seen "whisper" outside of Conversations(?) I've seen them referred to as whispers many times, so it seems pretty relevant.

Ideally, it should be possible for people to communicate.

>> I don't think I've seen "whisper" outside of Conversations(?) > I've seen them referred to as whispers many times, so it seems pretty relevant. Both can be true, since many use conversations and forks