As food for thought, I wanted to share a rough idea that’s been bouncing around in my head with regard to “dat://”.
Earlier this month…
So recently I checked out gnunet, which meant no less than 1 very late night of configuration drama, but which also meant learning about some very cool ideas.
One thing I’m impressed by is gnunet’s URI scheme. gnunet is composed of lots of different modules with names like “fs” and “cadet” and “vpn” and all kinds of stuff and I honestly don’t really know what they all do. But basically each module provides access to different kinds of data.
And gnunet’s uri scheme gives modules quite a bit of freedom to each implement their own APIs. A gnunet URI looks like this:
The “identifier” piece can be just about anything, depending on which module you’re talking to. To access a file from gnunet’s
fs module, you might use a URI that looks like this:
gnunet://fs/chk/[file hash].[query hash].[file size in bytes]
fs module provides a few different ways to query for files.
dat:// did something similar?
So what if there was something like this for linking data stored in various hypercore based data structures?
As a very literal example, we might imagine URIs like:
Just to be clear, this example takes very literal inspiration from
gnunet://module/id, but it wouldn’t necessarily need to look exactly like gnunet.
All of these modules have their own ways of dealing with addresses. Some of them will also loop in more hypercores or other hypercore based data structures.
And of course these modules are all evolving. But this would opens things up so that each module is responsible for maintaining its own backwards compatibility story.
It’d also open up some room for new hypercore based modules to enter the picture, as time moves into the future (inevitable).
What about everyone just making their own protocols?
During the last comm-comms meeting, @rangermauve helped me realize that it’s actually pretty awesome that people in various hypercore based projects are just going ahead and making their own protocols.
This idea isn’t about discouraging developers from making their own protocols. Rather it’s about attempting to make
dat:// URIs both (1) more explicit about the data they point at, (2) more inclusive of the many different hypercore based data structures people in the community are building and (3) more stable.
In current operating systems there’s a very strong coupling of protocols and applications. Protocols end up being pretty strongly suggestive of how to actually use the URI. This is great for linking to a specific way of interacting with data, but maybe it’s not always so great for referencing underlying data in a stable, interaction-agnostic way.