An Attempt At Redesigning multiaddr
The "multiaddr" in the title refers to the one of multiformats, designed by Protocol Labs of IPFS fame. While I'm not going to comment on their pivot towards AI and their lingering obsession of Web3 seemingly still present in 2024, I do think there's at least some merit to the idea.
One must understand that the most common meaning (and at the same time, the meaning seemingly adopted by the people behind multiaddr, at least according to my understandings) of the phrase "network addresses" is a kind of resource identifiers, which - if we really think about it - is a whole spectrum with numeric serial ID at one end and and actual fully-fledged resource-accessing programs at the other end, and I'm afraid that the more you want it to be unviersal and "future-proof", the more you'll have to move to the latter side. The current design of multiaddr already gears slightly more towards the "program" side instead of "ID" side of things; I personally think that to be anything more flexible than the current usage of URL, it's better to think of it as a description of some kind of process; and by thinking it this way, what we're doing is actually designing a very small domain DSL.
I don't like designing DSL. It's always very hard to obtain a good balance between flexibility and mental load - you don't want to have something that's so flexible that whatever it describes takes too much effort to understand, especially not in this case. But after half a day's careful thinking, I think I have something that maybe is good enough.
I was going to describe it within this blogpost, but it has grown too long; I've put it at a different location. You can access it here:
Last update: