Hey @Curia this is really needed but… do we think it’s a good idea to have yet another source of truth for the connection between discourse usernames and wallets?
Right now, Karma is doing that with the same mechanism you are using, in the forum thread you linked above. And now you are also doing it.
What happens if the same delegate links the same discourse account to one wallet on Karma and to another wallet on Curia? Which one is right? The latest one?
How do we expect other apps and downstream consumers to use this information in a composable way and discern which discourse username is linked to which wallet?
There are also more robust technical solutions to achieve this right now, for example, I believe this can be done using zkTLS proofs, the way Questbook does using reclaimprotocol.com tech. For example, right now, if you go to questbook.xyz and create an account, you can connect your Arbitrum Forum Discourse username to that Questbook Wallet, and there is a verifiable proof that the owner of that wallet actually controls the linked Discourse account.
In the meantime, delegates could also do something simpler, which is to add a record to their ENS names, specifying their Arbitrum Forum username, like I did on my paulofonseca.eth ENS name.
I believe that this type of delegate information (Name, Profile Picture, Forum account, Delegate Statement, etc), should be as open and composable as possible, which means that it should be onchain. Not behind some API from some service provider. And the easiest way of putting it onchain right now, would be to use ENS records on the delegate wallet. Most ENS records are not verifiable (some already can have proofs like x.com account, github account, etc), but it would be better for delegates to update that info once, in one place, and then all of the apps and downstream consumers would use that onchain source of truth, then forcing delegate to update their name, profile picture, delegate statement, forum username, on Snapshot, Tally, Karma, Curia, and so on…
So, in summary, I think we should try to avoid getting into this kind of situation…