OurSpace: Distributed Serverless Anti-Hierarchical Social Media

The main idea is to use something like IPFS to establish a distributed non-hierarchical alternative to both the web and the incumbent social media institutions while also creating a resilient alternative which would form a thick protocol on top of which people can then construct and extend interfaces like apps or websites.

Imagine I have an RSS or JSON file representing my personal feed of social posts (text, images, video, audio, etc.) This is served over IPFS and/or other similar protocols such as GitTorrent, Tor, or simple HTTP.

Ideally, there would be a simple process for connecting a person’s persistent identity to a standard way of accessing their feed file via whatever means. So for example, I could use my Ethereum wallet address like a username (People already do this using QR Codes on Snapchat), and then people could automatically look up how to find my feed file via whatever network and protocol they are using. A simple DHT could link my public wallet address to the IPFS address for my feed file, and the GitTorrent address, the HTTP address, and/or a Tor address. So that everything works regardless of what network you are using.

I especially like the idea of using an Ethereum wallet address as a username because it would mean that authentication via metamask or something like that would already be a simple process which is widely adopted plus already being based on a strong distributed system. It would also make it easy to send money to people. Many activist content creators use their whole bio section to post their venmo, cash app, paypal, etc. This would greatly simplify that process.

For synchronous communication, there are already protocols like Tox which facilitate entirely distributed, serverless, end-to-end-encrypted direct messaging as well as voice and video calling.

It’s easy to see how this concept could supplant tools like facebook, twitter, whatsapp, etc. It would be objectively better from basically every perspective, plus it would mean people can easily write their own clients featuring whatever kind of aggregation, curation, etc they prefer. It could easily be extended to focus on extreme security and anonymity or as a  very public and resilient content management system for a blog. There are so many directions and so much potential!

Existing Examples and Case Studies

Here is an example of a very similar approach to implementing a podcast player;

https://hackernoon.com/how-i-built-a-complete-p2p-rss-podcast-app-in-a-single-html-file-uo1631z1

 

The Hard Part

It’s very easy to publish data on IPFS or bittorrent or whatever. You get a unique hash which anyone can use to access what you have published. So Maybe you publish the index file for a website and then inside the file it links to all the other resources which you have also published.

(This all already works. See the example linked above.)

The hard part is revisions. If you change anything, then your original hash doesn’t work for the new revision and so you need a way to connect users to the current hash in order for them to find your current content.

I have thought a lot about this over the last few months and I have read extensively about the theory around the different ideas people have come up with to solve this problem.

GitTorrent is already a good solution to versioning but it still requires DNS as far as I can tell from reading the documentation. DNS is a hierarchical and fragile and high-latency system so that’s not a good fit for this.

DHT means distributed hash table. This is a distributed KVS or key/value store so you put some data and you get a hash which you can share and that will let people find the data. This is what a magnet links to. The data that the magnet’s hash points to in the DHT KVS is the list of hashes for the pieces of the torrent which you can then find from peers and assemble into whatever you’re trying to download.

This DHT KVS paradigm is very close to a good match, but there are still several problems to address.

Quick aside; one of the main fundamental arguments I wanted to make with this project is that is should always be trivially easy to send money to any user. Lots of people put their venmo/cashapp/paypal/etc on their bio on social media. I want that to be built into this project. So it would be really exciting to use an ethereum wallet public address as the central identifier of each user. This also has the benefit that a wide range of production-quality cryptography tools already exists around ethereum wallets. For example, metamask can easily sign things for you using your wallet. (Signing examples)

Okay so imagine this; a distributed hash table which has no unique primary key and has four columns:

  • First the primary key is the ethereum wallet public address for the users.
  • The second column is the publication timestamp for the main index or rss file or whatever their main file is.
  • Third, the current IPFS hash of their main file so that everyone can find it.
  • Last, it stores an ethereum signature to prove that the IPFS hash and publication timestamp belong to the ethereum wallet public address listed.

This means anyone can quickly and easily update their content and publish with extremely low latency to the entire fully-distributed network.

Following a given user (like we do on facebook or twitter) means your own app is going to automatically download and mirror their content (just like a podcast app would) and this means others can access that content from you, so the more followers you have the more easily accessible your content becomes.

What’s in a main file?

I really like the idea of using RSS with XSLT or something like it to serve a simple rss file that could also be styled as a webpage or blog. But really this file could be anything.

Meta tags in the file can link to things like the list of accounts you’re following, your secure protonmail address, your Tox address so that people can send you secure instant text, voice, and video calls. These could also all be hashed so that it’s possible to search for all the people whose email or phone number you have without them having to expose their phone numbers or emails to the network.

Then of course there is the social content you wish to publish in your feed.

All of these things can be integrated into apps so that users can seamlessly browse a list of popular or suggested mutual friends based on observable connections and then find accounts to follow.

Security and Privacy

IPFS is not secure. Anyone with the hash can download the file, just like with torrents. So it makes sense to include an option for end-to-end encryption for those who want to have their content be visible only to friends.

Simpler Usernames

It’s easy to imagine using domain names as a way to link to ethereum wallet public addresses. It could be as simple as having those addresses linked on the website or it could be a DNS text entry or some other kind of DNS record.

This would mean you are not reliant at all on DNS except as an optional shortcut to allow people to find your address without sharing the QR code or text address.