feat!(ServiceProviderRegistry): Hex Capabilities

[wjmelements]

Reviewer @rvagg
This allows the user to enter a hex string prefixed with 0x and it will be encoded as bytes.
Hex encoding is good for:

• address
• encoded certificates (feat: Endorsement Certificates FilOzone/synapse-sdk#443)
  We can consider detecting and supporting other encodings.

Changes

If a capability value string is hex, encode the bytes directly rather than as utf8

[Kubuxu]

What about the decode? It seems to me that UI might try displaying garbage or messing (UTF normalisation) with it, resulting in the capability getting corrupted on a round-trip.

[wjmelements]

What about the decode? It seems to me that UI might try displaying garbage or messing (UTF normalisation) with it, resulting in the capability getting corrupted on a round-trip.

This is a good point. Indeed it is hard to know the types of additional fields. Etherscan handles this by showing untyped data in hex by default and providing buttons for the user to decode it via utf8 or bigendian. Let me know what you think!

[Kubuxu]

The issue is as follows:

• user adds endoresment, it gets decoded and submitted on chain (endoresement is valid)
• user wants to modify another capability, this leads to us fetching capabilities, and putting them into JS strings, which corrupts them (https://kagi.com/assistant/43fe3cd4-4ca0-4dee-9b5c-ff122d8b8fa8)
• user submits that edit (endoresement becomes invalid as it was corrupted

I think the simplest way to avoid this, is to keep raw bytes of unedited keys.

[rvagg]

ok, approved without reading the full thread, good points

I think the simplest way to avoid this, is to keep raw bytes of unedited keys

how do you propose to do this? we'd need to plumb through an "edited" status which complicates the UI somewhat

how about just using unicode.IsPrint to figure out if a string has printable characters, if it doesn't, hex it to display it, then the round-trip should ~work. If the certificate happens to be printable then that's fine too, no need to hex for a round-trip.

[rvagg]

Or here's an alternative - do it in the UI, pass all of the capabilities to the UI (whatever's easiest to get a Uint8Array into the browser using the stack Curio uses to pass that), then do a round-trip in the browser using TextEncoder and TextDecoder, if the round-trip doesn't yield the original bytes then hex display the bytes, otherwise the stringified version.

[wjmelements]

I don't think any certs will be printable because they have zero-bytes which decode into the null terminator.

[BigLep]

@rvagg : are the next steps to do the alternative you're proposing?

[rvagg]

Next-step is in the commit I just pushed - it adds a step on the server side that checks whether a field is going to round-trip through JSON & the browser or not without encoding. If it needs encoding it converts it to a 0x string. This should deal with the lossy data issue in this PR and make it possible to put binary data into capabilities, as long as they are represented as 0x strings.

@Kubuxu if you wouldn't mind having a quick look at this if you get a chance.

[Kubuxu]

SGWM