Converting between ipld-prime links and CIDs is painful.

[Stebalien]

We need to find some way to either:

1. Use with ipld-prime links everywhere instead of CIDs.
   • Forces an allocation everywhere.
   • Doesn't work as a map key.
2. Make CIDs implement the Link interface.
   • We'll have to accept links in APIs (and maybe return CIDs?).
   • Awkward because we'll still have a mix.
3. Remove the abstraction.

[warpfork]

Yeah, agree, something isn't settling right here at present. I just haven't figured out how to fix it.

To review some reasons things are the way they are right now:

Part of the intent of putting an interface in this position was to leave open a clearer path toward other kinds of linking (limited relative references; cid+path superlinks; other(carefully)?). But at present that generality is speculative. (And the argument for retaining speculative generality is always a weak argument.)

Another reason I put an interface for Link between the core IPLD types and go-cid is that the transitive dependency span for go-cid is huge. Source-wise, it pulls in 10 additional repos (some of which are quite large, and largely off-topic -- e.g. golang.org/x/sys/cpu). Binary-wise, comparing a binary that imports ./linking/cid vs not, it adds almost a full megabyte (contextually: increases the size of a basic ipld cli tool to 150% of what it would otherwise be). Maintainablity-wise, the more transitive dependencies we have (particularly in repos that are multi-purpose, like x/sys/cpu), the more likely we are to get Fun with updates if user code wants a different version than we do. Maybe this issue isn't one to be concerned about; or perhaps more ideally, we could make some intervention in the go-cid package to improve these affairs. I found these numbers a bit worrying, though. Large transitive dependency trees make adoption harder.

An excerpt of the current godoc on the Link interface type, for anyone reading in the future, describes links this way:

Link is an abstract interface so that we can describe Nodes without getting stuck on specific details of any link representation. In practice, you'll almost certainly use CIDs for linking. However, it's possible to bring your own Link implementations (though this'll almost certainly involve also bringing your own encoding systems; it's a lot of work). It's even possible to use IPLD entirely without any linking implementation, using it purely for json/cbor via the encoding packages and foregoing the advanced traversal features around transparent link loading.

... and I still kinda like that reasoning. (Which is not to say it shouldn't be overriden by other concerns, but... I think it's worth thought.)

</earlierReasoning>

I will also +1 that the way the Link and Loader interfaces interact is also currently way too twisty. Some of this twistyness probably does not have a good reason. It's possible that if this is untwisted, the current friction level might go down to more acceptable levels; either that, or the ease of taking Option 2 should increase. So some investigation of this seems win-win.