It is time to create a decentralized public social network

We need a new way to subscribe to the world wide web

Photo by Kelly Sikkema on Unsplash

In this post I want to propose structure for a decentralized public social network. By combining web documents, decentralized databases and decentralized identity it is possible to create a new way to subscribe to the web.

The proposed social network would consist of three core parts: decentralized social posts, decentralized post indexes (channels) and channel reader platform(s).

1. Social posts

Today all our posts are the property of a social network company. You don’t have ownership rights to them and they can be lost, deleted or removed by the company any time. You are making a bet that the social network of your choice will never get bankrupt and will want to host your content on their website forever.

Another serious drawback of popular social networks is that your content is not easily shareable between different social platforms. Each platform will try to keep their customers inside and content created outside the platform will be discriminated (for example natively uploaded Facebook videos will look better in Facebook than Youtube video links).

In most social platforms public posts have a unique public URL. However discovering unique web address for your post is discouraged using dark UX patterns. For example in Facebook you have to press on post date to go to dedicated page of this post. There you can copy URL from the browser address bar and it looks something like this:

https://www.facebook.com/permalink.php?story_fbid=2213703585589774&id=100008504619342

As you can see the URL is ugly and in no way does describe the content of your social post. If somebody without Facebook account will try to view this content he will be greeted by aggressive popups encouraging to signup or login to the platform. Such URL behavior also discourages cross-sharing of social posts between different social networks.

In order to solve the problems mentioned above we should get back to the roots of the web and implement social posts as first-class web documents. It should be possible to host your posts on hosting provider of your choice and have a beautiful, SEO friendly URLs that would describe the content of the posts.

This would be a good example of a descriptive social post URL:

http://www.tautvilas.lt/social/today-i-found-something-interesting

This url pattern is adopted by blog posts because it makes sense to have beautiful urls in order to be easily indexed by search engines and have easy-to-remember human readable URL which can be shared across different platforms.

Blog posts and ordinary web pages today are bloated web documents that contain tons of complicated html code, javascript and style sheets. However we don’t need most of that for a simple social post web document. A social web post could be just a simple web page with meta tags that define social content. A simple social post page source code could look something like this:

This example social post has comment and attachment fields defined. There could be more field types, but I think these two would be more than enough to get us started.

As you can see this social post does not have an author name field. The reason for this is simple - in a decentralized social network the author of the post is the domain where the post is hosted on.

It is understandable that not everybody can buy and configure a domain to host their content. In order to simplify decentralized social network adoption for less tech-savvy users there could be platforms that would help people to create hosted social content and rent domains/subdomains for them. I will call such platforms ‘Social Post Writers’.

A Social Post Writer could be a commercial platform, that would have a subscription fee. It would have a simple interface that would allow you to compose a social post and give you a beautiful URL of it when you are done. Such a platform could also help you with uploading and hosting social media attachments such as videos and images. After you are done composing a social post you will be able to publish it to the decentralized social network channels.

2. Channels

Social posts are just simple web documents. They could be indexed by search engines and have a beautiful URLs, however that is not enough for a social network. We need an easy way to subscribe to certain authors (domains), to upvote and share the content that they create so that people can discover the content that their friends like.

I think that a decentralized database is a good way to achieve this goal. I call such a database a social network ‘channel’. I will not go into details how such a database could be implemented. I will just list the main features that such a database must have:

• It has to be public. The database can not have any secret private data.
• It has to be decentralized. The database would be hosted on many computers and each new entry would be processed using some sort of consensus algorithm.
• Each entry of the database has to be reasonably small. The social network can contain billions of updates and less people will want to host a database if it is too big.
• It has to be reasonably fast to process the updates
• It has to have protections from DDoS attacks and from too frequent automated posting

Each URL entry that is submitted to this database should have these properties:

• Submission time — timestamp when the record was published
• Social post URL — address of the web document. There has to be a characters limit for this field. Also query string parameters should be probably ignored.
• Social post fingerprint — hash for the meta tags of social post web document. This will help identify if social post was edited after submitting to the database.
• Author— the user (domain) that is submitting the post.
• Author signature — proof that the author domain is the submitter. The record should be signed with private key of the domain and public key should be discoverable on the domain in order to verify the claim.

The database would not host the content of social posts. It would only host the URLs to them and the proof that a certain user (domain) has posted them. This way we can keep the structure of the database really simple. There are several scenarios for posting to this database:

1. I post as tautvilas.lt, but the URL that I post is on another domain. That is the equivalent of ‘like’. I am not the author of the content, but I promote web document of some other domain.
2. I post as tautvilas.lt and the social post URL is tautvilas.lt/social/my-first-post. In this case the post is my original content. Other people can see this and they can ‘like’ (repost) this content.

The URL posted to the database can be a social post document, but it does not necessarily have to. It should be possible to share any URL, such as blog post, image and so on.

Anybody would be able to host this database. Also it should be really simple to write a tool that would read the updates of such database. Subscribing to updates from tautvilas.lt user(domain) should as simple as

tail -f /dev/channel | grep ‘tautvilas.lt’

3. Readers

Although it might be fun to implement a simple Social Network Reader (SNR) yourself this solution would not scale very well. If such a decentralized social network would start picking up speed I predict that commercial reader platforms would appear. The main functions of these platforms would be:

• Fetching URL preview and social meta content and caching it on their servers in order to display all social posts in a user-friendly way.
• Allowing each user to create subscription lists and have a beautiful realtime feed of the posts that a user is interested in.
• Creating community where users of the SNR platform would be able to interact with one another, leave comments on social posts and so on.
• Social content reader platforms would help to avoid the ‘hug of death’ for the original web content. In case your social post becomes wildly popular it will not be fetched from your hosting server millions of times. Instead it will be fetched once by social reader platform and cached on their servers.

In this scenario the reader platform would be like a higher layer of the decentralized social network. A community of one reader platform would be different from another platform. That means we could have more meaningful and more localized discussions and interactions that are based on the same decentralized social network database core. Each social network reader also could have different monetization model — one could be funded by ads, other by a subscription membership fee or donations.

Summary

I have introduced structure for a decentralized social network that would be made of three main parts:

• social posts that are simple HTML documents. Social post writing tools could help people to write and host these web documents.
• decentralized databases (channels) where URLs to these posts or any other web content would be stored.
• social network readers that would process the data stored in the channels and would display this information in a user-friendly way.

I see great potential for such a solution because it combines the fundamentals of the web and decentralization together with opportunities of profit and commercialization. Such a decentralized social network would give back control to people by allowing direct ownership of their social content. Also a decentralized social network would make sharing and discovering content online easier and more convenient than ever before.