Groupchat 3.0 development - 2025-11-19

> I don't know why that would be a requirement for anyone. Mostly I'm never ever offline because I have my phone signed it and it's basically never "offline". Actually I use iPhone now so it uses push notifications and is thus literally never offline i'm absolutely very extremely late so i want to first and foremost apologise for the month+ bump but i would like to chime in on that: i live in a place with bad reception and even moving too much around the building can drop connections, and this to me can happen several times a day, and i don't always have a computer turned on which frankly is a silly ask if the intent is just keeping room participation... my existence is for most practical purposes MUC-incompatible 😢 ↺

svp: is there a MUC related issue this causes you in practise?

It's ok to drop connections for a bit you'll resync when you connect

only with muc though not with 1:1

Unless you have offline messages or mam? But anyway the topic is MUC and next anyway so I don't think 1:1 is relevant

nope not then either see my message in xsf@ a few days ago

Do you have a point or what?

that with the way mam currently works you can't reconnect and sync, fixing this for MUC only won't help most normal people

Seems wildly off topic

you trying to police the channel certainly is

it's perfectly on topic, muc doesn't exist in a vacuum, you can't have one "this is how you don't lose messages" for MUC and then a contradictory way for 1:1

I think we are all on the same team here, all want XMPP to work well for everyone, and no one wants to lose or miss messages

Why is it an issue to loose connection in 1:1 or muc? I don't loose messages either way thanks to mam.

Even before mam this wasn't a problem, true. But I don't think that's what svp was asking about

> Why is it an issue to loose connection in 1:1 or muc? > I don't loose messages either way thanks to mam. you do if your server or your contact's server reboots or has a network hiccup ↺

In some corner cases its possible, yes. Far from a guaranteed loss.

neither of those are corner cases though, just normal things that are guaranteed to happen often

But now I understand, you want *that* xases to be fixed for 1:1 and groupchat. I would be already satisfied if the sending client gets the same send error as one 1:1 in these cases. ✏

Also not related to connection stability on your client. Which is what the question was about

I'm running a server from behind residential ISP and they have these network issues very regularly, so I can tell it's not rare. It'd be even more commonplace with the number of people selfhosting snikket Currently these kinda 1:1 messages are lost, but still got logged to MAM. It'd be nice if they're are somehow re-sent, and even better if they show up with the origin server ctime ✏

I think prosody has some stuff for unreliable s2s.

It is mainly ejabberd that expects s2s to be nearly uninterupted

But s2s is an entirely different topic from mam.

Kris, iirc that's not true? Wasn't ejabberd eagerly closing s2s if unactive?

Thanks, I might check out prosody. I'd say with MUC's MAM, at least you get a single source of truth if your messages are delivered or not. With 1:1 it's kinda based on whether the other party chooses to send a receipt or not

I run prosody from home too and it doesn't have anything for that either

with what svp said (a c2s issue): I do get long periods of room joins when switching networks, so I get where theyre coming from. It'd be nice to skip these operations and go straight to pulling from the channel's archive as need be

> But now I understand, you want *that* xases to be fixed for 1:1 and groupchat. > > I would be already satisfied if the sending client gets the same send error as one 1:1 in these cases. it's already "fixed" for groupchat by the archive being remote, just not 1:1 which could be solved the same way ↺

> I'm running a server from behind residential ISP and they have these network issues very regularly, so I can tell it's not rare. It'd be even more commonplace with the number of people selfhosting snikket > > Currently these kinda 1:1 messages are lost, but still got logged to MAM. It'd be nice if they're are somehow re-sent, and even better if they show up with the origin server ctime if they got logged to mam how are they lost? ↺

> I think prosody has some stuff for unreliable s2s. s2s smacks. it's optional but supported ↺

>> But now I understand, you want *that* xases to be fixed for 1:1 and groupchat. >> >> I would be already satisfied if the sending client gets the same send error as one 1:1 in these cases. > it's already "fixed" for groupchat by the archive being remote, just not 1:1 which could be solved the same way sort of. unless the message fails to deliver to the MUC in the first place due to s2s failure ↺

> with what svp said (a c2s issue): I do get long periods of room joins when switching networks, so I get where theyre coming from. It'd be nice to skip these operations and go straight to pulling from the channel's archive as need be stratself: so I'm curious what you mean here. What is "long periods of room joins" ? ↺

>> I'm running a server from behind residential ISP and they have these network issues very regularly, so I can tell it's not rare. It'd be even more commonplace with the number of people selfhosting snikket >> >> Currently these kinda 1:1 messages are lost, but still got logged to MAM. It'd be nice if they're are somehow re-sent, and even better if they show up with the origin server ctime > if they got logged to mam how are they lost? singpolyma: theyre logged to *my* MAM, but never received by the other party ↺

>> But now I understand, you want *that* xases to be fixed for 1:1 and groupchat. >> >> I would be already satisfied if the sending client gets the same send error as one 1:1 in these cases. > it's already "fixed" for groupchat by the archive being remote, just not 1:1 which could be solved the same way so all participants check whether their msg is registered on the remote archive, right? just to confirm. ✏ ↺

>> I'm running a server from behind residential ISP and they have these network issues very regularly, so I can tell it's not rare. It'd be even more commonplace with the number of people selfhosting snikket >> >> Currently these kinda 1:1 messages are lost, but still got logged to MAM. It'd be nice if they're are somehow re-sent, and even better if they show up with the origin server ctime > if they got logged to mam how are they lost? singpolyma: theyre logged to *my* MAM, but never received by the other party ↺

ah, ok. and you get smacks confirm from your server but no end to end confirm since they never get it. makes sense. I'm curious if the prosody s2s smacks would help you. of course the other server needs to support it as well

>> with what svp said (a c2s issue): I do get long periods of room joins when switching networks, so I get where theyre coming from. It'd be nice to skip these operations and go straight to pulling from the channel's archive as need be > stratself: so I'm curious what you mean here. What is "long periods of room joins" ? this is more of a clientside issue. Gajim sometimes takes too long to rejoin a room when I turn it off and on again. But it'd be nice to decouple presence from joins just so one doesnt need to perform such things. ↺

and as to present its case, my lagged message from the other account finally got sent :')

Well what Gajim shows as "rejoin the room" includes all kinds of different things at the protocol level. Most of the time is in the MAM sync usually

but yeah I guess you can't send until the presence flood is done? there's probably not good reason for that honestly, so maybe a consideration for GC3

yeah, amongst other things (like presence being necessary for moderations..)

> yeah, amongst other things (like presence being necessary for moderations..) no sure what kind of presence you mean here? ↺

you don't need the abuser to be present to moderate/ban them, for example. modulo app bugs

>> yeah, amongst other things (like presence being necessary for moderations..) > no sure what kind of presence you mean here? I believe once you turn off presence broadcast for everyone, you can't see the abuser's JID in a MUC I think we discussed this earlier, and one of the workaround was to send it to mods anyways despite what the roon says ✏ ↺

oh sure, some of the presence broadcast remove stuff can be buggy because it's not used often. I don't know if there's anything protocol level there or not but the implementation is a big heavy handed in some cases I hear

> ah, ok. and you get smacks confirm from your server but no end to end confirm since they never get it. makes sense. I'm curious if the prosody s2s smacks would help you. of course the other server needs to support it as well may I ask which module is this? gonna seek help later in the prosody room anyhow ✏ ↺

mod_smacks. It's automatically loaded onto mod_s2s by default these days.

> mod_smacks. It's automatically loaded onto mod_s2s by default these days. 👍 ↺

also, final thoughts. I think it'd be nice to have something like Matrix's `origin_server_ts`, so messages have some sort of "suggested" ordering. Kinda offtopic but that can benefit both grouchats and 1:1, though ✏

Messages are ordered by the groupchat server

The order is how they were received. They also carry a timestamp when the client send them, which can be quite different. I don't know matrix. Ordering with the matrix may be harder I would guess?

> The order is how they were received. They also carry a timestamp when the client send them, which can be quite different. > > I don't know matrix. Ordering with the matrix may be harder I would guess? are those client timestamps ever used for anything? I'd say they can prescribe order I think matrix sort "events" by origin_server_ts once all the sync magics complete, so it'd have a reasonable timeline ↺

Yes, "eventually consistent" is the key frase. ✏

>> I think prosody has some stuff for unreliable s2s. > s2s smacks. it's optional but supported ejabberd has s2s smacks also, but neither server persists the session across restarts ↺

>> s2s smacks. it's optional but supported > ejabberd has s2s smacks also, but neither server persists the session across restarts 🤔 ↺

we have a collection of partial mitigations with a ton of known holes and no real fix :'(

meanwhile email solved this decades before XMPP was created which is kinda a shame

> Yes, "eventually consistent" is the key frase. thats a nice rationale. But when my message get stuck in network hell and takes 30 minutes to send to a channel (which might have moved on to another topic), I'd get confused people and an "eventually inaccurate" timeline ↺

At the time, XMPP was intentionally not having that "fix" since the idea was to be instant messaging not email :) Even today, I'm not sure I want my message arriving two days later

Yeah, but it would be probably good to have servers respond stronger to not being able to deliver messages.

Like how email servers send "can not deliver receipts". ✏

>> The order is how they were received. They also carry a timestamp when the client send them, which can be quite different. >> >> I don't know matrix. Ordering with the matrix may be harder I would guess? > are those client timestamps ever used for anything? I'd say they can prescribe order > > I think matrix sort "events" by origin_server_ts once all the sync magics complete, so it'd have a reasonable timeline Yes they are. In the conversations client you'll see new messages in the order of the server when you're currently looking at the chat, and will get it sorted by client send time, when you're coming back to it from elsewhere. That's good that one can see the message from a day ago that got stuck, otherwise we would never notice it since its scrolled away ↺

Right now it is quite easy to miss.

> Like how email servers send "can not deliver receipts". s2s smacks should do this I think? failure to resume session should return errors for undelivered stuff ↺

>> are those client timestamps ever used for anything? I'd say they can prescribe order >> >> I think matrix sort "events" by origin_server_ts once all the sync magics complete, so it'd have a reasonable timeline > Yes they are. > In the conversations client you'll see new messages in the order of the server when you're currently looking at the chat, and will get it sorted by client send time, when you're coming back to it from elsewhere. > > That's good that one can see the message from a day ago that got stuck, otherwise we would never notice it since its scrolled away coming back as in, rejoining? I'd like to have some sort of "missed messages" indicator, though I know it's only for ~~nerds~~ powerusers ↺

Clients could implement it.

> Clients could implement it. 👍 ↺