-
Notifications
You must be signed in to change notification settings - Fork 175
Add new method eth_signTerms #7
Comments
This got +1's but never actual maintainer momentum, so I've opened an EIP: |
With |
This may be fine to implement as hoc like this. In the EIP, it was pointed out that recognizing email like mime headers could allow Ðapps to specify their terms render strategy. This could be non destructively added though, so it doesn't need agreement, it can just be added and supported. That said, if I say MetaMask adds something like markdown terms when given a mime header specifying it, and Ðapps adopt this format, other clients might want to add support, and maybe wish they'd chimed in on what that format looks like. But even then, I agree, this could be a sort of additional functionality on the normal eth_sign. |
In that linked EIP it was actually you who already convinced me no new method was needed, mine types could be added. If we agree on that format tentatively, I would call that the current proposal of this issue. Maybe I should reopen with that topic? |
Closing this, because I consider it basically solved by |
I've seen an increasing number of Dapp developers asking how they can allow web3-enabled visitors to authenticate by signing a terms of service to register.
This would allow a site to verify account ownership, without costing any gas fee, and allowing off-chain relationships to continue.
The reason this is different than the other current
sign
methods, is that it would be implied that the contents to be signed are human-readable text, (maybe styled, like markdown) so that web3 browsers and wallets can display the site's terms with the specified encoding, before hashing, prefixing, and signing as usual.Anyone else interested in such a method?
The text was updated successfully, but these errors were encountered: