# Design idea to solve the scalability problem of a decentralized social media platform using IPFS

**URL:** <https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158>\
**Category:** Help\
**Created:** [September 10, 2021, 4:39pm UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158 "2021-09-10T16:39:54Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![estebanabaroa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/estebanabaroa/32/5422_2.png) [@estebanabaroa](https://discuss.ipfs.tech/u/estebanabaroa)\
**Post date:** [October 2, 2021, 12:47am UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/21 "2021-10-02T00:47:03Z")

</div>

After getting some feedback I have added 2 new sections:

**Censorship resistance of the captcha server**

Captcha servers are not as censorship resistant as a purely P2P network, because it requires a direct connection to some HTTP endpoint. If this endpoint is blocked by your ISP or DDOSed, then you can’t connect. These attacks can be mitigated in a few minutes by changing the captcha server URL of your subplebbit, or using DDOS protection like Cloudflare. In a pure P2P network, if some peer is blocked by your ISP or DDOSed, some other peer should be available. A pure P2P captcha server solution seems impossible at this time because requesting a captcha challenge is not deterministic, so how would peers in this network deterministically block a bad peer spamming captcha challenge requests? If a solution for a P2P captcha server is found it should be attempted.

**Using anti-spam strategies other than the captcha server**

The captcha server can be replaced by other “anti-spam strategies”, such proof of balance of a certain cryptocurrency. For example, a subplebbit owner might require that posts be signed by users holding at least 1 ETH, or at least 1 token of their choice. Another strategy could be a proof of payment, each post must be accompanied by a minimum payment to the owner of the subplebbit. This might be fitting for celebrities wanting to use their subplebbit as a form of “onlyfan”, where fans pay to interact with them. Both these scenarios would not eliminate spam, but they would bring them down from an infinite amount of spam, to an amount that does not overwhelm the pubsub network, and that a group of human moderators can manage. Proof of balance/payment are deterministic so the P2P pubsub network can block spam attacks deterministically. Even more strategies can be added to fit the need of different communities if found, but at this time the captcha server remains the most versatile strategy.

The idea for proof of payment/holding came from @wclayf

---

<div class="post-metadata">

**Author:** ![estebanabaroa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/estebanabaroa/32/5422_2.png) [@estebanabaroa](https://discuss.ipfs.tech/u/estebanabaroa)\
**Post date:** [October 24, 2021, 8:35pm UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/22 "2021-10-24T20:35:44Z")

</div>

I realized that a full captcha challenge request-anwser-validation actually is deterministic, and could work over P2P. If a peer or IP address relays too many captcha challenge requests without enough correct captcha challenge answers, it gets blocked from the pubsub, deterministically. The captcha challenge request alone is not deterministic, but the entire exchange is. This would require 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.

So the “captcha server” over HTTP in the original design can be replaced for a “captcha service over peer-to-peer pubsub” design, which would make the entire design of Plebbit peer-to-peer. I will post an update to the entire redesign soon.

---

<div class="post-metadata">

**Author:** ![estebanabaroa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/estebanabaroa/32/5422_2.png) [@estebanabaroa](https://discuss.ipfs.tech/u/estebanabaroa)\
**Post date:** [October 24, 2021, 9:24pm UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/23 "2021-10-24T21:24:57Z")

</div>

**Captcha service over peer-to-peer pubsub**

An open peer-to-peer pubsub network 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 captcha 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 use 3rd party services like Google captchas.

**Lifecycle of publishing a post on a subplebbit**

 ![4](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/b/b29d19c23beca09e85e41ba1dfb8060838462381.png)  
 ![6](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/8/84214675b0e672dae8d4c27d4011b156195be6bf.png)

1. User opens the Plebbit app in a browser or desktop client, and sees an interface similar to Reddit.
2. The app automatically generates a public key pair if the user doesn’t already have one.
3. He publishes a cat post for a subplebbit called “Cats” with the public key “Y2F0cyA…”
4. His client joins the pubsub network for “Y2F0cyA…”
5. His client makes a request for a captcha challenge over pubsub.
6. His client receives a captcha challenge over pubsub (relayed from the subplebbit owner’s peer).
7. The app displays the captcha challenge to the user in an iframe.
8. The user completes the captcha challenge and publishes his post and captcha challenge answer over pubsub.
9. 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.
10. 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.
11. The subplebbit owner’s client updates the content of his subplebbit’s public key based addressing automatically.
12. A few minutes later, each user reading the subplebbit receives the update in their app.
13. 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.

---

<div class="post-metadata">

**Author:** ![estebanabaroa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/estebanabaroa/32/5422_2.png) [@estebanabaroa](https://discuss.ipfs.tech/u/estebanabaroa)\
**Post date:** [March 30, 2022, 3:52am UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/24 "2022-03-30T03:52:20Z")

</div>

2 new sections have been added to the whitepaper:

**Improving speed of public key based addressing**

A public key based addressing network query is much slower than a content addressing based one, because even after you find a peer that has the content, you must keep searching, in case another peer has content with a later nonce (more up to date content). In content based addressing, you stop as soon as you find a single peer, because the content is always the same. It is possible to achieve the same speed in Plebbit, by having public key based addressing content expire after X minutes, and having the subplebbit owner republish the content after the same X minutes. Using this strategy, there is only ever one valid content floating around the network, and as soon as you find one peer that has it, you can deterministically stop your search.

**Unlinking authors and IP addresses**

In Bittorrent, an attacker can discover all the IP addresses that are seeding a torrent, but he can’t discover the IP address of the originator of that torrent. In Bitcoin, an attacker can directly connect to all peers in the network, and assume that the first peer to relay a transaction to him is the originator of that transaction. In Plebbit, this type of attack is mitigated by having the author encrypt his comment or vote with the subplebbit owner’s public key, which means that while the attacker can know the peer published something, he doesn’t know what or from what author.

---

<div class="post-metadata">

**Author:** ![sandalcloud](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sandalcloud/32/6135_2.png) [@sandalcloud](https://discuss.ipfs.tech/u/sandalcloud)\
**Post date:** [April 4, 2022, 2:21am UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/25 "2022-04-04T02:21:27Z")

</div>

**Very strong text!**

---

<div class="post-metadata">

**Author:** ![yeehi](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/yeehi/32/2760_2.png) [@yeehi](https://discuss.ipfs.tech/u/yeehi)\
**Post date:** [June 11, 2022, 6:40am UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/26 "2022-06-11T06:40:20Z")

</div>

I think you are underestimating the importance of integrating search functionality into Plebbit. One reason people turn to alternative platforms is because of censorship. Content is deleted and lost. A lot of work, for example research or creating content or organizing archives is lost because it is no longer discoverable.

I hope you include search and archiving tools into Plebbit. It should certainly have a bookmarking system that helps people catalogue content and share notes. There is excellent Free Software for this already: Shaarli. Perhaps Plebbit could integrate some Shaarli functionlity.

> **[GitHub - shaarli/Shaarli: The personal, minimalist, super-fast, database...](https://github.com/shaarli/Shaarli)**
>
> The personal, minimalist, super-fast, database free, bookmarking service - community repo - GitHub - shaarli/Shaarli: The personal, minimalist, super-fast, database free, bookmarking service - comm...

---

<div class="post-metadata">

**Author:** ![estebanabaroa](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/estebanabaroa/32/5422_2.png) [@estebanabaroa](https://discuss.ipfs.tech/u/estebanabaroa)\
**Post date:** [June 11, 2022, 2:50pm UTC](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158/28 "2022-06-11T14:50:49Z")

</div>

> [@yeehi](#):
>
> I think you are underestimating the importance of integrating search functionality into Plebbit.

Search is not included not because it’s not a wanted feature, it’s not included because it seems impossible to do P2P.

Not having search doesn’t seem to be a dealbreaker in terms of core functionality of reddit, I’ve never once used the search function of reddit in the 10 years I’ve used it. Reddit does come up on Google, which is very useful, but my hope is that independent people will run “archivers” similar to how they do it for 4chan. 4chan posts expire after a few days, but there are several archivers that archive them and those can be found on google and searched.

It’s very easy to archive a complete subplebbit over P2P using plebbit, but it’s very slow.

[Previous page](https://discuss.ipfs.tech/t/design-idea-to-solve-the-scalability-problem-of-a-decentralized-social-media-platform-using-ipfs/12158.md?page=1)
