Limit Each Anonymous Chatter to 1 Occupant (by IP Address)?

[vencabot]

Is your feature request related to a problem? Please describe. The list of viewers in the chat is filled with duplicate (or alternate) names as anonymous viewers return to the chat in a new tab.

Describe the solution you'd like When an anonymous viewer requests to join the chat, their IP address is compared to other users in the chat. If it's the same address, they take over the same occupant ID and nickname (which they presumably had before).

Describe alternatives you've considered Maybe this could be done with cookies, but maybe IP address check would be cleaner. Maybe, rather than taking over the same occupant ID, the old occupant with the same IP address could just be booted, but restricting anonymous users to 1 Occupant could also make viewer Affiliations more useful, etc.

Additional context The viewer list fills up with duplication / alternate names so quickly that it's not really that useful; it might say that there are 19 chatters but it's really just 4 chatters with 5 entries each. The pasted image is actually the most mild case I've seen of this issue.

Thank you so much for creating and maintaining this fantastic plug-in. I've been using it for a few weeks now with great success, and viewers love it. I'm extremely grateful for many of its features and I'm grateful that it's continuing to improve.

[JohnXLivingston]

Hi,

I'm aware of this issue. I'm thinking about another solution these days: replace "XMPP anonymous accounts" by accounts created on the fly, and deleted after X hours of inactivity. So that a user opening multiple tabs will keep the same account.

This will not prevent bad actors to create multiple account, but it will help in the normal use case.

[vencabot]

Thank you for the consideration. Your solution sounds great to me; it sounds like this issue is caused by using "XMPP anonymous accounts," which I'm not familiar with because I know nothing about XMPP. I presumed that the current behavior was like what you described: creating throwaway accounts. It sounds like this XMPP 'anonymous accounts' feature is very convenient; it's a shame that it causes this problem.

I also agree that 'bad actors' aren't really worth worrying about in the short term. It seems like peertube-plugin-livechat's moderation features are fairly strong and rapidly improving.

Thank you again, good luck, and have a nice remainder of your morning!

[JohnXLivingston]

An XMPP anonymous account is an account that meets following:

• no password
• deleted when the user logs out
• can't speak with the outer world (these account are always created on the instance that host the video - for now)
• won't store any data on the server

The issue of having no password is that you can connect two browser tabs to the same account (maybe i'm wrong on this, i recently saw a SCRAM option to open sessions, and maybe it is available for anonymous users).

The solution i have in mind is pretty simple:

• an API on Peertube to create a temporary account, and get its credential
• store the generated password and the login in the browser local storage (i do something similar for "external accounts" that were recently implemented)
• use these credentials so that all your tabs uses the same account, and you re-use the same account if you come back in the X coming hours/days
• delete accounts that were not used since X hours/days (i do something similar for "external accounts", but maybe i should keep these anonymous accounts longer)
• forbid these temporary account to contact the outer world. Or maybe just allow connecting to other peertube instances. The purpose here is to avoid an attacker to generate accounts to connect to other XMPP services that are not Peertube-related, and spam them.

Doing so will make handling anonymous accounts more easy for moderation, and makes a lot of sense with the recent features i'm working on (for example, moderation notes that will come with v11).