Groupchat 3.0 development - 2025-02-25

> Retroactively changing the display of nicks seems like a bad idea as it would break all the mentions. If I get this right, the goal is to let (the person using) a client understand which messages are from the same person - regardless of nick changes - and to prevent someone impersonating an absent user by grabbing their nick. ↺

I think this is good. What I don't understand is how this will be accomplished in the UI. ✏

Kev, re presence vs. no presence, what is the story for when you want to display the users present in the current view, but don’t care about the noise of the presence in the other rooms you’re not currently displaying? I always felt like this needs a query mechanism, but never came up with something I’d like to use, for instance basing it on RSM for pagination felt a bit weird.

You turn on the subscription while you're looking at the room.

And immediately receive (a diff of?) the state?

MIX solved this by doing a MAM query where you could give the id of the last state, IIRC. I know that's not going to be popular to suggest, but probably yes, include a last-known ID and get a diff if possible or a full listing if not (a la roster versioning). I've not given that a lot of thought yet (I don't know if Jonas or Matthew have), but I think that's a non-core optimisation (i.e. it doesn't affect the data model or core protocol working out the details later).

The data model it affects slightly, as efficiently computing a diff of all of the presences in a room would be kind of inefficient if the server had to go through the entire stream of presences.

But yes, this can definitely be done later.

I didn't mean the implementation model, sorry.

Right, this is internal details.