Description of feature:
Implementing the "muc#roomconfig_presencebroadcast" feature to configure which roles in a MUC will have their presence broadcasted.
Initial implementation:
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.
Motivation: (Why?)
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!
Zash
on
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/>.
Changes
tags Patch Status-Accepted Milestone-0.12
Lance Stout
on
Ahh, the scansion tests are awesome!
Updated patch:
- luacheck passes with no warnings
- scansion passes with no errors (25 ok)
I ended up needing two new parameters added to publicise_occupant_status:
- prev_role
- force_unavailable
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.
Description of feature: Implementing the "muc#roomconfig_presencebroadcast" feature to configure which roles in a MUC will have their presence broadcasted. Initial implementation: 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. Motivation: (Why?) 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/>.
ChangesAhh, the scansion tests are awesome! Updated patch: - luacheck passes with no warnings - scansion passes with no errors (25 ok) I ended up needing two new parameters added to publicise_occupant_status: - prev_role - force_unavailable 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.
Merged as https://hg.prosody.im/trunk/rev/7b602e13c3b6. Thanks!
Changes