Replication and redundancy
minimum nodecount to replicate each chunk is effectively achieved by the syncing protocol:
- the protocol ensures that each chunk when sent for storage is relayed all the way the nodes closest to the chunk's hash address.
- closest nodes broadcast the chunk to all peers in their "most proximate bin" (ie n-strong local neighbourhood of a node).
Swarm chunk store has the following properties:
- each node automatically and opportunistic caches chunks (incentivised maximum-utilisation)
- each node CAN do the relaying above as long as they have peer-connections observing the kademlia overlay topology
- or if they dont, they later syncronise, the moment they have the chance.
As a result, you can guarantee correct redundant storage. (well initially guarantee at least, not maintain, see below)
On top of this, client-side measures to achieve arbitrary level of redundancy will be possible (it is already, but you need to do the work until swarm implements support) by using
- erasure coding (planned for POC0.4) with incentivised scan-and-repair
- obfuscation with multiple other chunks (planned for POC0.3)
- alternate routing, e.g., by hash permutations (not planned)
All this said, initial replication is not sufficient to guarantee redundancy at the time of retrieval and it cannot be.
It is only relevant if and to the extent that chunks are protected from being deleted through the incentive system (based on storer deposits, prepaid fees and proof of custody escrow conditions).
Storage location constraints
These are generally very hard to even interpret for systems like swarm (which on the storage layer is a distributed store of obfuscated chunks). Geographical conraints are an analogue of the guy with the flag having to walk in front of cars in the early days of automobile traffic regulations.
My suggestion for those intending to implement compliance on swarm:
- negative evidence (the files are not stored on any random node) is defensible the same way as plausible deniability)
- positive evidence can easily be supplied by a compliant node (or 'consortium' of compliant nodes) that can (on demand) reveal
- proof of the geographical location of their server
- showing the relevant storage seed/mask/obfuscator and actually storing the document in full depth
Well, yes, but no.
We most probably
- want measures that disallow plain unencrypted chunks of known media formats.
- do not want and cannot even theoretically have fair white/blacklisting
If you use strong symmetric obfuscation (simply XOR-ing two documents and recycle the pool as opposed to key-based encryption),
- fair white/black-listing is impossible (to even define)
- yet noone can be held accountable without EVERYONE being held accountable
Strong censorship resistance (allowing for nodes to store, upload any retrieve any content of their choosing) is one of the primary design goals of this project.