Rob Brackett

@SethMichaelLarson Great, thanks! I’ve put a little note in my source about 2.0 as a reminder :) @sigmavirus24 I think if I were trying to make a nice, abstract version...

Yep, the approach in #2500 would certainly work for my case.

I think this would be a great idea. I don’t know whether it fits best, but three options seem obvious to me: 1. [ipld/specs](https://github.com/ipld/specs) 2. [ipld/interface-ipld-format](https://github.com/ipld/interface-ipld-format) 3. A separate repo...

For what it’s worth: the reason I lean toward specs is that interface-ipld-format seems more focused on the API interface of a resolver, which a user of IPLD should usually...

That said, my opinion is not a *strong* one. Just getting this down somewhere is a win! 👍 It seems like we all agree this is a good idea, so...

## Some More Particulars *(This is all additional anecdotal stuff. The meat of the issue is above in the original post.)* Instead of the above, we tend to dive right...

**Note:** nevermind my point about paths/selectors/queries, I think [this `notes` issue](https://github.com/ipfs/notes/issues/272) clarified a bit for me: - we have paths - selectors are going to be a broader set of...

> As @nicola said, IPLD is concerned with the abstraction. I guess my confusion here is: in practice, at least, *there is no abstracted structure.* (You ask a resolver to...

> one can have multiple implementations That’s why I wrote “IPLD is *principally* a software program/library/**set of algorithms**” in the long description later on :)

> It's not unlike graphql. ~Sure, but GraphQL also defines the formatting of responses (like how errors are handled), which IPLD (at least so far?) does not.~ (Edit: this was...