A decentralized social media faces two critical challenges: how to store global data on a blockchain and prevent spam, all while being feeless. To address the first issue, we suggest avoiding blockchain technology and instead utilizing "public key based addressing" and a peer-to-peer pubsub network. A blockchain or DAG is unnecessary for social media as it does not require knowledge of transaction order to prevent double spends. Moreover, it is not concerned with the availability of old posts. To solve the spam problem, our proposal suggests having subplebbit owners run a "captcha service" node over peer-to-peer pubsub. Peers who fail too many captchas are blocked from pubsub.
Public key based addressing
In Bittorrent, a concept known as "content based addressing" is utilized, where the hash of a file serves as its unique address. Similarly, with "public key based addressing," the hash of a public key is used as the address for the subplebbit. To access the content of the subplebbit, network peers conduct a DHT query using this address. It is important to note that each time the content is updated, the nonce of the content increases. However, the network only retains the most recent nonce, ensuring the latest version of the content is accessible.
Peer-to-peer pubsub
Pubsub is an architecture in which users subscribe to a specified "topic," such as "cats," and subsequently receive any published messages related to that topic. In a peer-to-peer pubsub network, both publishing and subscribing are open to anyone. To post content to a subplebbit, a user can publish a message with a "topic" equivalent to the subplebbit's public key, which is based on public key addressing.
Captcha service over peer-to-peer pubsub
In order to prevent spam attacks and ensure effective moderation, we have implemented a solution for our open peer-to-peer pubsub network. Publishers are now required to request a captcha challenge from the subplebbit owner's peer before publishing any content. This helps to prevent DDOS attacks and makes it difficult for bots to spam the network. If a peer or IP address relays too many captcha challenge requests without providing enough correct answers, it will be blocked from the pubsub.
To ensure transparency, the subplebbit owner's peer broadcasts the result of all captcha challenge answers, and each peer keeps this information for a certain period of time. It is important to note that the captcha implementation is at the discretion of the subplebbit owner, who can choose to prompt all users, first-time users only, or no users at all. Additionally, third-party services like Google captchas can be used.
Lifecycle of creating a subplebbit
- Subplebbit owner starts a Plebbit client "node" on his desktop or server. It must be always online to serve content to his users.
- He generates a public key pair, which will be the "address" of his subplebbit.
- He configures captcha options, like how often and what kind of captchas to show.
- He publishes the metadata of his subplebbit to his public key based addressing. This includes subpebblit title, description, rules, list of public keys of moderators, etc.
Note: It is possible to delegate running a client to a centralized service, without providing the private key, which makes user experience easier, without sacrificing censorship resistance.
Lifecycle of reading the latest posts on a subplebbit
- User opens the Plebbit app in a browser or desktop client, and sees an interface similar to Reddit.
- His client joins the public key addressing network as a peer and makes a DHT query for each address of each subplebbit he is a member of. The queries each take several seconds but can be performed concurrently.
- The query returns the latest posts of each subplebbit, as well as their metadata such as title, description, moderator list and captcha server URL.
- His client arranges the content received in an interface similar to Reddit.
Lifecycle of publishing a post on a subplebbit
- User opens the Plebbit app in a browser or desktop client, and sees an interface similar to Reddit.
- The app automatically generates a public key pair if the user doesn't already have one.
- He publishes a cat post for a subplebbit called "Cats" with the public key "Y2F0cyA..."
- His client joins the pubsub network for "Y2F0cyA..."
- His client makes a request for a captcha challenge over pubsub.
- His client receives a captcha challenge over pubsub (relayed from the subplebbit owner's peer).
- The app displays the captcha challenge to the user in an iframe.
- The user completes the captcha challenge and publishes his post and captcha challenge answer over pubsub.
- The subplebbit owner's client gets notified that the user published to his pubsub, the post is not ignored because it contains a correct captcha challenge answer.
- The subplebbit owner's client publishes a message over pubsub indicating that the captcha answer is correct or incorrect. Peers relaying too many messages with incorrect or no captcha answers get blocked to avoid DDOS of the pubsub.
- The subplebbit owner's client updates the content of his subplebbit's public key based addressing automatically.
- A few minutes later, each user reading the subplebbit receives the update in their app.
- If the user's post violates the subplebbit's rules, a moderator can delete it, using a similar process the user used to publish.
Note: Browser users cannot join peer-to-peer networks directly, but they can use an HTTP provider or gateway that relays data for them. This service can exist for free without users having to do or pay anything.
What is a "post"
The content of a post cannot be retrieved through direct querying of a subplebbit's public key. Instead, a list of "content based addressing" fields is retrieved. For example, the latest post might appear as "bGF0ZXN0..." while the metadata might appear as "bWV0YWRhdGE...". Subsequently, the client will carry out a DHT query to retrieve the content. At least one node of the subplebbit's owner client should possess the data. In the event of a subplebbit being popular, other peers will distribute the load, similar to Bittorrent.
Using anti-spam strategies other than the captcha service
The captcha service, which is currently the most versatile strategy, can potentially be replaced by alternative anti-spam measures. One such measure could involve requiring users to demonstrate proof of balance in a specific cryptocurrency, such as holding at least 1 ETH or 1 token of their choice, before allowing them to post on a subplebbit.
Another approach could involve implementing a proof of payment system, where each post must be accompanied by a minimum payment to the subplebbit owner. This payment-based system could be particularly suitable for celebrities who wish to utilize their subplebbit as a platform for fan interaction, similar to "onlyfan" platforms where fans pay to engage with their favorite personalities. While these strategies may not completely eliminate spam, they can significantly reduce the overwhelming amount of spam and ensure that it remains manageable for human moderators.
The deterministic nature of proof of balance/payment allows the P2P pubsub network to effectively block spam attacks. Furthermore, additional strategies can be explored and implemented to cater to the specific needs of different communities. However, it is important to note that, for now, the captcha service remains the most adaptable and widely used approach.
Improving speed of public key based addressing
A network query based on public key addressing is slower than one based on content addressing because it requires continuous searching even after finding a peer with the desired content, to ensure there are no peers with more recent content (later nonce). With content addressing, the search stops as soon as a single relevant peer is found as the content is always the same. It is possible to achieve comparable speed on Plebbit by setting X-minute expiration times for public key-based addressed content and having the subplebbit owner republish the content every X minutes. With this approach, only one valid content runs at any given time, and you can deterministically end your search as soon as you find a peer with it.
Unlinking authors and IP addresses
In Bittorrent, it is possible for an attacker to identify the IP addresses of all the users who are sharing a torrent. However, the IP address of the original uploader of that torrent remains undisclosed. In the case of Bitcoin, an attacker has the ability to directly connect with all the peers in the network and can assume that the first peer to transmit a transaction to them is the one who initiated it. On the other hand, in Plebbit, this particular type of attack is mitigated by implementing encryption. The author encrypts their comment or vote using the subplebbit owner's public key. Consequently, while the attacker may be aware that a peer has published something, they are unable to determine the content or the specific author.
Conclusion
We believe that the proposed design resolves the issues of a decentralized Reddit alternative without a server or administrator. It permits an unlimited number of subplebbits, users, posts, comments, and votes while disregarding the sequence and accessibility of previous data. At no cost, users can create posts via a Reddit-like interface. Subplebbit owners can also evaluate spam semi-automatically via their private captcha service on a peer-to-peer pubsub platform. It would enable access to all the features that make Reddit addictive, such as upvotes, replies, notifications, awards, and the opportunity to reach the "front page". Moreover, it allows the Plebbit client developers to serve an unlimited number of users without requiring any server, legal, advertising, or moderation infrastructure.
To get involved, please contact me on Telegram @estebanabaroa or Discord estebanabaroa#2853. We are currently hiring JS developers.