---
title: Swarm TODO
---
# Sprint plan

# scope
- forwarding only (no recursive lookup and no connecting to new nodes, only working with active peers)

## TODO

- integrate new p2p
- write unit tests for protocol and netstore (without protocol)
- rework protocol errors using errs after PR merged
- integrate new p2p or develop branch after p2p merge
- integrate cademlia into hive / peer pool with new p2p
- work out timeouts and timeout encoding
- cli tools
- url bar and proxy

## CLI 
- hooking into DPA local API
- running as a daemon accepting request via socket?

### - 
## Encryption
- encryption gateway to incentivise encryption of public content
- xor encryption with random chunks
- in-memory encryption keys
- originator encryption for private content 


## APIs
- DAPP API - js integration (Fabian, Alex)
- mist dapp storage scheme, url->hash mapping (Fabian, Alex) [URL scheme](../doc/url-scheme)

# Discuss alternatives 

I suggest we each pick 2/3 and read up on their project status, features, useability, objectives, etc 
- Is it even worth it to reinvent/reimplement the wheel?
- what features do we want now and in future
- roadmap 

# Brainstorming

- storage economy, incentivisation, examples:
-- content owner pays recurring ether fee for storage.
-- scheme to reward content owner each time content is accessed. i.e accessing content would requires fee. this would reward popular content. should be optional though.
- dht  - chain interaction
- proof of custody https://docs.google.com/document/d/1F81ulKEZFPIGNEVRsx0H1gl2YRtf0mUMsX011BzSjnY/edit
- proof of resources http://systemdocs.maidsafe.net/content/system_components/proof_of_resources.html
- nonoutsourceable proofs of storage as mining criteria 
- proof of storage capacity directly rewarded by contract
- streaming, hash chains 
- routing and learning graph traversal
- minimising hops
- forwarding strategies, optimising dispersion of requests 
- lifetime of requests, renewals (repeated retrieval requests), expiry, reposting (repeated storage request)
- redundancy - store same data in multiple nodes (e.g 4x)
- the more accessed a content is, the more available it should be, should increase performance for popular content.

# Simulations

- full table homogeneous nodes network size vs density vs table size expected row-sizes 
- forwarding strategy vs latency vs traffic
- stable table, dropout rate vs routing optimisation by precalculating subtables for all peers. expected distance change (proximity delta) per hop


## Swarm

How far does the analogy go?
    
swarm of bees | a decentralised network of peers
-------|------------
living in a hive | form a distributed preimage archive
where they | where they
gather pollen | gather data chunks which they 
to produce honey | transform into a longer data stream (document)
they consume and store |  they serve and store  
buzzing bzz | using bzz as their communications protocol