(I had to take a moment to wrap my head around HAMTs, if we’re hash-addressing, why not just use a hashmap? I’m going to guess the answer is that in a distributed storage context, no one wants to have to be the one who has to expand the hashmap in the process of adding one entry, or that at large scales exponential up-sizing becomes a bit ridiculous, or because block chunking makes a tree structure relatively faster, or something like that?)
Autocodecs… I see. So in rustland we’d define a conversion like so: impl Into<Json> for &Cbor { fn into(self)-> Json { ... } }. But the impl has to be defined basically either in the Cbor type definition, or otherwise in the Json type definition, it can’t be defined anywhere else. This makes it unambiguous which impl is being used, but I’ve always found that a bit limiting, because it means a third party cannot come along and define a conversion for two types that don’t know about each other.
I’d probably prefer an approach where there’s a fairly open set of converter packages that anyone can contribute to, where collisions (conversions between the same pair of types) are ranked by some community code auditing process (maybe peer review) in terms of security, efficiency and ergonomics (potentially not ranked with numeric ratings but using full rank recovery from comparisons between pairs (paraphrasing: finding the ‘top’ of the graph formed by submitted comparisons between the nodes in the graph. A tournament is an efficient example of this being done. Something like pagerank is an approximate and good enough algorithm for taking a graph and finding its top.) as this is more suitable for situations where there’s no obvious max or min quality to callibrate an absolute scale, and where doing comparisons is expensive, and where there’s a fair amount of respect between judges.).
So, EG, I guess when you tried to convert cbor to json, your code editor would query that registry and select the top (audited) conversion, and put its content-hash-import into your code. (like, import convert_cbor_json from ipfs:QmcniBv7UQ4gGPQQW2BwbD4ZZHzN3o3tPuNLZCbBchd1zh#convert_cbor_json (the name after the hash is just a check to make sure it’s the right hash and to make it clear what the hash link is supposed to refer to. Eventually the editor would cache the package and show its description instead of a hash.))
I guess that’d be a specific case in a more general system: The community defines categories for libraries. Categories are assigned or removed by the votes of programmers in your preferred “is a good programmer” endorsement graph. Libraries that share a category are sometimes compared and ranked. “Conversions of cbor to json” would be one such library category. If a library has higher ranked alternatives within its primary category, the library browser shows a notice/warning/alert on its page, suggesting that you check out the other alternatives.
I should ask whether Fission would like to be involved in the development of a distributed cross-language typesystems and development tooling, or whether yall are just going to leave it to me. If it’s left to me, 30% chance it wont get done! I haven’t floated this by NLNet and they might consider it too ambitious at this stage. (But also, there are a lot of people who share the dream of a cross-language wasm ecosystem, and bytecodealliance are doing a lot of good work in that direction and probably intend to just keep going, so it probably wont be left to me.)
Capn proto is also a distributed type system and actor interface language, but it favors obtuse read-in-place APIs that people don’t seem to like, and the type description format doesn’t embrace content-addressing, and it mandates field numbers (for forward-compatability) even in initial definitions when they’re just boilerplate, and that could also be dealt with much more elegantly using content-addressing to link to previous versions of the schema. So I wont use the capnp format.
And I don’t think there have been any other attempts at this?
Nice first post.