Discussion thread for ERC-7946: add uwulink ERC by moodysalem · Pull Request #1043 · ethereum/ERCs · GitHub
2 Likes
Really like the pattern of the programmable mode. Do you think it would make sense to separate this from the encoding part (protobuf)?
While I am not opposed to Protobuf, I see that the pattern used by the programmable mode could be valuable even in a rpc based world.
1 Like
What’s This?! *notices you have a new standard* Some non-editorial comments:
I echo @rmeissner’s comment that separating this from protobufs might be a good idea, but a different reason. Simply referring to protobufs from an ERC is going to be difficult on an editorial level. They aren’t defined in an RFC (or any other approved document source), and that means the reader cannot get a complete understanding of the specification from the ERC itself. As for why we’re very careful about the external sources we allow, see markdown-rel-links. That said, the wire format specification is stored in a git repository, so one could follow EIP-5757 and try to get it approved but YMMV.
On another note, I love this idea. This is a huge advancement over ERC-4804 and its decedents.
As I’m sure you’re well aware, browsers, unfortunately, don’t support registering arbitrary schemes in extensions or with registerProtocolHandler. How would you propose working around that issue?
A particular concern of mine when designing a forward-compatible protocol, is how to handle mandatory new fields in a schema. Say a new version of UWULink comes out, and it introduces an optional field that MUST be understood if present or the request should fail. Does this proposal provide such a feature? Should it?
Question: Was the acronym created before or after the full name was created?
Good question, I don’t have an answer though. For context, websites can register protocol handlers with the browser using the web+ prefix as described here (e.g. a web based wallet like Coinbase’s smart wallet) and in the extension manifest as described here.
I’d consider that a breaking change to the protocol that we should strive to avoid. I can’t think of a good example where we’d need to do this though.
1 Like
Nice proposal, thanks for writing!
Any reason why offchain signature request are not supported?
Would be great to be able to have offchain signature benefit from the one-off flow
Furthermore there is some contrats call that require such offchain signature to be passed in
I thus see 2 thing missing in the proposal:
- Ability to request offchain signature
- ability to pass in result from one signature request of the list in the next calls/signature requests