Allow synchronization of user block lists from your main website #23

New Issue

kirsle · 2023-07-17T23:26:19Z

kirsle commented

2023-07-17 23:26:19 +00:00

If you have a website with a preexisting userbase, it would be nice if it could pre-sync who a user has blocked before they enter the chat (so that the blocked profiles might automatically mute one another).

It would be too much data to stuff into the JWT token so this would have to be sent over out-of-band (e.g. by an HTTP API endpoint).

The workflow might be: as your site is signing a JWT token to redirect the user to the chat room, it could also make a post to the chat server to sync your block list over. The chat would hold onto these lists (temporarily, in memory) so when it sees you log on it could automatically apply mutes to the affected usernames.

Some other notes/ideas:

This should probably be done after the "duplicate usernames" issue is resolved (if someone enters the chat twice by JWT token, the chat server appends a 2 or a 3 after their name; instead it might kick off the original name and let the new join take over). Having inconsistent usernames could wreak havoc on matching your block list effectively.
Is the mute feature on chat good for this use case? Or should a deeper block happen where you don't even see each other on the Who List as online at all?
The chat front-end page would also need to know who all you muted for its own front-end state (to show the unmute button, etc.) - if only the server side manages the mute it can be confusing to users.

If you have a website with a preexisting userbase, it would be nice if it could pre-sync who a user has blocked before they enter the chat (so that the blocked profiles might automatically mute one another). It would be too much data to stuff into the JWT token so this would have to be sent over out-of-band (e.g. by an HTTP API endpoint). The workflow might be: as your site is signing a JWT token to redirect the user to the chat room, it could also make a post to the chat server to sync your block list over. The chat would hold onto these lists (temporarily, in memory) so when it sees you log on it could automatically apply mutes to the affected usernames. Some other notes/ideas: * This should probably be done after the "duplicate usernames" issue is resolved (if someone enters the chat twice by JWT token, the chat server appends a 2 or a 3 after their name; instead it might kick off the original name and let the new join take over). Having inconsistent usernames could wreak havoc on matching your block list effectively. * Is the mute feature on chat good for this use case? Or should a deeper block happen where you don't even see each other on the Who List as online at all? * The chat front-end page would also need to know who all you muted for its own front-end state (to show the unmute button, etc.) - if only the server side manages the mute it can be confusing to users.

kirsle added the

enhancement

label 2023-07-17 23:26:19 +00:00

kirsle closed this issue

2023-08-12 17:25:47 +00:00

Sign in to join this conversation.