How to deal with "reserved ENS usernames"

It has come to our attention that the implementation of ENS usernames in the current RC for V1 status app allows for registration of ENS usernames that are the list that the original ENS Dapp forbade.

As this is not pivotal to launching V1, I wanted to capture the majority of the conversation to shelve for after launch.

There have been a few solutions, namely:

  1. remove the list entirely, enable any registration that conforms to current in-app registration criteria (alphanumeric). Broadcast that anything that is a subdomain of stateofus.eth will never be an official channel of Status, and shouldn’t be treated as such. This can be extended to say that anything officcial will come from status.eth and we can have in-app branding on anything with that to reinforce it (this could be a neat thing for Status CCs, tbh).
  2. widdle down the list to be smaller, and increase the in-app criteria to not allow names within that list. This list would be as minimal as possible, and only pertain to Status related things, not various other entities that are currently within the list.
  3. implement the list as is in the app, as the original ENS username Dapp had done, increase the UX of slashing so that people can see when a name is being used, and slash it easily.

My personal thoughts for now:

  • If we keep the ability to slash, regardless of what is available to be slashed, then a dapp for slashing names easily should be created, and a portal to it should be easily available within the Status app.
  • I am reticent to make very large changes to audited contracts without a formal review of the changes.
  • In the name of decentralization and continuance, I am in favor of doing things that require the least amount of “policing” and bias from us, especially in terms of long term maintenance. The community should be in charge of this, and things should be able to exist without the existence of the status organization.

I am in favor of removing that list. The list will always be incomplete and therefore would only give an illusion of safety. It is better to be very clear that a username is just a shortcut for a public key and nothing else, and that it is therefore no form of verification by Status. Never ever in any case without exception.

For official communications if we want an official communication medium we can use status.eth, but with a UX that differs from regular usernames. Although in the past we were strongly oppose to having this kind of communication channel to avoid being compromised. We would need at least to have a warrant canary if we do that.

2 Likes

Eric makes a great point that it is in fact much simpler to establish all usernames as unofficial by default. Instead, we single out the ones that are, if we decide to utilize such names (status.eth, for example).

Eliminating the list eliminates a good amount of manual effort to review and maintain the list, so I’m also in favor.

2 Likes

I am in favor of keeping the list only for names obviously intended to fool people into a misrepresentation of Status.im, Status.im Subsystems, and names used by other systems to represent moderators/administrators.

Regarding the names being incomplete, I changed the design of the contract to allow the change of any slashing rules, including the list of names, minimal size, invalid characters, without having to make a full upgrade of the contract

The reserved names could be upgraded as needed, and later a SNT democracy will be the controller of this rules.

The policing of the reserved list is done by the users itself, that can check if someone is attempting to sue a reserved name to chat, and the upgrade of the list would be done only if really needed.

1 Like