Hi, Just to make that clear: I'm all-in on creating the new GC3 protocol, but that ideally would tackle many more issues than just the presence spam (and many of which have already been discussed elsewhere), so the "easy" protocol you had in mind doesn't really do it.
The main reason why I proposed making use of the existing things, is that those are already available and we will be able to get implementation experience quicker. This implementation experience can be very valuable for the GC3 protocol. On Mon, 2026-02-02 at 08:48 +0100, Philipp Hörist wrote: > But thats set by the admin, not by the client. So its not the client > that gets presences spam under control, its the admin that decides if > clients are spammed or not. Which is fine in many cases: Large rooms (especially if bridged from legacy networks that don't have a room-presence logic) produce the same amount of presence spam for everyone. There is always a limit of the amount of presence spam that is bearable to the client. I doubt that this is something that the enduser will want to decide on (no matter if as a participant or room owner), so it would just be arbitrary limits selected by client developers. The question thus is just if those arbitrary limits are selected by client developers or server/gateway developers. Doing it on the server using existing mechanisms instead of involving the client also has the advantage that it immediately is to the benefit of every client, as it doesn't require any client changes. > Then there are other obstacles which would need to be solved > - XEPs that depend on presence (Hats, comes to mind) Sure, this might be interesting problems to solve. But they also need to be solved for GC3 independently. Again, getting the implementation experience on top of MUC and trying different ways how those issues can be solved based on the existing infrastructure is likely easier than starting a GC3 from scratch and having to think about everything from the beginning. Marvin _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
