Please review and answer the following 2 questions on the images in this discuss post.
Do the images accurately reflect system behavior of showing profile information?
Do you have any suggestions to mitigate impersonation?
To verify another user that has added you as a contact or set to display their ENS name in chat, you need to go to Profile view. Only in Profile view you will see their pseudoanonymous random name (a.k.a unique identifier) that you can use to verify they are who they say they are. At the same time we want to avoid having an overload of information inside a chat.
Background
To help people understand what information they expose when participating in a chat or adding people as a contact, itâs important to have an accurate picture of this. Such that we can communicate it at various points in the UI, create transparency, awareness, and help people make informed decisions.
In detailing UI designs it seemed an overal picture of this profile information structure was missing. The images below provide this picture. They are intended to show in what cases a random name, chosen avatar, potential ENS name is exposed given our current implementation.
Onces accurate it can be used to:
Make sure Status UI reflects actual system behavior.
Explain people how Status helps you manage your online identity.
Assess impact on the UI whenever we want to introduce changes to this structure, for example adding ENS name as a chat name.
Profile states
The current profile settings allow to create 3 different states. While new designs for Profile are in progress, these states remain the same.
Image #
State
Image 1
New profile - Random name and random avatar
Image 2
Profile with a name specified
Image 3
Profile with a name and picture (avatar) specified
Image 4
Profile with a name, picture, and ENS name specified
Image 1 - New profile
For both contacts and non-contacts random name and avatar are exposed in profile view and chat.
Image 4 - Profile with a name, picture, and ENS name specified
When an ENS name is specified (i.e. verified), it can be set to be displayed in chat or not. This is a global setting that would change the view for both contacts and non-contacts. If ENS name is set to display in chat:
For contacts and non-contacts, ENS name is exposed in chat.
For non-contacts, ENS name, random name, random avatar are exposed in profile view.
For contacts specified name, specified avatar AND random name is exposed in profile view.
Bonus 1. Trusted contacts marked in chats with a checkmark
To add even more power to the contact list in Status, we can rename it to âTrusted Contactsâ and add a check icon next to their names so that users could notice that
We might add a feature so that users could rename other users themselves. For example i can rename âFluffy Banana Fenderâ to âJarradâ or âCrypto-trader from Berlinâ
My gut call is that itâs too much info. Hereâs my 2 wei on the matter, as a user and âonboarderâ.
Problem 1: a person can have multiple ENS names (I have three yet still get messages meant for Barry in 90% of the cases someone tries to @ barry)⌠This fluid ENS system needs to be communicated clearly because if weâre communicating to people that a change in random avatar or random name means something is fishy, that smell will stick to changing ENS names, too.
Problem 2: Four identifiers (random name, random avatar, ens name, own custom name). FIVE with custom nicknames. This fails the mom test so hard. Given that there is no way to find someone via their random name (which is a shame, it should be a two way conversion so that my mom who would no doubt remember that Iâm Sarcastic General Blackrussianterrier could message me by typing that in as recipient), I recommend random names be killed off despite the novelty effect and entertainment value. One confusion vector less.
To further simplify things for end users, I would recommend removing the option to set your own name and instead require a stake to get an identity in this system. Essentially, make ENS === own custom name change. That way your own nickname becomes something you identify as to others, carrying extra weight IRT switching willy-nilly, in addition to the cost of ENSing again. The additional investment required to build a profile that way will also make people more likely to stick around and use the app, similar to how you feel guilty for not playing a subscription based MMO 24/7 after pre-paying a month.
Custom nicknames can then serve the purpose of a typical contact list, which is a must have in Status, and your contacts can put your full name (non ENS nick) in there. Random avatar provides a semblance of security, and until a user registers for ENS theyâre shown as 0x53af..5532, similar to the âyouâre just a droneâ psychological warfare that Twitter wages against its egg-users, forcing them to identify more and more, or LinkedIn with their âprofile completion %â.
Yeah, I tend to agree that as soon as we will be able to show a ENS username/usernames everywhere, there is little sense to allow a user to set a custom name for themselves.
A bit trickier thing is that we donât have a reverse lookup in ENS, so I know that bruno.<blah> is 0xabcabc.... but I canât know that 0xabcabc.... is bruno.<blah>. Iâm not sure where this limitation comes from except for the implementation details and if we want to change that.
Maybe @petty or @ricardo3 know more on that or can at least point to the right person.
Iâll join the ENS party here, I donât find the other identity layers that interesting or necessary once ENS is fully baked-in.
With the nicknames, I donât mind it since its optional but if anything, I think we should be reducing the complexity and not pile another layer on top of what we already have.
As for the trusted contacts, there is something about the positioning of the check icon that reminds me of verification badges you see on social networks. Iâd like to take a stab at this design myself to see if it canât be more customised to fit its purpose.
I also like the idea of leaning on ENS as the only form of user-friendly identity. It mitigates impersonation. However, the major issue with this is that ENS is a public record and exposes the wallet. So we need a burner wallet to make this safe.
If we have consensus on this ENS-only approach though, perhaps we can justify more effort behind reverse look-up.
I disagree that we should require users to stake for identityânot least because it adds friction during onboarding that we havenât solved.
I think we could instead offer different tiers of ENS registration. A premium, paid option ( stateofus.eth) can offer benefits such as opt-in default display, access to exclusive chats, etc. A free option using another domain can be offered during onboarding without benefits.
Agreed with @Bruno that custom nicknames would be nice to give the user control over other peopleâs presentation, in this ENS-only scenario.
Thanks Oskar for bringing that gh issue link.
Its technically possible to make a reverse registrar for ens usernames, it can even be used the common " address" reverse.
This comes with some downsides:
A list of usernames should not be public in the blockchain by default (or, encouraged by dapp).
Once a username is revealed in reverse registrar, it will very unlikely to ever be forgotten, even if removed from state.
However, is impossible to prevent someone from reverse registrar their address, for example, my ens username is reverse registrar to resolve to my wallet address, which is derived from my Messaging Public Key.
If you derive the address from the status contact code that is resolved from my ens usernames you will get the address set in addr.reverse.
My suggestion is that:
For contacts the username is provided/saved just like the âgiven nameâ, but ens usernames are verified in-chain, so if a contact provides a bad username it would ignore (or warn/block user).
For public/group chats, it would be possible to announce the username at room, or include it as payload in message data, so other users listening would be able to fetch it, if they want to.
Fetching the username costs a bit of âinternet data connectionâ so, would be better to have this configurable.
The reverse registrar can be implemented aswell, but we should discuss the exact use case of it, such as for someone who exactly wants to publicly reveal their username to the world.
This is an interesting idea. I agree that having nickname/display name, ENS and randomly generated name is very complicated for users. I would prefer we stick with just two: a one randomly generated name you get when initially creating your account + and an ENS name. Thatâs all.
Agreed. IMO since ENS is a big part of the identity stack itâs perfectly OK that it costs, thatâs part of the whole reason we have ENS names. The name + ens name + random 3 word device ID + contact code is a whole lot of confusion for anyone.
Sounds like we have consensus on reducing to max 2 name options.
So per @naghdyâs suggestion, you onboard and receive a random name. And this is the only name you have and display to other users until you register an ENS name.
I like that that reduces the complexity around contacts and display names as well.
Another quick thought - what if we allow a user to claim a canonical ENS when first registering which would be uniqueName.stateofus.eth, as in, sarcastic.general.blackrussianterrier.stateofus.eth, and then users can register additional names as desired?
This adds the option to âverify your account in a decentralized wayâ, increasing outward trust of an individual, while still letting them have disposable addresses and identities etc derived from this main address thatâs the basis of the randomly generated name.
You basically claim the randomly generated name for yourself, we keep the entertainment and novelty value of random names, and thereafter people can actually contact us through those so theyâre not useless, without even setting up a special resolver. All other ENS names then essentially become aliases.
First of all, thereâs a reason we got to where we are. All names had a function at some point. My intention is to fully understand to what extend any new proposal meets the requirements that have come up in the past. Iâll prepare a mapping for this and willl follow up here.
Proposal
For now this seems to be the proposed solution:
Provide the user with a generated random name, giving some control by allowing to generate up to 3 times
Provide the user with the option to register this random name for free, with the benefit of allowing others to find you by this name
Provide the user with the option to register another name in addition or instead of the random name at a cost, with the benefit of allowing others to find you buy any chosen name (albeit nickname or given name)
Registering any name is optional to avoid any gas (ETH assets) requirement.
Implications
People who do not own ETH will not have a way to show their real identity to people they trust within Status. They will need to inform people outside of Status what their random name is and others can only start a chat with them after reconizing them in a public or group chat or after having received their Contact Code outside of Status.
Pseudoanonimity of the random name use will likely be reduced further as more people might call out who is who in public chats as we reduce the ways to display a chosen name.
Implementation
As @rachel flagged. ENS as default has privacy implications at the moment. This is not necessarily an implication if we can implement registering names with a burnerwallet and yet verify ownership lateron.
I see this as the biggest challenge that flows from the proposal. @ricardo3@gravityblast do you have any thoughts on how we can allow this?
ps @oskarth the idea of ENS registration tiers starts to feel an aweful lot like Network incentivization. @petty this happened while you were out:) Itâs a long thread but would really love to hear your thoughts on the security of the proposal.
Currently I donât see how you can make it free, i.e. not requiring any ETH due to gas costs. If you need some crypto, what would be the advantage of not charging for it in SNT? If we definitely want to support non-SNT use case, the better way IMO is to support other ENS top level names, not devalue our already too cheap stateofus.eth names.
This approach makes sense to me.
It might also be worthwhile to consider optional recipient-based tagging, so you can tag people based on what you remember about them. E.g. this person does UX, or they won this sticker competition, they scammed me on Teller Network once, etc. IIRC Reddit has something like this. Even simpler: Contacts phone numbers works this way, e.g. âMomâ or âDentistâ.
What if we let people claim their random name as ENS by interacting with a dapp, and status covers the tx fee for the first, say, 10k? This removes the gas barrier, only registers for free those who are serious about this, and facilitates easier communicating and identification, in addition to demoing how dapps work in status?
The dapp can be a simple form which issues a tx from a back end wallet meant for this. The TXs can be bulked and transmitted separately (once per hour or so) to stay secure and not have a hot wallet on a server. It would take a bit of manual labor but I think itâd be worth it at this early stage.
I should rephrase: I meant free registration, not free from transaction costs. This is why registration should always be optional (third bullet).
Iâm all open to a discussion on the exact tiers. Personally, have not made my mind up on that. At the moment I would say there should be a free registration (not transaction) of random names to enable finding and being found. I like your âsearch by tagâ alternative for that @oskarth!
At the same time assuming that contacts will remain more persistently throughout upgrades at some point, I imagine finding and being found through (random) name registration (i.e. âfreeâ registration of random name), will become less of a must have an more a nice to have IMO; Eventually finding and being found will become a 1-time/infrequent action for each new friend. At that point Iâd be happy with random name use until, burner wallet, ENS registration.
Thank you all for such constructive feedback. Here is the updated profile structure.
First of all, there are two major changes:
No more âchosen namesâ (i.e Andrei Mironov). There are only account names (i.e Defensive Attractive Woodborer) and ENS usernames (i.e andmironov.shateofus.eth)
Nicknames. Everyone seems to agree that a nice way to provide a way for users to identify each other for free might be nicknames. Nicknames behave just like names in your phoneâs contact list. You can specify a name for any user. (i.e rename Defensive Attractive Woodborer to âMomâ). Nicknames are only visible to those who have specified them.
Other than that:
if a user has specified a profile picture, it will be visible only to that userâs contacts;
A user can be multiple ENS usernames registered and a way to choose the âprimaryâ one;
Account name in chat has a grey color, nicknames are black, ENS usernames are blue and always start with â@â
Nicknames have the highest priority in chat. Account names have the lowest (I added @emily777 a nickname âMomâ so i will see her messages as from 'Mom")
Suggestion by @yenda: Have contact groups with âTrusted contactsâ as a default one, to provide a way to grant access to certain profile information to a specific group of contacts;
Great job Andrey!
One clarification for your pictures, it is possible to add nickname for profile event if there is no ens name right?
And also maybe we could do the same with picture, so you can change the pictures for your contacts same as nickname , in that case there will be no question why i see his picture but not her or who can see my pic etc
I like the idea of trusted contacts, but Iâd be a bit careful about using a word like trusted unless it is meaningful in a cryptographic/security sense. What does it imply exactly? In my world, a useful distinction might be something like âverified key identity in real lifeâ, but this is not a flow we currently encourage too much (e.g. compared to Briar).
As @ricardo3 mentioned, anyone who looks up the ENS username can see their associated wallet that staked for the name. One possible option that might fit into this is to use some specific derivation path (pinging @michele, @gravityblast) in the new key management scheme to be only for registering this name, so it doesnât leak information about other transactions (other than how money initially got into that account).
I am for minimizing the amount of names a user has w.r.t a single account⌠we should stick with what is initially given (random as it is WAY better than the contact code) and then an ENS name (which drives SNT use anyway). One questions is how do we deal with names outside *.stateofus.eth? Can someone opt into setting their name as a already registered ENS name outside of that domain, or do we just ignore it in profile but still allow for it to be resolved in search.
As for helping to deal with the ability of identifying people, I really enjoy the option mentioned of nicknames, as that information is local to an individual and can be edited on their device at will. The random name is fun, for a little while until you need to keep track of a lot of people, any serious userbase will require that they be able to tag users with a nickname just to manage keeping track of people.
