2.9 KiB
2.9 KiB
| 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
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 |