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?