editorial: Clarify string representation of CACAO signing input

[ukstv]

As noted in ChainAgnostic/namespaces#41 (comment) and ChainAgnostic/namespaces#66 CAIP-122 is ambiguous.

We define address in data model as CAIP-10 account. String representation of singing input though uses plain ${address} field, and ${chain-id} that the data model does not even mention.

The PR here resolves the ambiguity. Data model remains the same, with address being CAIP-10. String representation is clarified to reflect two fields (previously ${address} and ${chain-id}) are derived from data model's address.

[haardikk21]

Thank you 🙏

[bumblefudge]

This seems reasonable to me, since it's the net-same information displayed in a more readily signable message. ChainID will still be illegible in namesapces where CAIP-2 is counterintuitive or not part of the native end-user's mental model, but at the very least this is less scary than having an incomprehensible bit of hash prepended to the address (which is what the EIP editors insisted on in the EIP).

Do we have any sense of how many non-Ceramic implementers this could break, tho? Is it worth adding some mention of the previous state to "## Legacy considerations?" I.e. if Haardik's library and Ceramic's library are being used to generate the messages AND verify them in 99% of contexts, then it's a no-brainer, but it's still worth discussing downstream risks insofar as they're known, making it a major-version change in package managers, etc etc...

[ukstv]

This seems reasonable to me, since it's the net-same information displayed in a more readily signable message. ChainID will still be illegible in namesapces where CAIP-2 is counterintuitive or not part of the native end-user's mental model, but at the very least this is less scary than having an incomprehensible bit of hash prepended to the address (which is what the EIP editors insisted on in the EIP).

Do we have any sense of how many non-Ceramic implementers this could break, tho? Is it worth adding some mention of the previous state to "## Legacy considerations?" I.e. if Haardik's library and Ceramic's library are being used to generate the messages AND verify them in 99% of contexts, then it's a no-brainer, but it's still worth discussing downstream risks insofar as they're known, making it a major-version change in package managers, etc etc...

AFAIK, that only changes wording, not the implementations.

[bumblefudge]

hehe by this i meant, throw currently-conformant implementations out of conformance (and interop)

oh sorry just realized you wrote this before today's meeting :D

[silverpill]

LGTM