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.

Principles

• Mobility: At any point you can change your server without losing data or connections, much like the telephone network. You should even be able to use different services from different servers
• Service as Pig: "In any transaction, there are 3 parties - the farmer, the butcher and the pig. If you're not the farmer or the butcher...". Services are paid for by the consumer. See advertising.
• Security: All data will be secured. Security models will be explicit.
• Privacy: To the extent that it is possible. Once you share something with another party, you cannot prevent them from sharing it further. But you will have absolute control over who can access your data.
• Ownership: You own your data.

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
• Application: Can read and possibly modify data on behalf of a user.

Another Approach

• UII : User interface and identity servers. These are the servers that users actually connect to.
• Application Servers : Where the applications live. Directs the UII server on how to present information and accesses the data.
• Data Servers : Where user data lives.
  • Relational : Takes a sql like query and returns json - CRUD
  • Static : Takes a guid, can return json or binary data - CROD (overwrite, no update)
  • GUID : Takes a guid, can returns json - CRUD

The idea is that a killer app has to stand on it's own merits - not by holding your data hostage.

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.

This is a lot of complexity for the basic user. One potential solution to simplify things would be to have a desktop application to get a user started and walk them through a stripped down key management, then get them setup on a server with a more traditional log-in.

Data Templates & Applications

Different templates for storing data can be created and submitted to the community. Applications are written to use these templates. Simply through applications rising in popularity different data patterns should become dominant.

Advertising

From a technical standpoint, this does not require it's own section, it will operate just like everything else. But because this is currently the dominant model (and what I want to break) I will address it directly. Advertisements are fine, but the consumer should know they're being advertised to and what they get in return. Ad models (and tracking models) should be opt-in.

5/3/2013 Notes

• Guides
• Database Servers
• Application Servers

This framework is a little more theoretical, some aspects may not hold up in practice, but it's the most solid starting points I've had yet. Guide servers have a reputation and know who you are. You have an open account with them and they speak to the application and database servers on your behalf. Databases, as expected, hold data. Different servers can support different models and schemes. Application servers run applications. All data models and schemes as well as all applications are open source (there's those pesky assumptions). The assumption is as demand for models and schemes rises and falls, the servers supporting them will respond to the demand. Same with the application. Separating the data and application layers is good for many reasons I will not enumerate here. Guides build up tabs with database and application servers. There's a sort of fuzzy banking that goes on here, but I think it can be stable (enough). Guides build up tabs with database and application servers. Bills are paid in bitcoin, but can be pegged to a number of other metrics (usd, euro, gold, s&p).

Everything in the system has a reputation. User have UserReputations, Guides and GuideReputations and database and applicaiton servers have HardwareReputations. Actually, Guides have two types of reputation, UserReview and HardwareReview. Good service and prompt payment delivers good rewards and poor service or late payment earns negative rewards.

Users request applications from Guides. Guides relay those requests to application servers on the users behalf as well as handle the data transactions the application requires. The application and data servers add the cost of the transaction to the Guides tab. The guide, in return bills the client. When a users tab grows bigger than their reputation justifies, the guide requests payment. And when the Guide tab grows to large (with one of the hardware servers) payment is also requested. Of course, some entities will default on their bills. It is expected that the systems take this into account and charge accordingly.

Application Development

This is all fine but it leaves the incentivization of application development absent. I'm not sure how to solve this. The problem is piracy. If I write an application that any application server can run, it will be hard to prevent them from running it without paying me. It would be possible to make a dent with reputations. But, then any one could take my software resign it as their own.

Software is - fundamentally - a public good. We may be able to solve this with privileged groups, specifically, the application and database servers. Developers can setups "shops" that are funded by the application servers. The application servers make it publicly known when they are supporting a shop. The shops would have an implicit reputation based on the software they have developed. It may be that public pressure would keep the application and database servers funding the shops, but were that to collapse, it would be very difficult to re-establish.

5/14/2013 Notes

I was listening to Jaron Lanier and he raised some interesting points about where the current models are heading. I still feel like I'm close, but I'm missing my "Block Chain" breakthrough.

Rebuilding The Browser

One thing I keep waffling on is rebuilding the browser. It would increase the magnitude of the project significantly, but the current state of browsers kind of sucks. Rather than the current model, I was thinking of something far more of a sandbox model. One of the major barriers I see is the 'same origin' policy, which is just goofy at this point (and easily circumvented). I would also like to transition from the classic request model to a full socket model. It wouldn't invalidate the old way - a server could connect, deliver the necessary data and disconnect.

Copyright Enforcement

One of the issues raised above is getting payment to app developers. There are two ways in which this can be violated. The first is an app-server running the application without paying dues. The other is someone taking the source and repackaging it as their own.

To combat app-server piracy, app-servers would have reputation and theft would damage their reputation.

To combat payment theft, apps would be registered with app servers (by hash). If someone were to perform this form of theft, it could be demonstrated that their repository was more recent than the one they stole. It would then be marked pirated, the origin would be referenced and their reputation would be damaged.

The final problem, particularly difficult, is the combination of the two. An app-server (actually, the operator) could pirate a repository and pocket all the money. When called out, they shut down the repository and repeat with a new app. They can repeat this indefinitely.