Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New way to handle "anonymous" accounts #546

Open
JohnXLivingston opened this issue Sep 16, 2024 · 2 comments
Open

New way to handle "anonymous" accounts #546

JohnXLivingston opened this issue Sep 16, 2024 · 2 comments
Labels
enhancement New feature or request Searching Sponsor Issues that needs a funding to be done. Type: Moderation

Comments

@JohnXLivingston
Copy link
Owner

JohnXLivingston commented Sep 16, 2024

Using XMPP anonymous accounts has various inconvenient:

  • moderation is difficult
  • if users open 2 browser tabs, they will in fact use 2 separate accounts (and there will be nickname conflicts)
  • following a user's message history could be difficulte, as the backend account changes everytime.

So, we should implement some kind of "semi-anonymous" users:

  • an API on Peertube to request an account
  • the account is created on a special Prosody component (with some restriction, as for real XMPP anonymous account: can't speak with the outside world, ...)
  • credentials are sent to the browser and stored in session storage to be reused
  • accounts are deleted after inactivity

This is also related to #487

Warning: this should not break backward compatibility: instances that have not the livechat up to date should still be able to connect

@vencabot
Copy link

Something I would suggest for consideration is that XMPP components can send and receive messages under any account name without needing to create an account on the Prosody database, so maybe that would be even easier. It's what I've been doing for my chat bridge, and it works very well. The process is like this:

  • Component sends a Presence status to the group-chat room (Multi-User Chat) of 'Available' -- but instead of supplying its own JID in the 'from' field, it supplies an arbitrary JID of your choosing (something only Components are allowed to do).
  • That JID is now considered Available in that MUC and the Component will receive any messages that are labeled 'to' that JID.
  • The Component can send chat messages 'from' that JID 'to' the MUC.
  • When you want for that 'account' to leave the MUC, you just send a Presence status of Unavailable to the MUC 'from' that JID.
  • The Component will no longer receive messages addressed to that JID.

Perhaps it would be easier in some way to create and delete accounts on Prosody, but in case you weren't aware of this mechanism of Components, I wanted to bring it up.

@JohnXLivingston
Copy link
Owner Author

Perhaps it would be easier in some way to create and delete accounts on Prosody, but in case you weren't aware of this mechanism of Components, I wanted to bring it up.

But here, there are real users behind the anonymous accounts. So i can't use this.
For the record, i already do something very similar for external accounts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Searching Sponsor Issues that needs a funding to be done. Type: Moderation
Projects
Status: No status
Development

No branches or pull requests

2 participants