Distributed Social Networking

A protocol for social networking so that data can be decentralized.

Social media is moving into the commodity range. It would be nice to have a standard protocol so that the value of network could be leveraged while each node in the network specialized in a specific niche.

Core Components

• Servers: Represented by a URL, data lives here
• Users: This is the core representation of a user. A public/private key
• User-Data: Data owned by the users. SERVERS DO NOT OWN DATA, they hold it
• Permissions: Who has access to what data
• Integrity: How much trust a server has earned from the network
• Adjudicator: When a tab is in dispute a third party server can resolve the dispute

Contracts

There are specific types of contracts that servers and users can enter into. Broadly speaking, they are divided into content-delivery and processing.

Payments

Bitcoins are exchanged for fulfilling requests, holding data and so forth. Your server(s) hold coins in escrow for you. As you make requests, you rack up a tab on other servers. The tab has two 'due' conditions - a date and an amount. Failing to pay a tab means that server will no longer honor your requests and the server acting on your behalf will take a hit to it's Integrity rating. What should happen is that as your tab comes due your server should pay it for you. The server should not let you rack up more debt than you have in your escrow.

I'm not sure how to incorporate this, but there is room for a model where users can earn money for their media. Basically the server gives them a kick-back.

Security

Gives me a headache just thinking about this. A user has a private key that is either never shared or entrusted to server. If it is entrusted to a server, the user needs to have absolute confidence in that server. Other servers can get an executor-key (with specific permissions) which allow them to act on your behalf.

I think I'll go with the secure one-time pad model; a secure line of communication is established with the public key and only used to exchange one-time keys. This can even be done at the JavaScript level so that the public key is never transmitted.

Examples

Viewing a Picture

You open up your page. The server begins making requests to pull updates about your friends. Any server can do this on your behalf - it just sends a request for updates with your public key. The updates are each hashed, and the hash signed with the corresponding friends private key, then the whole thing is packaged up and encrypted with your public key. Included in the updates from each server is a pricing, like 5 credits per request plus 1 credit per k. That is delivered to your browser where it is decrypted and displayed. You see that a friend has uploaded a picture and part of the update package was a low-res thumb and that the image is available in 50k, 200k and 1,000k. You click to see the full image and your client determines that the 200k image is best for your display. A request is generated identifying the image and stating the price you expect to pay for it (205 credits), the hash of the request is signed with your private key and the whole thing is encrypted with your friends executor-public-key (the public key that represents your friend on that server). The request is sent the server holding your friends image where it is processed. The server generates a symmetric key, encrypts the image with the symmetric key, the symmetric key is encrypted with your public key, the two are packaged up and sent back to you. One note - I think it would be (reasonably) safe and efficient for resources to be encrypted once with a symmetric key, and the same symmetric key is distributed to anyone with permissions to that resource. These two actions can then be separated. A CDN type server (no processing, no security) can deliver the already-encrypted-image while a secure server can deliver the key. -- moving on -- The image and the key are delivered to your browser, your public key unlocks the symmetric key, the symmetric key unlocks the image and you see a funny gif of a cat sitting on a baby's head. Your tab on the other server is incremented by 205 credits.

Notes

One of the big wild cards is dropped requests. If a server honestly sends me something but I never get it - who pays? How is that arbitrated? Maybe we could use packet level statistics - if I'm transferring you an image, you send an AWK for each packet and we can establish that 99% of the time, the packets are received. If you go dark on the last packet, you're probably trying to duck payment and claim it was never delivered.