Modern XMPP project discussion - 2024-09-19

howdy. are there any clients currently supporting oauth? see there is a module for prosody https://modules.prosody.im/mod_auth_oauth_external.html but of course clients must support it as well.

muppeth: you mean SASL OAUTHBEARER ?

yes.

i see there is also just oauthbearer module but i guess the same applies.

I'm not aware of any (public) ones. I have a test client I use to test the modules, but that's it so far. The XEP was only published a couple of days ago (XEP-0493), so you now have something to ask client devs for :)

i see.

so pretty much atm clients would have to default to legacy auth.

I don't know if we'll ever push for OAuth to replace conventional logins in XMPP, although I strongly feel that web clients (especially server-side clients, such as Movim) or anything else that accesses your account outside of your own devices, should 100% use OAuth.

I prefer SASL2+FAST for on-device native clients

trying to implement keycloak and looks like it aint that smooth sailing. same as with email.

There are afaik some old out of tree patches for conversejs to enable oauth

Yeah, that's a bit rough and also something (slightly) different

That's why I had to write the XEP - "supporting OAuth" can mean too many different things

Converse.js's support uses (IIRC) a non-standard SASL mechanism, and a third-party component, and it allows you to offer "Log in with [Github|Google|etc.]"

Which is what some people want. The XEP is more for "I already have an XMPP account, now I want to grant something access to it"

There is a lot of protocol overlap between the two use cases, Prosody should be able to support both, but the XEP is only for the second case

I'm thinking of adding a third kind of MUC to https://docs.modernxmpp.org/client/groupchat/#types-of-chat Should be called "broadcast" 📢 where only the owners/admin can publish and the others are muted

It is actually already existing on things like Telegram and Instagram afaik, nicoco should also be able to map it better for some bridges

https://telegram.org/tour/channels

edhelas, yeah, I'm building support for that into the MUC 2.0 draft I'm working on

MattJ in the XEP or more as a ModernXMPP guideline ?

It will be in the XEP, but it will be equivalent to the guidelines (which should still be documented)

Do you have a draft of that ? Because basically in a client its mostly UI things

https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA

There's nothing you need to worry about though, just continue as you are :)

Some serious things going on in this document <3

It's designed to be backwards-compatible with MUC, but much simpler for clients that choose to use it

So instead of joining a room, configuring it with a bunch of options, you just send an iq to create a room with a certain profile, and you'll get the necessary defaults already set correctly

You can still configure details if you want

Ah fun it's a bit what I though about with the pubsub#type and Profiles in https://xmpp.org/extensions/xep-0472.html#profiles

Yeah

Still need to work on that Stories XEP that is "just" a Social Feed profile on top of the base one

How easy would it be to add a new type of room in there

I don't want clients to limit it to only these types and be stuck with that for the next 10 years

pep., easy enough

> I'm thinking of adding a third kind of MUC to https://docs.modernxmpp.org/client/groupchat/#types-of-chat > Should be called "broadcast" 📢 where only the owners/admin can publish and the others are muted I was intending on just having using PubSub feeds to act like 'Telegram Channels', in my experiment of a Telegram-imitation XMPP client (when I get back to it) ↺

arcanicanis, that's kinda what Movim does

although to group it together alongside conversations, rather than be listed under a separate tab/section ✏

Sure, that's just a UI thing

edhelas, which begs the question, why are you looking at this, when you already have pubsub feeds?

It seems like it might be confusing to have both in one app

It'd be neat if PubSub was available in more of the instant messaging-focused clients, as insofar I think Movim may be the only one?

Because it's not the same usage

And some apps like Instagram have both, you have feeds which are articles, and you have rooms that are short messages

Also because there's only a few apps that are supporting Pubsub feeds people might want to use this solution to broadcast information.

Also thinking about bridges like Slidge.

A MUC<->Pubsub bridge would be interesting for that

To me its like putting a square in a circle

It's like trying to publish RSS/Atom feeds to MUC, its works, but really not made for that

I still have to dig deeper into aspects with PubSub, but has there been any well-developed/maintained ActivityPub to XMPP PubSub bridges?

goffi was working on one as part of libervia (it was funded by NLnet)

MattJ is it released ? I've heard about the project but never had the chance to actually see working and packaged versions afaik

> It's like trying to publish RSS/Atom feeds to MUC, its works, but really not made for that I think it just comes down to how it's actually operationally used. But using MUCs for short announcements to +10k users also feels like misusing something ↺

I think polish was still being applied, last I heard

> I think it just comes down to how it's actually operationally used. But using MUCs for short announcements to +10k users also feels like misusing something If you want to publish your blog articles, you use Pubsub If you want to send quick alerts each 20min about possible stock market changes, maybe MUC is wiser ↺

I'm interested in concrete reasons why, though

It's not only about the protocol, its the fact that we have UIs already built on top of it

Sure, compatibility with existing clients, I get that

My current fixation is working on portable identity in ActivityPub, as well as toying with DIDs for portable identifiers, as I'm working in my ActivityPub server implementation. If there's a gap in bridging to/from ActivityPub, I'm very willing to fill the gap wherever needed. I can also bring up new FEPs for extensions that could make bridging easier, if there's any gaps identified.

In a perfect world we would have directly start with Pubsub in the early stages of XMPP and build MUC on top of it, but its not the case

My fixation on the argument is more the protocol level: to my vague understanding of PubSub, the server keeps record of all contacts interested in a feed, and pushes out a message when something new is published; versus with a MUC, where each user has to maintain a connected state to a MUC, and the MUC has to handle all the background noise of connection state messages ✏

arcanicanis, I’ve been using libervia’s AP gateway for more than one year at this point, it mostly works.

ahh, 'formerly Salut a Toi', that's where that project went

I find its usage of Python and the myriad of dependencies a bit bad to work with though.

The Python ecosystem just typically feels like a mess for that

Yeah.

MattJ, no more MUX? Now GC3 (for group chat 3 I guess?)

Kris, yeah, slightly less confusing (and the 'mux' namespace was already taken by some Jingle stuff)

Can colons appear in the localpart as long as they're escaped, or are they totally prohibited? https://www.rfc-editor.org/rfc/rfc7622.html#section-3.3.1 an example of what would be encoded as a username would be like: did:fedi:z8LrnLyDceDz9oKN6iPBCtUupd The context being of having some DID-aware ActivityPub bridge, when the time comes

does it have to be 3 letters? otherwise why not just MUC2?

MUC-X, MUC-NEXT, NMUX, NUX, XUC

Out of curiosity, where did MIX end up? ✏

The edit history seems to be from 2015-2020, not sure if that was just some experiment of replacing MUCs for something different/better

arcanicanis, MIX has some implementations but (IMHO) not a promising future for the open network

If it has, GC3 might be a step in the right direction (since it makes MUC a little more MIX-like, with regards to the data model)

Kris, it doesn't have to be three letters. However "MUC 2" has been a concept for over a decade, and may have some baggage attached. It's also less of a clean break - I feel that people will still see it as MUC1 < MUC2 < MIX

I'd like it to have at least as much of a chance as MIX did, rather than being perceived as something that is obsoleted by MIX before it even leaves the gate

Hoping we might make some progress on it at the sprint this weekend