search

Joystream / community-repo

A repo for community contribution and documentation
GNU General Public License v3.0
19 stars 73 forks source link

Discord flow to claim Joystream on-chain identities #730

Closed singulart closed 2 years ago

singulart commented 2 years ago

Current state of affairs

  1. Joystream Discord members exist completely independently from Joystream on-chain memberships.
  2. Discord server roles are assigned to users by admin users manually.
  3. Existing Joystream Discord server roles do not cover the broad variety of on-chain roles in Olympia.
  4. There have been instances where malicious users attempted to pretend to be someone from JSGenesis by taking similar usernames (handles)

It is evident that the current state of things is not ideal on many levels and needs improvements. Therefore, we propose the following novel functionality to be built for the Joystream Discord:

Proposed added value

As a Joystream Discord user, I need an ability to securely claim my Joystream DAO on-chain membership (identity), so that I can be assigned custom Discord server roles, and so that other users on Discord can see what role do I currently play in Joystream DAO.

What this means technically

  1. Creating a system of record (a data store) that keeps track of relation between a given Discord user and their Joystream membership.
  2. Creating an easy to use facility (a bot) to enable Discord users to securely claim their membership in Joystream.

A breakdown of the flow steps

  1. Discord user initiates the process by executing a special command: /claim <joystream membership handle> <joystream wallet address>
  2. User is sent a DM with a challenge string
  3. User signs the challenge string in Polkadot App
  4. User sends the signed challenge string by executing another command /solve <signed challenge>
  5. System checks whether the signature is correct, that is, created by an address that the user claims ownership of.
  6. System also checks whether the address user claims ownership of corresponds to the Joystream membership handle provided in step 1.
  7. If the checks in steps 5 and 6 pass, the system stores the mapping between users' Discord handle, their Joystream membership handle, and their Joystream wallet address in a database.
  8. As a final step, the system assigns a user the special 'Identity Verified' server role.

In cases of any error situation, a user is supposed to receive an easy to understand plain text explanation.

Additionally, the system would run scheduled periodic checks to find out which Joystream DAO roles does a particular verified user have: Council Member, Workgroup worker, Workgroup Lead, and so on. This feature gives an opportunity to assign additional custom server roles based on Joystream on-chain roles. These Discord roles may or may not bear specialised server permissions. But, at the very minimum, they would serve as visual indicators of Joystream DAO roles inside Discord, so that newcomers get a perfect impression of the variety of opportunities within Joystream.

Budget breakdown

  1. /claim command - 4h
  2. /solve command - 4h
  3. Persistence layer: tables, queries - 3h
  4. Error handling and unhappy flows- 4h
  5. Additional roles management - 10h

Total: 25h

traumschule commented 2 years ago

Alternative flow:

  1. Send Discord ID tokens to bot address.
  2. Send DM to bot: !claim AccountId.
  3. Bot replies Please send X tokens to bot address (X = random number).
  4. Bot returns all tokens and publicly stores confirmed claim (for example in dedicated branch of community repo).

Security

Attacker would need to (A) forge and intercept direct discord message + (B) issue transaction with someone's key which both together are unlikely unless credentials are compromised anyway. In case attacker responds to public transaction in (1) and claims (2), (3) is impossible without obtaining key or convincing rightful owner to send requested amount of tokens to bot address.

Implementation

  1. Bot listens to transactions
  2. Bot reacts to DM: check for transaction by AccountId and compare amount to msg.author.tag.
  3. Reply to received message in (2).
  4. Listen for correct amount by AccountId, blacklist after n wrong transactions or push commit.
  5. In both cases update message sent in (3).

Estimated effort: 5..10h

mochet commented 2 years ago

Alternative:

This removes all transfers, bot commands and other things and the claim is stored and is public because its on the forum already.

This also removes many components of Discord from the concept, since the bot is effectively just using the forum thread.

Downsides:

singulart commented 2 years ago

@mochet what prevents me from claiming tomato#9464 Discord user on Forum?

singulart commented 2 years ago

@traumschule Couple of questions re: the alternative suggested. Firstly, was it proposed because it's more secure than the original proposal? Secondly, I don't think 5..10h estimate is realistic.. Could you may be break it down like I did? I feel like "pubilc ledger" of the mappings is a good idea, by the way. But efforts-wise, implementing a Git integration is no smaller than a Postgres integration. Thanks for your feedback anyway!

mochet commented 2 years ago

Nothing, but it seems like it would be easier to do the verificatoin aspect on Discord. This way we're removing transactions from something a user has to fully understand before they can participate.

singulart commented 2 years ago

My proposal doesn't imply any additional on-chain transactions. The key aspect of it from the users' perspective is to sign the data (a string) using the Pioneer's Sign tab, which is relatively straightforward thing to do.

mochet commented 2 years ago

My proposal doesn't imply any additional on-chain transactions. The key aspect of it from the users' perspective is to sign the data (a string) using the Pioneer's Sign tab, which is relatively straightforward thing to do.

So the new versoin of Pioneer doesn't include the signing thing AFAIK. In any case, signing stuff (in my opinion) is a more complex thing for very new users to learn.

I believe there will still be a copy of the old Pioneer where they could sign stuff, but I think it would be better to design this in a way that removes as many terms and complexity as possible.

For example, some users may primarily be video makers using Atlas and only the forums and using the Polkadot wallet. I think asking them to learn the signing part may be throwing too much at them (baring in mind the already highly complex nature of Joystream and the governance system).

I am working on an early stage initiative to identify the language that is used for each level of user and trying to minimize what the most basic/new users will encounter, which is why I think using signing is less desirable in the long term. Basically to make the initial education and participation elements really as simple as possible.

mochet commented 2 years ago

Another way to look at it: posting a forum message is basically signing it.

So the Discord bot could just generate a random string/numbers that the user could also post on the forum to verify.

This removes the entire "signing" aspect.

So rather than explain the whole concept of what signing is and having to tell users how to use the signing tool which is quite technically complex, we could maybe reduce it to just "post on the forum" which is practically general knowledge for people.

singulart commented 2 years ago

Another way to look at it: posting a forum message is basically signing it.

So the Discord bot could just generate a random string/numbers that the user could also post on the forum to verify.

This removes the entire "signing" aspect.

So rather than explain the whole concept of what signing is and having to tell users how to use the signing tool which is quite technically complex, we could maybe reduce it to just "post on the forum" which is practically general knowledge for people.

Love the idea with posting on forum, but again, this brings the question of how scalable this approach is. (Imagine thousands of users doing this.)

mochet commented 2 years ago

Another way to look at it: posting a forum message is basically signing it. So the Discord bot could just generate a random string/numbers that the user could also post on the forum to verify. This removes the entire "signing" aspect. So rather than explain the whole concept of what signing is and having to tell users how to use the signing tool which is quite technically complex, we could maybe reduce it to just "post on the forum" which is practically general knowledge for people.

Love the idea with posting on forum, but again, this brings the question of how scalable this approach is. (Imagine thousands of users doing this.)

The forum can scale quite significantly actually. It works very differently to the old one. But in any case if/when we hit scaling issues, then we may just need to custom design an approach for something like this.

I personally don't think Discord itself can scale to that many users beyond just being a notification/information tool. So whether or not 10k users really need to verify Discord accounts, I don't know what the value of that is in the long term (Discord may change)

singulart commented 2 years ago

@mochet Can you sketch out the flow involving posting on forum? It's not clear to me how you envision the Discord side of it.

mochet commented 2 years ago

One approach to identifying a Discord identity using a wallet is described here: https://portto.com/blocto-crypto-blog/discord-blocto-guild/

mochet commented 2 years ago

@mochet Can you sketch out the flow involving posting on forum? It's not clear to me how you envision the Discord side of it.

Process

  1. A forum thread is created dedicated for this purpose
  2. A user posts in the thread using their Joystream membership with their Discord username
  3. A bot on Discord monitors this thread for new posts and then adds new posts to some form of database. The user at this point would be unverified
  4. The bot then sends a message like the below to the user for them to verify (this type of message is described here: https://www.reddit.com/r/discordapp/comments/kqwgqe/i_saw_a_custom_bot_send_only_you_can_see_this/)

image

  1. The user then replies or clicks a button to verify the forum request was valid and at that point they become verified
singulart commented 2 years ago

Still waiting for feedback from @mochet on the proposed flow. Unclear way forward in terms of Story Points estimate. FYI @bwhm @dmtrjsg

mochet commented 2 years ago

Still waiting for feedback from @mochet on the proposed flow. Unclear way forward in terms of Story Points estimate. FYI @bwhm @dmtrjsg

I was going to ask about this to bedeho but it was already bought up here: https://github.com/Joystream/pioneer/issues/1977 (and on Discord more recently: https://discord.com/channels/811216481340751934/813361923172335648/968133015370879036)

In short, there will be profile fields added to Pioneer at some point. I had already searched through the runtime/QN code to see how custom fields could be added but couldn't find an answer.

I guess then its a question of whether to wait for this feature?

singulart commented 2 years ago

Proposal: https://dao.joystream.org/#/proposals/preview/181