Add a cidlink.Memory storage option

[willscott]

the current storage.Memory does not provide cid semantics where data can be stored under e.g. cidV0 and retrieved as cidV1.

[rvagg]

sgtm
beInitialized() is a bit of a naming oddity though, and are you intending for Bag to be public? seems like something that should remain private and be mediated through accessors if you need to do something fancy with it.

[willscott]

that part is directly copying https://github.com/ipld/go-ipld-prime/blob/master/storage/memory.go

[rvagg]

ok then, @warpfork can consider that critique directed at him then, and given the consistency this is 👍

[warpfork]

yeah, the memory storage type that Will's riffing off of here was really only intended for testing and demo usage, so it's very yolo/we-are-all-consenting-adults-here/unsafe. I shan't defend it much :)

[warpfork]

I wonder if this would be easier to do more cleanly after the big storage API PR.

After that lands, I would propose we could solve this with a function like:

func ConfigureLinkSystemWithMultihashKeyedStorage(lsys *linking.LinkSystem, store storage.WritableStorage) {
	lsys.StorageWriteOpener = func(lctx linking.LinkContext) (io.Writer, linking.BlockWriteCommitter, error) {
		wr, wrcommit, err := storage.PutStream(lctx.Ctx, store)
		return wr, func(lnk datamodel.Link) error {
			return wrcommit(lnk.(cidlink.Link).Cid.Hash().HexString())
		}, err
	}
}

... the upside of which would be: we're not rewriting the storage implementation, we're just writing how we transform the link into a key before we hand it to the storage layer. This would seem cleaner and results in more code reuse.

[willscott]

I needed this already and have been using it in e.g. https://github.com/ipfs/go-unixfsnode/pull/12/files#diff-daf113341551df24033a6ff3b492572582e857944008668d6647486c5ab415e2R33-R35

In general I'm not convinced about "there will be better paths later" as a reason not to merge things, since that's always true.