SWARM replication and partitioning

Question

With SWARM, can ALL files be split/partitioned and/or replicated onto a Minimum Limit number of nodes whilst uploaded to the network?

Could the Minimum Limit number be >50 nodes and the replication >5 nodes? This would give ETH users greater reassurance to support the network. There are strict compliance standards for companies as to the location of stored client data (so perhaps in future we can also select nodes by region eg. within Europe / Outside Europe) also.

There are many strengths and weaknesses for censorship resistance - although any Copyrighted/Illegal material needs to have the ability to be flagged or effectively un-hashable (as good as removed) once discovered by the network users upon data retrieval. So I personally think SWARM should restrict certain media/file formats from being uploaded. Those multimedia formats should be left to separate systems like IPFS to deal with.

Answer 1

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

Censorship resistance

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.