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
- A la carte : Everyone pays for what they use. No ads, no subscriptions, no piracy.
- Users control their data : Data does not reside with the application - it resides with the user. Services have to share data and users can take their data elsewhere if they're unhappy with a service - no hostages.
- Security and privacy : You never have to disclose a real identity, you control who has access to what information. Systems use the correct level of encryption for the task at hand - the only time something is unencrypted is when it is meant for broadcast.
Axioms
- Most components are honest most of the time
- Most components are naive most of the time
Core Components
- Servers: Represented by a IPv6 address, 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.
Local VM
The web browser has kind of become a nightmare. I propose using a sort of VM (as in JVM). The application requests a VM based on a security model. So any application can get an ephemeral, limited instance because it would be difficult (hopefully impossible) to run an attack that way. An application can make specific security requests - sandbox local storage, clipboard, microphone, camera, open user specified files (through a dialog box), unfettered access to the hard drive (probably only for trusted applications).
This can then be matched with "trust services" (something that will be required anyway) to establish how trust-worthy an application (and the server's it's going through) is.
For getting a prototype running, there are several "security sandbox" options. I want to focus on building a security sandbox
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.
Authentication and Key Management
This would not be a part of the spec, but it is important to demonstrate that workable solutions exist within the space.
There are a few problems that need to be addressed that arise out of naive users:
- Multiple devices
- Using a device you don't own
- Losing a key file
Username Password Authentication
This is of course the least secure and we can encourage people to not use it. But it is comfortable and familiar and better than nothing. Under this scheme, a private key file would entrusted to an identity server and you could gain access to it by giving the correct username and password.
Device Authentication
A take on two factor authentication - a device that can be uniquely identified (most likely a phone) serves as a form of identification and you can only proceed using that device.
Local Authentication Server
Using a phone or tablet with wifi or bluetooth, the device becomes the authentication server after establishing a connection to the non-owned device.
Social Network Backup
A copy of a master key is encrypted with A producing file B. B is stored in an accessible place (storage server), and A is distributed among a social network. To recover the original master key, the individual must identify themselves to the members of the network (in person, over the phone, or some audio/visual IP method) who can authenticate their identity. When enough pieces are reconstituted, the key is recovered.
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.