Dist.ribut.us lite: Difference between revisions

From Adam Colton
Jump to navigation Jump to search
No edit summary
No edit summary
Line 53: Line 53:
This is the 'hello world' of distributed applications. Establish a chat log and allow users to append to it based on cryptographic permissions.
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  
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.


=== File Sync ===
=== File Sync ===

Revision as of 14:38, 9 August 2018

Rather than full p2p, a system for distributing trust between federated servers

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.

Server

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

Storage

Data is a simple Key/Value store backed by Bolt. 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.

Static

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

Permissions

The key is some sort of guid. The record has Read/Write/Admin permissions with a list of signing keys for each permission.

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.

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.

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.

File Sync

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