Dist.ribut.us lite

Rather than full p2p, a system for distributing trust between federated servers. It fails many of the goals of the full dist.ribut.us design, most notably meta-data protection via onion routing. But it is much easier to build and could provide the necessary foundation to build the full system.

Federation Problem

In a federated server system, individual servers can gain power over the whole system. To prevent this, the rules need to be enforced and users should not be associated with an individual server.

Design

Gateway

A gateway is a service that talks to many servers to make sure the system is honest. Gateway software should be light weight and simple enough that a moderately sophisticated user can setup their own gateway. It handles the eigentrust calculation (or maybe just validates it) and handles the web-of-trust issues.

Server

The servers hold data and facilitate connections. Most communication is user-to-user over WebRTC.

Storage

Data is a simple Key/Value store. Though it's a little more than that because the key needs to have enough data to locate a server, a database and a bucket.

I need a way to swap out the backing medium. In some cases Bolt will be easiest, in others, blob services like S3 will be better.

Static

A resource where the key is the hash of the data.

Permissions

Permissions are placed on a bucket. UserIDs are written to the bucket with a permissions level. Data is written key/val. Both are prefixed with a header byte.

Services and Applications

A service run on a server, an application runs on a client. As much logic should be pushed to the application level as possible. Services and applications must be open source.

Client Binary

The client binary is an application intended to run on the client system. It allows protected access to the clipboard, file system and other resources generally protected from a browser. It also runs an instance of a gateway.

I can get a version of this running on desktops easily, mobile is a bit more tricky. Android should not be a stretch, but other mobile platforms may be a challenge.

Users

A user is a signing key at it's heart. Finding a usability pattern for this is going to be tricky.

Communication Security

TLS isn't going to fully cover this because many users will be running small personal servers off non-fixed IP addresses.

Community

Censure

Servers can censure each other, which is used in an eigentrust pattern. Gateways keep a log of the servers they trust and update them as that trust changes.

Open Source

All applications and services must be open source. A server running closed source or modified code should be censured by the community

Forgetful

Services should not spy on users, should not retain any information other than that requested by the user.

Profits

User based advertising is strictly forbidden. It is acceptable to run either blind or contextual advertising. Blind advertising being a rotation of advertisements that do not take the user into account at all. Contextual advertising being based on the current context, but with no individual data being taken into account at all. For instance, when a user performs a search, the server can choose to display an advertisement based on the search terms. Or if a user is viewing an image with meta data, advertising based on the meta data is acceptable. But the association between the user and the context must be ephemeral.

Better would be for users to pay for access to federated servers. This is a divergence from the norm, but perhaps with mom-and-pop servers where the users actually know the administrators, this could be established.

Personal Setup

RasPi

I should get a version built that can be setup on a RasPi easily. A 1TB external drive is cheap.

AWS

I should offer an image

Target Applications

Chat

This is the 'hello world' of distributed applications. Establish a chat log and allow users to append to it based on cryptographic permissions.

Ha! this is actually a good use for a sort-of-blockchain. The head of a chat contains the most recent additions and a block reference. When the chat gets too long, the history is written to a static block.

It may make sense to write the block in 2 parts, a header and the data. The header contains the 'next' link, time span and a bloom filter for words in the text.

Chat can also do a direct file send over webRTC.

File Sync

Allow users to sync their files between devices. This is a bit more complex and requires the client binary.

Speakeasy

A basic social network.

• Posts
• Direct Messaging
• Media uploads

Media Player

Designed for personal use. User puts their media files on something like a RasPi drive and they can stream the media. A per-user record