-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make eip authorship depend on ENS #169
Comments
Added to agenda #168 |
I have to agree with you here. I wish there was something better than https://radicle.network/ or https://www.valist.io/ for this problem. |
How would you feel about allowing an Ethereum address as a third option (alongside email and GitHub username) as an option for authenticating authors? I believe you can use secp256k1 private keys for GPG signing. |
@SamWilsn that's great. I will be in favor of this proposal for supporting Ethereum msg signing or ENS as a third option. So long as at least for now people can also still use their email and github to authenticate if they choose so. |
@TimDaub suggest changing the subject to
|
In fact, I'm using ens as the author name |
I support allowing ENS OR an Ethereum mainnet address. I would not support it if it was only ENS. |
ETH mainnet address is fine.It's just that the ETH mainnet address may be a bit long. |
<shameless promotion of my own EIP>With the help of EIP-5219, this can be done with any smart contract.</shameless promotion of my own EIP> |
I guess we need to ask ourselves why we have authors and their GitHub or e-mail address. Author names are there for attribution, and we require a GitHub username for automated authentication. While we can perform manual authentication using e-mail, it really isn't a common practice (nor is it something I'd like to encourage.) You could argue that email addresses are there in case we need to contact an author, but generally speaking the So what benefits does adding an ENS name or Ethereum address bring? For communication, they're pretty useless. There's no standard way of sending a message to an ENS/address, and while some solutions do exist, I don't think they're widespread enough to use in this process, and again, the We could use an author's ENS/address for automated authentication, but as far as I know, there's no tooling to support signing a commit with an Ethereum private key. There's likely even less tooling to support signing a commit with an ENS name. I'd be much more excited about this ticket if someone could demo a signed commit we could use for authentication. If we do want to add an authentication method that doesn't depend on GitHub, why not just make a |
I think this discussion is based on the following considerations.
GH is very handy and in most cases it works pretty well. However, it sometimes suffers from censorship-resistant concerns. So the scenario being discussed might be: for some EIP authors, if GH doesn't work well anymore, do we need some fallbacks |
A data point of how EIP author address has been used: I have been using the email addresses on EIP to reach out to authors for questions, suggestions and invitation of peer reviews. ENS name or mainnet address helps providing a native way to identify an author. It also allow us to depend less on Github account systems which is, for now, centralized. For example, author may authenticate and authorize their commit without requiring a github account. Currently it's still unlikely we move away completely from Github soon, but it's a step closer to a better future of EIP. While it seems slightly premature at this moment to advocate for using ENS to identify authors for now, I think there are benefits when ENS is mature (e.g. when adopted more widely). With the trend of account abtractions, it's possible in the future when everyone uses a smart contract as their wallet and social identity, they might be able to also specify communication channel in their ENS. such as ENS text entries or via something like https://eips.ethereum.org/EIPS/eip-5437
I support either way or both. |
+1 +1 for pgp key as well |
good idea. also Shall we consider a GitLab self-hosted archive to ensure code and EIP are always accessible? |
The text was updated successfully, but these errors were encountered: