Profile information Structure - Please review

Reverse lookup for ENS usernames issue: https://github.com/status-im/ens-usernames/issues/80

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.

3 Likes

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.

We’re currently working around the lack of reverse look-up by having users take action to verify their name. Designs in progress, bottom right-ish: https://www.figma.com/file/TNCyHKtR3sx5EL6YznFWUa4O/Profile?node-id=510%3A3116 (cc @igor)

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.

3 Likes

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.

image
image

image

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:

  1. 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).
  2. 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.

1 Like

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.

3 Likes

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.

2 Likes

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.

5 Likes

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.

1 Like

Very constructive responses here! Thank you @Bruno @maciej @rachel @ricardo3 @naghdy @oskarth @Hutch. Time to consolidate.

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.

1 Like

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”.

1 Like

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:

  1. 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)

  2. 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")

Group%209
1
Group%2013
1

Yet to be decided/discussed:

  • Renaming “Contacts” to “Trusted contacts”
  • 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;
4 Likes

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

Thanks Andrey!

Yes, sorry, did not add that to the graph

maybe we could do the same with picture, so you can change the pictures for your contacts same as nickname

nice idea, let’s think about it!

1 Like

Great stuff @andmironov!

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).

Sorry I’m late to the party.

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.

2 Likes

Thanks for taking a look @petty!

Sounds like there’s two paths to persue on order to mitigate pushing for ENS registration in Profile.

  1. Accepting verification of non-stateofus domains
  2. Allow staking ENS in Status with a derived key pair (burner wallet idea)

As long as we’re in Beta I would say neither path should block implementing the profile structure. As wallet exposure through ENS is an existing issue we would be exposing, not introducing.

For 1, I don’t know what might be blockers here and if this is a feasible route. @yenda Can you speak to this? Is it that we wouldn’t be able to verify ownership?
For 2, we should have a clear timeline of Profile and Key management implementation @igor @guylouis Any thoughts on when either work is planned for implementation?

  1. Accepting verification of non-stateofus domains

Allowing users to use non-stateofus domains should be perfectly feasible. However, I think they should be treated differently—and that .stateofus.eth domains should have preferential treatment in UX—in order to incentivize their use.

  1. Allow staking ENS in Status with a derived key pair (burner wallet idea)

This is the most crucial issue on the table, imo. This whole key derivation, multiple wallets/burner wallet topic is a mammoth thing and perhaps requires a swarm to carefully consider and steer implementation across Status. WDYT @igor @guylouis @hester?

In the meantime, I agree that we’re not blocked. @andmironov’s updates look great, and we should be able to go ahead with this simplified two-name structure, in whatever order of priority we determine for Q2.

I plan to draft up a post on swarm specific prios for chat & browser here on Discuss by EOW, so that we can go into those Q2 discussions with good context.

4 Likes

I agree for the mammoth :sweat_smile: and some dedicated discussions and/or swarm on this are needed! starting point being Musings on Key Management (aka 'Whisper Decoupling')

As for which path should be used for the burner wallet that will stake the ENS name, my take is that it’s also part of a more general discussion of which paths we use for dedicated purposes. It could be following EIP1581 sub-purpose field (https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581.md), or maybe using the cak: field proposition in EIP1775, but right now there are still intense discussions (with andreaf & michele heavily involved) about these two to figure out which paths unique dApps and specific purposes use.

See discussion here https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742
and discussion here https://github.com/ethereum/EIPs/pull/1775
and the EIP itself https://github.com/ethereum/EIPs/blob/6671145ef6561a79e4e484fb26629ad2dd8b18a9/EIPS/eip-1775.md

2 Likes