Modern XMPP project discussion - 2026-03-05

I think that is just the brainspace people that first came up with the terms had. The default for MUC is also "conferences." as in SIP phone conferences.

so obviously a participant isn't permanently in the phone conference

and it is notable to add that MAM was added much later to group chats, and for a long time it really was like legacy IRC.

erebion: it's a UI thing and a historical oddity. Most apps (including most mobile apps for XMPP) show the real member list, at least for private groups where it has one, and don't have this "X has left the group" nonsense

Desktop clients are a bit behind in that regard I think

In a public channel where you don't become a member though, if you go offline, the channel really does have no record of you (except any messages it may have in the history)

This is different to Matrix, where you do actually persistently join even public channels, and remain a member of the channel by default even if you never log in again

This is one reason a lot of public Matrix channels have larger participant counts than public XMPP channels

I think Matrix has a bot or some mechanism to remove participants that have been inactive for some months

Which was added to try and clean up some of the old participants

> I think Matrix has a bot or some mechanism to remove participants that have been inactive for some months normally it doesnt. But it can be configured ↺

> erebion: it's a UI thing and a historical oddity. Most apps (including most mobile apps for XMPP) show the real member list, at least for private groups where it has one, and don't have this "X has left the group" nonsense the real member list, meaning those with membership status? ↺

Yes

right. monocles does show a member tag and put the nonmembers below. Gajim does that too but it's hidden behind a popup

Really in a public channel, people who are not members are something more like "guests"

Tidying this up is one of the goals of GC3

i mean we're all guests here except for the 5 of you, lol

> Tidying this up is one of the goals of GC3 were you trying to simplify membership and roles into one thing? ↺

Yes, roles aren't very useful

well, hope that means I can join chats without announcing my presence. I'm thinking if xmpp make it easier to not use presence/roster list for things, it'd be nice

though, I hope pseudonymous MUCs can still be kept?

Yes definitely. They are one of the nice features that XMPP has that most others don't 🙂

hey, with occupants IDs and messages IDs being common nowadays, has anyone thought of refreshing LMC so that: - messages could be corrected beyond just the last one - how far/how old would be a room setting and up to the admins ?

Some clients are already doing that (allowing corrections beyond the last one)

The limitation was never really in the protocol, so not much has to change beyond the XEP title, and some consensus

But not many people think it's a good idea to allow everything to be infinitely editable

can't say i agree but i do see why

I think most mainstream messengers (except IIRC Telegram, which went infinitely editable), have a time limit such as 2 hours or 24 hours

> But not many people think it's a good idea to allow everything to be infinitely editable which is exactly what I wrote, it could be shoved sideways as the MUC configuration and become a room admin concern ↺

Not exactly, as the server/MUC isn't really involved with corrections

> I think most mainstream messengers (except IIRC Telegram, which went infinitely editable), have a time limit such as 2 hours or 24 hours Clients could just indicate that the message was changed, perhaps even show the original message. No need to prevent it. :D ↺

Even if it scrolled out of view already?

> But not many people think it's a good idea to allow everything to be infinitely editable i think it's a good idea as long as you keep all versions ↺

> Not exactly, as the server/MUC isn't really involved with corrections MAM does, right? ↺

No, corrections are just regular messages as far as the server side is concerned

> Not exactly, as the server/MUC isn't really involved with corrections changing that would seem like a good idea? It appears we have a bit too much undefined behaviour at the moment ↺

rom1dep: what's undefined?

a client may send a LMC for a non-LM, and other clients may do something about it, or not. The practical outcome seem rather underspecified and problematic

> No, corrections are just regular messages as far as the server side is concerned but can the client can distinguish between message-as-corrections and normal messages? ↺

Yes

All the logic is in the clients

Nothing about the protocol needs to change for any of this

then it's all good. clients just show what they wanna show

Exactly

And allow what they want to allow

> Nothing about the protocol needs to change for any of this nothing needs to change unless we desire something better ↺

why wouldn't it be desirable to let the MUC be the arbitrator of what can be corrected or not?

i don't think the LMC XEP (besides from its name and initial intentions) needs to change anything. Though it could, in certain cases, be a good idea to implement some MUC logic to deny some messages (?)

but idk if it should be done via another XEP. Well, it may if you want some standardized toggles in the admin panels

the LMC XEP may benefit from covering the aspects pertaining to the MUC rejecting a correction, would things be heading this way?

A MUC could already reject corrections if it wanted to

But that doesn't seem like a massive improvement to me

It makes things less consistent, as it would behave differently across different chats

So more confusing for users

> but idk if it should be done via another XEP. Well, it may if you want some standardized toggles in the admin panels wdyt about these standardized toggles for group configuration, MattJ? could this something to be extended upon maybe in GC3? ↺

What, exactly?

> It makes things less consistent, as it would behave differently across different chats I don't think it would make things any worse than we have it now with, e.g. moderations that are dependent upon occupant ID? In this case, the client would disco the MUC config to know under which circumstances messages can be corrected, and adapt its UI accordingly (you wouldn't get an "edit message" icon where it's forbidden) ↺

But occupant-id is practically universal at the present. It was a ramp from 0% supported to 100% supported. Adding a configuration option for standard behaviour just means it will always be inconsistent across chats forever.

maybe that's where our perspectives diverge, IMO, message correction isn't "standard behaviour", it's context (i.e. MUC)-specific

It'd be fair to have some MUCs where message correction is forbidden (e.g. IRC style, or for bridges interop), and others more "lax"

We already have bridges, including IRC

nobody is arguing with that

They work without rejecting corrections

Wouldn't they work even better (i.e. in a user friendlier manner) with the clients not offering corrections where it's unreasonable?

Mapping XMPP corrections to `s/old/new/` messages sounds fun

Bridges could do that

This discussion is going nowhere. Is this somehow controversial or stupid?

You're just mostly going against XMPP's idea of "use known, ignore unknown"

> They work without rejecting corrections Afaik biboumi recently added that. ↺

> You're just mostly going against XMPP's idea of "use known, ignore unknown" I don't see how

>> You're just mostly going against XMPP's idea of "use known, ignore unknown" > I don't see how Corrections beyond the last one just won't be recognized by non-supporting clients, so there is no need to do anything

You don't need to get anyone's permission in here to implement your version of the idea. Just make it and ask for forgiveness.

Waiting for someone else's approval is silly when you can just implement it and be told no if it really is a 'simple feature'.

Even if it isn't adopted as an XEP, you can still do it. XEPs are to standardize capabilities, but it's a lot easier to argue what the standard can be with a proof of concept in hand ✏

Otherwise people will just gripe and bemoan the work involved because they have to do that work, hence you beating them to it.

The argument 'feature is no-go because other clients need to implement it' is absolutely silly. Clients don't have Jingle. They don't have MIX. They don't use Pub-Sub. Those features still have XEPs. The clients are *already fractured*. The OMEMO implementations across clients are out of synch.

Grow some balls and let people improve things, don't shoot them down unless they lack graceful degradation. We have mechanisms to send server error messages, we can implement one for 'you tried to correct this message but that service is not available for this message'.

What else is extensibility for?

I am not saying the principle of 'use simple things that work' is incorrect, but that's no excuse to prevent or discourage hacking the protocol to do *new* things, as long as the old things are still there.

It's ridiculous.

I'm going to entertain this idea: https://chat.modernxmpp.org/paste/7a162860-b9bf-4f3e-993f-8662fc96d8f5

I fail to see how a modification like this will significantly 'degrade client compatibility' when in reality the 'degradation' is exactly the intended feature being described - limiting a client's ability to modify MUC data based on a server (not client) derived condition. ✏

> I'm going to entertain this idea: > https://chat.modernxmpp.org/paste/7a162860-b9bf-4f3e-993f-8662fc96d8f5 Sounds like an extreme overengineering

I don't see how this would introduce compatibility issues either, because 'requesting to correct' is the same as 'trying to correct', just with a different context for the amount and type of data the client has to send.

> Clients could just indicate that the message was changed, perhaps even show the original message. No need to prevent it. :D It'd be nice if clients had UI for displaying / diffing edited messages like that, and maybe display a little warning if it's been edited weeks later or something. Personally, I find time limits on editing messages a bit odd, but I can see how it could be abused. Sometimes it is nice to be able to edit old messages if you can pin informational messages, for instance. ↺

If you think it's overengineering, that's cool. If it's transparent to your client, it's not your problem, but the implementor's problem, on the implementor's own software. You won't feel it.

I generally dislike stuff that requires server's participation, so…

Deciding what messages can or cannot be sent through a MUC is decidedly a matter of server participation.

It's a descendant of access control.

This is just a specifically scoped example of access (read-write) control.

this is just an extra error? not sure why you'd need a correction request query

it would not work for 1:1 though

As in peer to peer?

yes. private message, 1:1 chat

I can't think of a reason that the clients would need to restrict each others' ability to correct messages, except to tell the other client 'hey, I'm bridged to something that does not properly handle corrections'. I believe the degradation commonly used here is just to show the correction as a new message.

However, you could also have clients impose limits on how many corrections they would accept at one time, I could see that being useful.

it might

but idk how it wouldn't work with existing error mechanisms for MUCs. Just send something like "Unable to correct messages (please retry in 20 seconds)"

the rest you could do is to write a server module that accepts business logic from a config file, I think

Exactly what I was thinking.

The reason why I supposed a correction query is for cases where the user has not begun writing a correction, and the client wants to save them the trouble of writing the correction before finding out they can't correct their message to begin with, especially if it's lengthy. Generally speaking, clients having a way to discover controlled capabilities instead of falling back on try-fail is nice.

Try-fail still works just fine, but it may incur extra effort on the user and send unnecessary data down the line. ✏

Anyway, this is all just speculation unless someone's feeling creative. :p ✏

i see your point. a bit complex to get it working though. probably will never be a xep

Jeez. Talk about corections, I'm a typo machine right now.

I should probably get some sleep. ✏