bytes & link representation in the policy

[Gozala]

Extracting this discussion into own thread https://github.com/ucan-wg/delegation/pull/3/files#r1502988400

Inlining relevant messages from above thread for the context

@expede:

I think the most controversial thing here is that we don't match on IPLD, but directly on JSON (from an earlier conversation that we had). This means no Link, or Bytes. (Technically there's no integers either, but we infer them per IPLD). On the plus side, we don't have to introduce new syntax for these — you can match on bytes by looking at ./.bytes and matching on the base64.

[Gozala]

Pasting my response from the othre thread

Literal(Json)

Can we restrict literals to just scalars ? I think it will get hairy otherwise especially if we start extending syntax in the future.

Select(Vec)

After some implementation experiments I came out with an opinion that I would like to have more clear way to signal whether selection should return one result or many. If you have [] or some form of range like [1:9] anywhere in the path it results in many otherwise one or none.

I think it would be less ambiguous to have JSON pointer selectors and then clause like ['in', '?item', '?list'] to reference (some) children.

It isn't a strongly held opinion, but so far I find it explicit in to be more comprehendible. Furthermore I don't expect to write those paths manually but rather generate them from some DSL which likely will generate will look more like to compile to less ambiguous syntax (with in) than use fancy jq selector.

This means no Link, or Bytes. (Technically there's no integers either, but we infer them per IPLD). On the plus side, we don't have to introduce new syntax for these — you can match on bytes by looking at ./.bytes and matching on the base64.

I think I we need to support bytes natively. We do not use JSON in our UCANs, but rather use a DAG-CBOR which has native support for bytes. I can imagine expressions around byte prefixes / slices and having to deal with base64 string would be awkward.

I think in case of JSON bytes could simply be represented by arrays of bytes. Although in literals I would support idea of using { '/': { 'bytes': base64 } }.

I have less strong opinions about links. Still I would prefer if representation was base encoding agnostic that is to say ./ should probably be bytes and not string or perhaps there is a better way but I really would dislike if base encoding has leaked somehow. Put it differently I don't think string operators should apply to links.

[expede]

I think I we need to support bytes natively. We do not use JSON in our UCANs, but rather use a DAG-CBOR

Yep same here. I don't want to convert to dag-json and downcast to normal JSON 👍

I think in case of JSON bytes could simply be represented by arrays of bytes. Although in literals I would support idea of using { '/': { 'bytes': base64 } }.

Oh interesting! Do you have a use case for that? I guess if we eventually support substrings you could match against binary-packed varsig headers and stuff.

---

I think we're on the same page about IPLD > JSON 👍

[Gozala]

Oh interesting! Do you have a use case for that? I guess if we eventually support substrings you could match against binary-packed varsig headers and stuff.

I don't have one per say, but I've dealt with sub-byte packing in filecoin world and trying to handle that kind of data mapped to base64 does not seem ideal.

On a separate note in most cases when we have bytes we don't have DAG-JSON-ified version of them and having to encode it seems impractical.

I guess if we eventually support substrings you could match against binary-packed varsig headers and stuff.

With jq selectors you could actually select a slice within bytes (if they were represented as byte arrays) which is also motivation here.

[expede]

With jq selectors you could actually select a slice within bytes (if they were represented as byte arrays) which is also motivation here.

Super interesting 🤔

Anyhow, it sounds like we're all on team "treat it as IPLD". I'm updating my implementation to that now 👍