Things in IPLD on IPFS

[vorburger]

It may be fun to explore storing Enola's Things on IPFS's IPLD.

This would first require being able to turn an IImmutableThing into the IPLD Data Model. That would enable to create predictable hashes of Things, to be generate CIDs. This will require work to turn any Datatype into one or several predictable 0/1 bits format/s (simplest could be e.g. just toString, and Maps as JSON with sorted keys?).

That would enable e.g. IPLD DAG JSON Codec as an Enola Format.

IPFS IPLD Schemas would need to be an Enola Schema.

Related libraries of possible interest:

• https://github.com/ipld/java-cid
• https://github.com/ipld/java-ipld-cbor
• https://github.com/filip26/copper-multicodec
• https://github.com/filip26/copper-multibase

[vorburger]

https://ipld.io/tools

https://github.com/ipld/cid-cbor/ ?

https://openengiadina.codeberg.page/rdf-cbor/ but that's not what one would want... It could be a basis, but we would want a utility which transforms IRIs into, either:

• Special cases such as urn:uuid (et la.) to 37 etc.
• Else, if Thing exists (with properties), CID of it
• Otherwise, to CBOR tagged URI (32) or IRI (266)

... IFF such are valid in IPLD (TBC), else string if not CID.

https://www.w3.org/2024/12/rch-wg-charter.html is probably how you would want to canonicalize RDF? But we don't actually need that, because it would be based on the Thing API (and we already have Thing canonicalization in Enola, somewhere).

The "IPLD blocks" must include the IRI (as the hash is one way). We COULD postfix IRI with @multibase CID, to "version" them? And have sameAs with & without version. This would help to distinguish different Thing version itérations.

Next Steps:

1. Play "hands on" with IPLD.. create, link, read (on local IPFS Node)
2. Implement Enola Thing CBOR format support)
3. Implement IPLD support