Add exploration report for a schema listpair extension

[vmx]

The IPLD Schema Map kind already supports a representation called listpair, which could be extended to support advanced use cases like integer or bytes map keys.

[warpfork]

This is really fun and something we should talk about more so I love the writeup :)

So far I've considered that even when Schemas allow a wider range of things as map keys, the thing must still have "a representation which has a kind of string". Most of the reason for this has been out of concern for ensuring serializability in all codecs (at least, all those that have full support for the entire Data Model), and also a tad in concern for pathing (figuring that we could use the stringified form in pathing without issue).

But this brings up some really good points that this particular map representation could actually let us get away with tossing out at least one of those two worries, and that is kinda interesting.

[prataprc]

Neat write-up. Very useful.

Though the use-case of filenames as map keys, e.g for IPFS, can still be served. You would use binary keys together with the listpairs representation to store the filenames.

The proposal describe how to treat map keys - either as Unicode-string, or binary-string. How to know whether the incoming path-segment-key is to be treated as Unicode-string or binary-string, is it discussed/specified else where ?

Btw, I am assuming that Unicode-string means language native string implementation. Correct me if that is wrong.

[vmx]

How to know whether the incoming path-segment-key is to be treated as Unicode-string or binary-string, is it discussed/specified else where ?

Path segments for Data Model traversal will just have the same kind as they map keys (strings). For schema level pathing we need something else somehow. @warpfork had a view ideas, but there isn't really anything specific yet.

Btw, I am assuming that Unicode-string means language native string implementation. Correct me if that is wrong.

Yes.