ENS name: Jeff.eth
My reasons for wanting to be a delegate: Longtime ENS user and advocate. Feel that I will do a good job of protecting the less tangible but still valuable parts of the ENS communityâs culture.
My view on each section of the proposed ENS Constitution
- Name ownership shall not be infringed: (Agree/Disagree/Comment)
Being completely frank, this provision is poorly worded and will definitely result in conflict/disagreement at some point (it already has if you poke around actually). But I think the underlying principles motivating this provision are promising, if we can articulate them better.
First, for ENS names to be useful at all the behaviour and usability of an ENS name has to be predictable and we have to have a consensus about that behaviour that has a high degree of legitimacy and legibility. For better or worse, the existing expectation of many people in the Ethereum ecosystem is that once you designate a single private key (or set of private keys) to control a record, that key has to sign off on any future changes to the record. If you lose the key, too bad. Itâs seen as a âharsh but fairâ approach. But even this consensus has a lot of caveats. Mostly these caveats are about ways that a community, smart contract architect, etc. sets the expectations of the users up front. In the case of ENS names, take expiry. Expiry has been part of the ENS plan from the beginning, and because this has been communicated clearly there is a shared expectation and consensus on the part of most ENS users that this is an acceptable infringement on their âabsolute rightâ of ownership. Or, what happens when there is a bug in the auction process? Maybe some auctions have to be restarted, which is a sort of infringement. But not doing so would infringe on other types of ownership. So I get what this point is trying to say but at the least the word âabsoluteâ is a poor fit here.
Another principle that definitely seems to be intended by this provision is to protect and maintain the credible neutrality of the ENS infrastructure itself. ENS already has a very wide userbase and set of stakeholders, and this credible neutrality is a key part of how all these different users, with their many (and sometimes conflicting) goals/needs can all agree to share one ENS system with its associated standards, tooling, integrations, and so on. But there is no such thing (or no such useful thing) as absolute neutrality. Even the credible neutrality of a system like ENS must of necessity embed some set of actual values to keep ENS worth anything at all to people. These values include things like âwhat is a bug?â or âwhat constitutes a DoS attack?â and so on. These values are mostly implicit in communities like this one, but they certainly exist. Not all of these values can be âenforcedâ but they must all âinformâ certain decisions. A genuinely âtrue neutralâ system is not actually useful. You have to be good to everyone, not just neutral too them. And determining what that means hopefully involves some widely shared social consensus on what âgood neutralâ means, including how it changes in the light of new information (like changes in the Ethereum platform itself, or new technological capabilities that become available).
And finally, it is a technical fact, regardless of how the ENS registrar etc. are designed, that the ENS system is socially forkable. There are obvious and significant advantages to not forking the ENS system, not least of which is the degree to which many technical integrations with ENS have failed to correctly plan for this possibility. But what we all collectively decide the ENS system is will have an enormous effect on the future usage and usefulness of any particular smart contract that forms a part of it. These means that we need to make a deliberate and ongoing effort to maintain positive and ongoing relationships between as many present and future stakeholders as possible. Doing this well requires continuous communication around how ENS names are changing, problems that users are encountering, and so on. Trust and goodwill are critical elements of a technical consensus. You canât even conceive of an idea of âabsolute ownershipâ of ENS name which would ignore these facts.
In summary, the thing I would want to protect as a delegate is the predictability, legitimacy, and legibility of the consensus around how ENS names work; the good and credible neutrality of the ENS architecture and system in how users and stakeholders are treated; and the positive social trust and goodwill which exists among the present and future set of ENS stakeholders. And if someone can improve the phrasing of this section to better capture that, Iâd happily vote for that version of the text. If not, thatâs what I take this text to be trying to say, if somewhat poorly.
- Fees are primarily an incentive mechanism: (Agree/Disagree/Comment)
This is clearly the existing social consensus around the ENS architecture. ENS is first and foremost a public service, NOT a for profit enterprise. Any divergence from this plan would be substantial: very large issues would have to be at stake to ever consider changing this part of ENS in my view.
- Income funds ENS and other public goods: (Agree/Disagree/Comment)
Again, in broad terms I think this is the existing consensus of what current and future funds are intended for. Developing and supporting a healthy ENS ecosystem first, and then secondarily supporting the broader social and technical ecosystem on which the health of ENS also depends.
- ENS Integrates with the global namespace: (Agree/Disagree/Comment)
The relationship of ENS with global namespaces like DNS is also fairly well established, if incompletely specified in a couple of cases. But again the way of relating to and integrating DNS has been well established and public for some time, so it would take a very substantial issue being at stake for this general viewpoint to be seriously altered, in my view (example: a major change in how DNS is actually used worldwide).
My web3 qualifications / skills:
Incorrigible amateur and interferer in more serious technical engineering. Code literate, security aware, and familiar with most parts of the Ethereum and blockchain ecosystem, but probably not the person you want handwriting a critical bugfix under time pressure for real users. More knowledgeable (albeit still not guaranteed to be useful) in the research department. A long track record of reviewing and analysing web3/Ethereum projects, typically at the design/conceptual/architectural level, though sometimes right down to the code. Knowledgeable enough to be dangerous about most technical things 
Bitcoin since 2010 and Ethereum since before crowdsale. Usually seen on twitter at https://twitter.com/technocrypto/