Proposal: IPLD Selectors (A)

[jbenet]

I've been working on an IPLD Selectors proposal. It aims to be very small, while synthesizing a lot of what we've been discussing over time.

Notes:

• not sure where to put this. i'm dumping into ./selectors/selectors.md in this repo, following what's in other concurrent PRs in this repo. Feel free to move it as you see fit. (directory because it includes an image)
• this is tagged with (A) in case concurrent/competing selector proposals show up and this one needs to be referred to separately.
• i still need to finish this :(, but i dont want to block others. I'd like to finish and freeze this by EOQ.

Proposal Status:

• This was written around 2018-10-16 (video presentation)
• It narrows down the decision space enough to make significant progress.
• good enough for trying out an implementation to learn more and make choices.
• But it is not complete.
• some choices that need to be made:
  • select general binary and string format structure for selectors. (options given here)
  • binary and string formats for each selector. doesn't have to be here.
  • whether to dump all selector codes into multicodec table, or one code.
  • which S expression selector variant to use (may be out of scope for this doc)
• more prose here may help implementors.

[mikeal]

I love that we have a selectors proposal before we have a finished IPLD Paths spec :)

[mikeal]

One thing this has me thinking about is how we might implement a better pin/gc API.

For most use cases I can think of, you usually want to store a selector, or set of selectors, of a given CID. Later, you likely want to replace the CID for that pin, causing a sync against the new graph. If we had an API that actually replaces the CID for a pin we can actually calculate the orphaned nodes and perform a simpler/faster GC of just those blocks.