Profile information Structure - Please review

[hester]

Thanks for taking a look @petty!

@petty

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

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?

[rachel]

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.

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

[guylouis]

I agree for the mammoth and some dedicated discussions and/or swarm on this are needed! starting point being Status.app

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 EIP ERC App Keys: application specific wallet accounts - EIPs - Fellowship of Ethereum Magicians
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