Aliases: from a local file, kinda like requirements.txt, maps name to hash, either package/module name, or an author/public key name.
This has to be treated specially. If two aliases appear to be the same, but one is fetched a "secure" IPFS hash, it MUST be compared w/ what ever secure hash the two aliases had in common. Otherwise a malicious package could "pretend" that it hash the sha256 that's the same, but provide a bad IPFS hash, and then we'd load the malicous package instead
Example: from cas.a.jmg.utils import aiter, anext
Make sure that when an alias is used, that the same module is returned when a direct hash import is used.
Local cache: if a directory like ~/.cas_cache exists, use it’s contents automatically, and if it’s writable, write any network fetched imported data to it.
Features: add: file url ipfs hash git(?)hub?
init cache:
Loading resources from yourself (package): sys.modules[name] returns a valid module while your are being initalized, even for main, though may not work due to it not being a package, but probably can be emulated via file use importlib.resources: https://docs.python.org/3.7/library/importlib.html#module-importlib.resources > Loaders that wish to support resource reading should implement a get_resource_reader(fullname) method as specified by importlib.abc.ResourceReader.
Hash options: urn old ietf draft: https://datatracker.ietf.org/doc/draft-thiemann-hash-urn/ - not up to date hash-uri: https://github.com/hash-uri/hash-uri - this looks best multihash: https://github.com/multiformats/multihash - no URI specification ipfs uri: https://github.com/ipfs/in-web-browsers/blob/master/ADDRESSING.md - not a hash, but useful for IPFS names ni: https://tools.ietf.org/html/rfc6920 - complicated, not well supported