This is an interesting point. Naive content-addressing does not address the issue of confidentiality. Pieces of content are not encrypted and any transporting and caching peers will be able to read content. Also for large contents the entire content is stored in an entire chunk, making transport complicated.
We have a proposal on how to do this that is optimized for smaller file-sizes and adds an verification-capability that allows caching peers to cache the entire content without being able to read the content: An Encoding for Robust Immutable Storage.
I believe that RDF is a very well suited data-model for decentralized systems (even more decentralized than what SOLID and ActivityPub currently are). I see content-addressing as the stepping stone to be able to use RDF in decentralized systems.
This lead to a discussion on the SAFE forum which is a good exploration of both his work, and a way to combine both the useful metaphors of addressing by location (folders, files etc), addressing by classification (labels which identify the creating app, data types such as photo, image etc, classifications such as personal, business, financial etc, mostly applied automatically), and where all data is also inherently content addressed (so three metaphors which all work together orthogonally). See: Concepts for apps in a decentralised web (SAFE forum)
I’m very interested to read about a fourth, using content addressing of triples @pukkamustard. RDF is a native data type for SAFE, so I’ll have a think about how this could work with capability based access control. I think it will be fine because access control is orthogonal - addressing by content is just knowing where the data is. You will still need permission in order to access and decrypt it.
So my question is more how content addressing based on triples could be used to locate the data in the backend (whether Solid, SAFE, IPFS or whatever). I’ll go read!
@pukkamustard I see your motivation is reliability in a system where trying on servers creates inaccessibility. Do you have other use cases for this?
This would not be an issue with SAFE, so I’m wondering about other uses. Intuitively I can see it would likely be useful and I’m aware that different approaches to supporting this kind of content addressing might be selected based on the use cases. Actually, having read that you have an efficient scheme for creating a canonical representation of any RDF my question is not relevant. This could definitely be implemented on SAFE, making any RDF document, including the canonical representation content addressable. I’ll pass your paper on because I think this is an important capability.
I posted on the SAFE Development forum for comment but the devs are very busy atm so I don’t expect an immediate response. See: Content addressing RDF
Any thoughts regarding IPLD, or blockchain non-fungible token contracts etc ?
Do you see your approaches @pukkamustard@happybeing as being peer level competition to such, or a possible part of ecosystem including any and all those things, etc ?
This ties into my post regarding What is most minimum SOLID?, essentially, content -addressed URIs for RDF purposes breaks Linked Data, even non-http breaks it in definition, while certainly being valid RDF.
@pukkamustard I assume homomorphic encryption concept can also get interesting regarding what your exploring.
Regarding SOLID itself, ive been exploring the concept of distributed / decentralized / virtualized Linked Data Containers, as content-addressed, as the it very much seems impractical to continue thinking of a “POD” as a specific protected folder that actually exists only on one server exposed by location based address, etc …
My approach has been to provide a way for Solid apps to run on SAFE Network, and have demonstrated the essentials working by providing a Solid API on top of the SAFE API, that can be utilised with a slightly modified Solid app library (eg forks of rdflib.js and solid-auth-client both work).
How Solid and Solid on SAFE systems relate is hard to say at this stage. Ideally they can sit side by side, one able to utilise the other, and Solid could integrate SAFE as a backend to a regular Solid server, but there are compromises with any close coupling that need to be worked out because of the different protocols. Unlike dat: or ipfs: protocols, the safe: protocol is designed to avoid use of web services which even when encrypted are vulnerable to attacks, tracking, censorship and so on. To solve these problems SAFE clients should by default at least, block all non safe: traffic, and any client (or server) which allows non safe: protocols loses many of the privacy and security benefits of using SAFE in the first place. So it can be done, but whether or not and how it is done will depend on the reasons for using SAFE and http: together.
Would you consider the first class constructs / granularity / atomicity of your work here to be regarding RDF URI and triple level, or RDF graph, document, file (turtle, etc …)?
At initial skimming through, I can see where it is accounting for many levels, but regarding some of the levels in detail it appears the focus is on file / graph level, especially regarding the immutable storage and discussion around how to handle inevitability of blank nodes etc.
Does this assumption line up with your intent, or am I not interpreting it correctly?
One thing that I think makes very easy with content-addressing is offline-first and decentralized applications. Clients can create content and reference the content from other content without having to interact with a server as the identifiers are commutable completely local.
This might be just one aspect of a broader sense of “reliability”.
The Web demo actually uses js-ipfs already. Unfortunately I was not able to get IPFS from web-browser working reliably.