Description of feature:
Implementing the "muc#roomconfig_presencebroadcast" feature to configure which roles in a MUC will have their presence broadcasted.
I'm working on implementing this feature. Working, first draft patch available here: https://gist.github.com/legastero/219702bc69724f2e1f03469954547235
This required a few small tweaks in the core muc lib, so filing the issue to gauge upstream interest.
Controlling (or rather, limiting) presence updates for certain types of users is very useful for some applications.
Prime motivation: when implementing a MUC room for chat associated with a live video stream that is expected to have a large number of intermittent viewers, individual presence updates are noisy and not particularly useful.
Additional use case: Combined with voice requests (and auto-approving server handler), it allows for having guest visitors join and view the room chat live, without needing to pick a nick first (or show up as random-guest-####, etc). Picking a nick would happen when the user decides to begin chatting (change nick then request voice).
As always, thank you so much for such an enjoyable project to work with!
Interesting, thanks! TIL muc#roomconfig_presencebroadcast exists.
Patch looks like a good start. Try luacheck for catching some simpler issues.
It would also be good to run it against our integration tests, so check out <https://matthewwild.co.uk/projects/scansion/>.
Ahh, the scansion tests are awesome!
- luacheck passes with no warnings
- scansion passes with no errors (25 ok)
I ended up needing two new parameters added to publicise_occupant_status:
The force_unavailable one is there to handle a room config change that removes broadcast for existing users, but it feels weird having to pass so many nil args to set that final true. There's probably a better way for this.