[Standards] Re: Presence problem in large MUC rooms.

Hi 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. That alone is worth to have a new spec. Then there are other obstacles which would need to be solved - XEPs that depend on presence (Hats, comes to mind) - Discovering the real-jid (Altough unlikely that big MUCs are non-anonymous, the protocol should not make it impossible) If presence would be optional, we also would not need to find a solution to get messages, if the client is not joined, because a join is just 2 stanzas, one to join, one back that join was successful, so very cheap. The other big topic is a refactor around roles and affiliations. I don't think its worth to further add hacks on top of XEP-0045. Desperately trying to salvage a protocol that was design with presences in mind. its relatively easy to create a new MUC protocol which is perfectly backwards compatible. - Send join for new muc standard - Add indication if client wants to receive presence or not (Presence is optional) - If joined with new muc standard, real-jid needs to be attached to each message, if chat is non-anonymous - Revise the Hats XEP to not depend on presence - Add new efficient IQs to get affiliations There are no breaking changes here, a MUC can be operated with both protocols at the same time. And this solves all problems that i know of. Except maybe the refactor around affiliation or roles, but i would say we can live with that if it means MUCs stay backwards compatible. Regards