The Next Social Network
I've been talking with colleagues and thinking about this for a long while, now... I'm going to try to organize my thoughts on this in this post.
First, I believe there is a lot more to gain by decentralizing things a bit... that includes social networks. Facebook has become a behemoth, with a lot of strength and influence. It's not that I don't like Facebook, in general. I really just don't feel comfortable putting that much power into the hands of a corporation, who's primary goal is to make money and satisfy their investors.
That said, I don't want to create the next Facebook or MySpace... My goal is more along the lines of what I used to think the web should eventually grow to be when I was first learning about HTML. Everybody sharing everything they want to share, in real time, with the world. A vast interconnected landscape of users and devices, all able to communicate and share data, content, and media, instantly, whenever a connection is available.
The User Interface
- People should be able to easily share content and media, using their own equipment and bandwidth, that they pay for (I mean, it's cheap, right? People have hardware and bandwidth to spare, at home, at least).
- It should be easy to decide exactly who has access to the content you share.
- Shared content should be deletable (unless of course, someone made a local copy).
- Keys should be used for access (not insecure usernames / passwords), also makes centralized data store for authentication unnecessary.
- Each server should have a stream of yours' and other users' content.
Easily Share Content
The first rule, it has to be dead simple to share. At least as easy as it is to share on Facebook. Type a status, post. Paste a link, post. Drag a photo, post.
There should be no additional cost... Have a default setting for share level, if you want to post something that is visible to some other group, not the default, that can incur a small cost, just as it does in Facebook.
Easy Content Restriction
Again, this should all be key based. If you are visiting your own instance, you would have total control... granted by your key. If someone else is visiting, assuming you've added their key to a special access group, they would be able to see exactly what you've granted them access to see, and nothing else. If someone visits your site without a key, or with a key you haven't given any access to, they would only be able to see the public content.
Content is Deletable
Anything that you've shared should be deletable, and clients should auto delete anything that was deleted from someone's server, if it is marked as deleted when they pull information, again. This isn't going to be totally enforceable... same rules as today, apply, "If you share something online, assume it will never be deletable." Of course, if you never give others access to that material, it should never get into the wild, either.
Public / Private Keys
It's time for key based authentication for the masses. This can be made a lot simpler than it has been. I don't know why it has taken so long for it to catch on, but it's time. We don't have to remember 30 different passwords for all of our different sites any more. We only need one strongly encrypted key (actually a few, one per client device we use, but that's another post). Keys are the only way to truly decentralize this.
Without keys, we either need central authentication servers, which all instances of the software would need to trust or we are back in the place where we either use the same password for a hundred different sites, or a hundred different passwords... horrible, either way...
The Stream
The stream will consist of updates from you and others (filtered however you wish), which you can view and comment on, as you decide. This stream will not be filtered or displayed algorithmically, unless you decide to do it. Your server will occasionally fetch updates from servers where you have specified you want to see updates.
The source
There are also some guidelines for the software to make this all possible:
- It should be small, fast, and simple with few (if any) dependencies, making it able to run on anything from a desktop pc, to a network attached storage, to a router with a hard drive plugged into it.
- It should be simple and fast to setup with defaults that work for at least 80% of the people using it (no configuration files, no professional administrator, ssh access, etc).
Small, Fast, Few Dependencies
In order to make this as small, fast, and portable as possible, it should probably be written in language that allows you to get close to the metal. I'm thinking C++, you only pay for what you use. It should have very few dependencies, certainly no large relational databases. Maybe a small one for the key store, but I'm not even sure that's necessary, yet.
I think making everything file based would be simplest, though, I'm not yet sure how it will work and be fast enough. It will probably need some sort of engine to parse the files and structure them all as json data to be accessed through the API's.
Simple, Fast Setup
The setup shouldn't require a server admin. Eventually, it should be as easy as plugging in a device and giving it a copy of your public key to give you administrative access.
After giving it your public key, it authenticates you really quick then steps through a few important settings (import settings from existing instance, set default share level, etc...).
Making it Available
Making this work for households with their own subscription to internet service, should be beyond simple, with a few UPNP rules. However, making it work for people with shared connections, where the users have no control of the router, like universities, apartment buildings, community homes, etc... will be much harder.
- Use TOR hidden services for addressing (no need to maintain a domain name, no need to give up information about where you're located with your IP address).
- Use UPNP to open ports in the routers / firewalls.
- Use relays for devices in shared connection settings.
Addressing Using TOR Hidden Services
While some may consider it overkill, privacy is important to me. I'm sure there are others that would appreciate not broadcasting to the world what region they live in, what internet provider they use, as well as all the other little bits of information that can be gleaned from your IP address. TOR hidden services kill two birds with one stone. They make it harder to find your server, as you won't be giving out your IP address to all your friends (and their friends and their friends friends, etc). Also, TOR hidden service addresses are free, and won't be squatted on, or snatched if you forget to renew your domain (there is no registering, so there is no renewing).
Universal Plug and Play (UPNP)
The server should request the necessary ports opened each time it starts (and closed when it stops) from a range of ports, so we can make port sniffing to find servers harder, as well as play nicely with other services on the network. Also, it makes it easy for anybody to setup (as long as their router supports UPNP).
Relays for Internal / Shared Connections
Essentially, there will need to be relays (stable fast connected instances) which can be connected to from the services that are not able to be seen on the public internet, due to sharing a connection where users don't have control of the routers, or misbehaving ISP's, or whatever else may happen.
These relays should only happen on the fastest, most stable connections. The software should probably decide which instances are promoted to relays, automatically, based on up-time, connection speed, etc. Of course, there will need to be a kill switch, but it should have appropriate notices about the legal protections that relays and such will get (as they will essentially be network providers and wouldn't be expected to police the traffic moving across their device, as if they could... it's encrypted).
The Application Programming Interface
The interface should have at least a couple of different API's, making a decoupled data / web structure seem the way to go. However, I would prefer the recoupling to happen in the backend, but I don't really know if that's necessary.
- One should serve up HTML / CSS / JS, like a normal web site, so people can browse other people's pages (where their keys have been given access, of course).
- Another should serve up some minimal data format (think application/hal+json, or one of the other million publishing protocols available), so aggregators can pull people's streams to their own servers for perusal at their own convenience.
- The owner's public key should be accessible.
Web Page Display
When visiting a user's server from a browser, you should be given a standard display of the user's information (posts, bio, photos, etc) that your authenticated key has been granted access to. The owner can apply themes to this view, as they see fit.
While this will be an easy way to see one person's updates, it won't be the standard way to look at them / comment on them, that will be in your own stream, that you control.
Data API
A data API should be exposed by the service, which will allow other's servers to grab updates, as scheduled (or when force refreshed). This data API should only send the data that is needed to ensure the data on the requesting server is up to date. There need not be any style information sent or anything else. In fact, any source code in this stream should probably be suppressed.
The Owner's Public Key
There should also be an interface to retrieve the server owner's public key, as well as share your public key with the server. This way we can all get connected programmatically, for the most part. For instance:
- Visit a friend's server.
- Verify that it is actually that friend's server.
- Upload your public key, so your friend can give you custom access.
- Download your friends public key, giving them the access you wish them to have.
Decentralization is Key
What I'm envisioning, has a lot of parts and will take a lot of effort to get it right. It won't require fancy hardware or even fast connections. It won't require paying many times more for your storage, than you would for a standard external hard drive. It has the potential to change things. When Facebook, Twitter, and YouTube are blocked by the powers that be, we lose access to large troves of information and ways to share new information.
I want to make it harder for people in power to block communication for large swaths of people with a single block of IP addresses. I want to make it so easy to share information that anybody can do it, at any time, from anywhere, with the simplest of connections to the public internet.
Decentralization is what makes all of this possible. It will also give us a social network free of ads (unless users start adding them to their streams, of course, but if that happens and you don't want to see it, you just stop following that stream). It gives us a social network free from the tinkering of algorithms by the great experimenters, the data scientists of the current social networks. We see the information how we want to see it, when we want to see it.
No more policing what can and can't be shared, though, so far, it has mostly been for the good, but it shouldn't be necessary. People can police themselves. They can avoid trolls, themselves. I realize this may be a jaded view... but, I think people are inherently good. I feel like we can determine the users being bad and decide for ourselves if it is worth seeing or not.
Published