For years I’ve had an idea for a resilient distributed CDN and social networking protocol, but lacked the time and experience to build it.
Recently I’ve been experimenting with the closest existing thing to my vision – secure scuttlebutt, using it’s clients Manyverse and Patchwork. I would like to promote these as the people-powered replacement for Facebook. These apps are somewhat lacking in features currently, and are not designed to fit within the storage of personal devices were they to become as popular and interconnected as the big social networks. I would like to fork the ssb codebase to build in the changes I think need to be made but for two problems. It would break compatibility with the existing protocol, and, I hate node.
Here, while it’s in my mind, I will explain the design I think a distributed social network needs to function and scale.
A personal blockchain (sigh) for each user.
A user’s account shall consist of a simple linear chain of two types of message.
- Invite block. These are messages encrypted using the targets public key. These shall contain a password to a channel.
- Message block. This refers to the URI of a password encrypted json object which may contain any type of message which will eventually be rendered on the front end, as well as a select few system messages, such as publishing IP addresses for direct connections from trusted peers.
Every shared entity, from one-to-one messages to private groups will be considered a channel, wherein every associated message will be encrypted with the same shared password. Passwords are shared through private invites sent to the invitee.
A many-to-many password store linked to users.
Every message block will be password encrypted. The password for public messages will be a sha256 checksum of the sender’s message. For all other channels, each user will be able to send these passwords to each other using invite blocks. Whenever a user downloads a message block, they will attempt to decrypt this message using each known password for the sender. If the message is decrypted it may be used in anyway the reader wishes (ie. rendering to a page), otherwise the message will be assumed not for the reader and ignored though left in the cache.
Password protected binaries.
Any binary object such as images or video shall be password protected using the sha256 checksum of it’s own unencrypted form. This means each file only needs to be stored once in the cache and instead of sending the file to multiple recipients, the user only has to send instructions on how to access a file which is already distributed within the network.
Each user shall attempt to store every object they are aware of up to a defined cache limit, or an inverted cache limit (ie. fill the cache until only 10GB of storage remain on the device.) The cache shall be organised into a folder structure which reflects a concept of closeness to the user. A preliminary idea of this is the following
- Objects created by the user
- Objects created by friends of the user
- Objects created by users followed by the user, but aren’t considered friends (ie, news websites)
- Objects shared by the user
- Objects shared by friends of the user
- Objects which reference the user
- Objects referenced by the user
- Objects referenced by the users friends
- Objects from channels referenced by the user
- Objects by other users on channels which have been referenced by the user
When the cache limit has been reached, objects will be deleted using the following formula.
- List objects in the folder furthest from the user.
- Ignore anything younger than 24 hours (or any arbitrary time period which gives messages time to be passed on to somewhere more relevant on the network)
- Sort remaining objects by the kademlia concept of closeness to the users id
- Delete the farthest away objects on this list until the cache size is under the cache limit.
Clearing the cache this way increases the speed and chances of objects being findable to other users, as they can sort peers by closeness to the object they seek.