Hi Chris Gebhardt. Thanks for the comments!

Right, but if the leaves are encrypted, I'm not seeing the practical difference. Routing obfuscation and network path redundancy are the only way to gain anonymity / availability, which is a different layer than the data model. Am I missing something?

I agree completely. An adversary can observe network traffic and then learn about which blocks belong to what content. One would require some kind of transport level obfuscation (e.g. transmit a bunch of random blocks) to mitigate this. I think the indistinguishability of block type can help do these kinds of obfuscations.

A case where encryption of branch nodes might make more sense is plausible deniability for caching peers. Caching peers can choose to not know anything about the blocks they are caching. If the caching peers hold the verification capability then they can decode the branch nodes and yes we end up at the case where branch nodes are just not encrypted.

So, I admit, the case for encrypting branch nodes is not so strong. Still, I think it is worth the effort.

Partly, I suspect we have radically different objectives here. A core principle of the InfoCentral data model is to make a fair amount of graph structure (hash refs) publicly visible, even if content is encrypted. This is for the sake of reference collection, which allows all parties to participate in routing public information toward its adjacencies in the graph. (Thus helping build out a shared semantic graph, RDF or otherwise..) It also eliminates the need for the fiasco that is owned namespaces and federation, because new information can simply coalesce around existing information and be filtered by end users.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.

So, I admit, the case for encrypting branch nodes is not so strong. Still, I think it is worth the effort.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.
Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.
Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.
Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.
Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.

Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.

Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities) Of course, the statement data may also be encrypted, with the same or different keys.

I think this still works with what we propose. Namely you can reference the verification capabilities. This make the hash refs publicly visible, even if content is encrypted.

Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise). My new "standard entity" data model (WIP) allows contained references to be selectively plaintext or encrypted, even to different keys. This could be used to hide the Merkle branch references as in your model. But it also allows, say, subject references in RDF to be publicly indexed by repositories and collected (for the sake of gathering multi-sourced statements within the entities for different subjects) Of course, any statement data may also be encrypted, with the same or different keys.

In reply to @how:public.cat
I think plausible deniability for caching actors is a strong case as It effectively enables network neutrality and provides another defense layer against censorship attempts by strong attackers.

In reply to @how:public.cat
I think plausible deniability for caching actors is a strong case as It effectively enables network neutrality and provides another defense layer against censorship attempts by strong attackers.

Here, in particular, I'm talking about not just the references that build a Merkle tree but the hash references within serialized content, such as the subjects, predicates, and objects of semantic graph statements (RDF or otherwise).

The ERIS and "Content-addressable RDF" proposals split up these two ideas as well. "Content-addressable RDF" defines some restrictions on RDF that make sub-graphs content-addressable. Subjects, predicates and objects can be referenced by a (not-so-)good old URL, a simple hash of the serialized content being referenced or by a more intricate (and secure) encoding of the content (e.g. ERIS).

Thus far, I didn't have any particular plans to force people to use a certain storage block size or Merkle tree structure

Same, same. ERIS is just one possible way of securely encoding content that can be referenced.

I recently learnt that GNUNet also defines URLs (https://docs.gnunet.org/handbook/gnunet.html#File_002dSharing-URIs). So also ECRS encoded content can be referenced from RDF.

One of my assumptions is that there will not be a single topography, like true P2P, but rather a wide range of network overlays.

I share this assumption. @tg has proposed one such topography (https://p2pcollab.net/#upsycle).

The full plausible deniability model is certainly useful, though I suspect it is necessarily quite costly in performance.

This might very well be the case. But there are situations where plausible deniability (and censorship resistance) is absolutely necessary. Maybe encoding the branch nodes will help in lowering the total cost of full plausible deniability?