Plebbit is a protocol and tooling for creating decentralized forum applications like Reddit, Facebook groups, Discourse, etc. It's a pure P2P protocol, it doesn't use any central server, databases, public HTTP end point, DNS, etc. It uses parts of the IPFS and Ethereum stack to create everything it needs:

• IPFS for immutable data, like a published comment or a recent subplebbit page.

• IPNS for mutable data, like replies to a comment, upvote counts, new posts/comments published on a subplebbit, etc.

• IPFS pubsub for authors publishing comments/votes to a subplebbit and for the captcha challenge exchange between authors and subplebbits.

• ENS for usernames, community names, and serving the client in browsers.

Scalability and fees

A decentralized social media/forum has 2 problems: How to store the entire world's data on a blockchain, and how to prevent spam while being feeless. We propose solving the data problem by not using a blockchain for content, but rather IPNS and IPFS pubsub. Unlike cryptocurrencies that must know the order of each transaction to prevent double spends, social media does not care about the order of posts, nor about the availability of old posts.

Note that we must still use a blockchain (ENS) for usernames and community names because those do care about doublespends and ledger history availability.

IPNS

The IPNS name (also ENS name) is the name and address of the subplebbit, e.g. "memes.eth".

Pubsub

To publish a post to a subplebbit, a user would publish a pubsub message with a "topic" equal to the subplebbit's ENS name. This allows the subplebbit owner to reply with "challenge" and "challengeverification" messages signed with his ENS' public key that all pubsub peers can verify.

Captcha service over pubsub

Nondeterministic pubsub (like user generated comments) is susceptible to spam attacks that would DDOS it, as well as makes it impossible for moderators to manually moderate an infinite amount of bot spam. We solve this problem by requiring publishers to first request a captcha challenge from the subplebbit owner's peer. If a peer or IP address relays too many captcha challenge requests without providing enough correct captcha challenge answers, it gets blocked from the pubsub. This requires the subplebbit owner's peer to broadcast the result of all captcha challenge answers, and for each peer to keep this information for some time.

Note: The challenge implementation is completely up to the subplebbit owner. He can decide to prompt all users, first time users only, or no users at all. He can proxy 3rd party services like Google captchas. He can use other challenge types, like a proof of stake/holding/payment of a certain token, a whitelist, invite list, etc.

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 an IPNS public key, and adds it as a TXT record to his ENS name, 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 IPNS record. This includes subpebblit title, description, rules, list of public keys of moderators, etc.

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.eth"

• His client joins the pubsub network for "cats.eth"

• 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.