I think a slightly better proposal was to use a URN namespace (instead of an URI scheme).
In any case, content-addressing is great and should be used more. However, I think there are two issues:
Large content must be fetched in it’s entirety before it can be authenticated
No built-in encryption
Number 1 is solved by using a merkle tree (like BitTorrent, IPFS,…). Both are solved by ECRS as implemented in GNUnet or in a slight update I have been working on: ERIS.
Do you mean that there’s no provision for encrypting a resource while it’s being fetched? It may be rather informal, but it seems to me that section 4 defines a conversion of each ni URI that includes a domain name or IP address into an https URI. A server might not bother serving the resource over HTTPS, but it doesn’t seem to me that this RFC otherwise addresses fetching ni resources much if at all.
Do you mean that there’s no provision for encrypting a resource while it’s being fetched?
I mean that there’s no enforced encryption at rest or during transport.
As you mention one could use HTTPS or other encrypted transport. But peers that cache the content still can read it and there’s no way to make sure that HTTPS is used.
A nice thing about content-addressing is that it makes the content independent of any location or protocol used to transfer it. Imho, all the more reason to make sure the content is always encrypted.
One could say that these are separate concerns. It is possible to encrypt content and then content-address the encrypted ciphertext. This is the approach taken by IPFS. In practice content on IPFS is not encrypted. Also with BitTorrent, content is not encrypted (causing quite a bit of real harm).
In ECRS and ERIS content is always encrypted and chopped into small blocks. Doing this together results in a readily-usable and network-optimized scheme for content-addressing.
It’s relatively well thought through for their usecase. The human readable prefix lets you tell at a glance what kind of code it is. There’s a checksum at the end to catch typos. They avoid similar looking letters and order the letters to prevent typos from getting past the checksum. If your goal is to make a CAS system that can be used by humans as URLs, you could do worse. It probably needs some dashes though for visual chunking.
I think a slightly better proposal was to use a URN namespace (instead of an URI scheme).
In any case, content-addressing is great and should be used more. However, I think there are two issues:
Number 1 is solved by using a merkle tree (like BitTorrent, IPFS,…). Both are solved by ECRS as implemented in GNUnet or in a slight update I have been working on: ERIS.
Do you mean that there’s no provision for encrypting a resource while it’s being fetched? It may be rather informal, but it seems to me that section 4 defines a conversion of each
niURI that includes a domain name or IP address into anhttpsURI. A server might not bother serving the resource over HTTPS, but it doesn’t seem to me that this RFC otherwise addresses fetchingniresources much if at all.I mean that there’s no enforced encryption at rest or during transport.
As you mention one could use HTTPS or other encrypted transport. But peers that cache the content still can read it and there’s no way to make sure that HTTPS is used.
A nice thing about content-addressing is that it makes the content independent of any location or protocol used to transfer it. Imho, all the more reason to make sure the content is always encrypted.
One could say that these are separate concerns. It is possible to encrypt content and then content-address the encrypted ciphertext. This is the approach taken by IPFS. In practice content on IPFS is not encrypted. Also with BitTorrent, content is not encrypted (causing quite a bit of real harm).
In ECRS and ERIS content is always encrypted and chopped into small blocks. Doing this together results in a readily-usable and network-optimized scheme for content-addressing.
Thanks for the update.
Bitcoin is dumb, but they did make up a good CAS format.
Hm what’s good about it? (honest question)
It’s relatively well thought through for their usecase. The human readable prefix lets you tell at a glance what kind of code it is. There’s a checksum at the end to catch typos. They avoid similar looking letters and order the letters to prevent typos from getting past the checksum. If your goal is to make a CAS system that can be used by humans as URLs, you could do worse. It probably needs some dashes though for visual chunking.