P2pstorage

Decentralize everything

I started deploying cheap NAS boxes running OpenWrt around my local mesh environment and experimenting with possible use-cases for non-router devices with storage in mesh environments.

Starting from the bootloader and target-support for the cheapest-ever NAS SoC in the Linux Kernel and OpenWrt I'm now working on building blocks of a (hopefully) shared vision.

Being socialized in a FIDO world, I first thought about running NEWS services and having them talk UUCP, NNTP and SMTP -- however, a smart BitTorrent setup turned out to be the more suitable content distribution tool for contemporary users (but I didn't yet let go-off the idea of re-using tools which were tested for 15 years serving hundreds of users on i586-class hardware with 32MIBs of RAM -- a spec not unlike many cheap embedded systems today) Anyway, for the more progressive minds there are fancy things like distributed filesystems https://tahoe-lafs.org sidenode: kadnode combined with anycast DNS helps to (partially) solve distributed name resolution and is not bound to a specific routing protocol. anycast actually seems to be a good idea for quite a lot of things (dht seed nodes, bittorrent retrackers, ...)

Running cjdns, gnunet, torcat, you-name-it as a "social mesh" on top of the "physical" transport mesh is an interesting field to explore, also for autonomous mesh-connected NAS boxes. Distributed overlays provide a better option for remote access compared to traditional VPNs which are expensive and risky to run and usually end-up being the central bottleneck. Eg. cjdns can run on top of an batman-adv mesh-routed interface as well as communicating with far-away and/or well-connected peers via ARPANET IPv4/v6. IP-over-IP tunnel setups on top of cjdns can then be used for point-to-point IP links where needed (e.g. to provide layer-3 routing between different mesh communities or to access mesh-services from remote, private gateways, ...)

Anyway, now that we are connected *and* got some chunks of permanent storage as well as processing resources, what are we going to do?

I got some suggestions:

• run local caches, e.g. http://wiki.squid-cache.org/ConfigExamples/DynamicContent/YouTube

• run bittorrent trackers (e.g. to make the archive of radio shows of the local community radio available on freifunk)

• run transmission(-web)

• run Twister

• run Retroshare seedbox

• provide OS distribution package mirrors, maybe also PXE-bootable OS installations or live-systems

• provide "classic" cloud services (dropbox-like)

• run NNTP-backed forums with web-UI :)

• feed aggregators

• mpd, icecast, ...

publish and share

Network requirements for local storage and P2P

* endpoint-to-endpoint addressing (e.g. using AHCP v4+v6 **in addition** to globally routed IPv6 prefixes and NAT'ed IPv4 via DHCP)
* routing-protocol-agnostic multicast service discovert via mDNS/SSDP (requires at multicast routing)
* splashing and l7filter foobar performed by gateways only, transparent communication inside the mesh

(very) low-hanging fruits

* retracker.local hack to make torrent-clients snitch on their users to an in-mesh tracker
* trackers can use livesync over multicast to stay in-sync (every tracker then tracks every torrent)
* the local tracker can add torrents *not* added via livesync to a local transmission client
* community forks of peerflix or popcorn time
* https://github.com/rkfg/BTFS
* use mesh-wide mdns to announce local services (e.g. smb, ipp, pulseaudio, ssh, ...) and mainline commercial OS will discover them

future vision

* (web)torrent-over-webrtc resulting in p2p HTML5 video in the browser with no additional software installed
* better url-handlers can allow to address the folder/file inside a torrent
* support for "App"-like torrents containing an index.html and metadata.json file in addition to static content.

talk, chat and discuss

today

* use an asterisk-dialplan hack to resolve self-assigned mesh phonenumbers -- use sRTP with self-signed keys (more below)
* web-dht-based in browser multi-user-chat
* pidgin, adiumx, ... support mDNS-based local peer chat

tomorrow

* web-rtc audio/video integration
* zRTP and OTR in JavaScript
* hack kadnode to resolv SRV and ENUM DNS records -- or 
* actually have a browser one can trust and hardware one can trust to run it on... however...

Once we got storage, we need a...

why?

* secure end-to-end communication without pre-shared knowledge or side-channel authentication
* we should rethink how to apply cryptographic tools. In a graph, the key-pairs should be the arrows, not the dots! Signed-public-key alone don't express any specific relation -- we need an extendible signature-purpose struct being signed along with the 

10 years ago

• mojonation
• Freenet Project

we are here

• BitCoin provides a very well-tested decentralized PKI -- but it's too bloated to run on a router
• RetroShare looks like donkey and does everything -- too much for a router (though I managed to get a headless version compiled on OpenWrt some time ago)
• people start to understand the patterns found in the "social network" can be expressed with assymmetric cryptography.
• all myths of "secure networks" and "secure services" have busted -- crypto is the only way out.

why do I mention that in this talk?

• have a universal keystore service with support for all applications incl. agents (gnome keyring and alike do that -- we need a libubox'ified version of that)
• the blockchain pattern is not hard to understand starting from public key cryptography -- and together with an existing DHT it's not hard to build a naiive implementation of something like a distributed pgp key directory able to handle public key certificates publishing and requests. As time goes by, certificates will nedd to be updated (owner can revoke the key and add/remove signatures other made on your public key, signers can revoke signatures).
• in order to have anything like RSS (or even Twitter-like) stuff in a distributed fashion, we need the blockchain pattern (or a "light" version of it)
• now imaging having a small ukaddht system service running and providing some ubus RPC, have a distributed PKI service running and using ukaddht

-> for compatibility, the pki service could create an /etc/ssl/ folder use FUSE to provide the usual openssl cert dir containing the public keys of everyone the user directly signed for SSL-use.

• create 2 new keypairs and use the first one to sign your first magnet-podcast post together with the public key hash of the 2nd keypair.

when posting next time, generate another keypair for future use, and also sign the public key hash of the keypair used for the first post as well as the public key hash of the keypair just generated for future use. (and this can also works in private)

• a distributed pki together with p2p-storage and pki-provided authentication of dht objects could potentially replace blogs, twitter and provide single-sign-on/delegation like oauth.