Are the ethereum based social networks going to miss yet another opportunity?

It's too early to take over from Twitter.

Most people don't have any coins so you can't do anything involving coins. Anything involving storing and shipping data over P2P at scale is too unreliable, so you need a central server anyhow. The only part we've sort-of solved is key management which we could use for encrypted DMs etc but that's still an extra hurdle for users to migrate.

Just use Mastodon. Mastodon is very extensible, once we've got out of the control of a single company we should be able to bolt on ENS integration, encrypted DMs and data over P2P, as and when they're good enough.

Take a look at Lens, Farcaster and Urbit. Easiest way to use lens on mobile is with Orb.

Edit: oh and for a version of Reddit: http://gm.xyz

I like lenster

Smartcontracts are currently being actively used only by DeFi. In other general areas, however, a wretched failure must be frankly acknowledged. Originally, smartcontracts were not aimed at Defi. Rather, Ethereum was a platform designed for general fields. It can be confirmed by the fact that the ERC20 token did not exist at the time of Ethereum's launch, but was only developed later.

The problem is that despite this situation, Ethereum Foundation and other stakeholders are not very concerned about this problem. Everyone is focused on money businesses.

Currently, Apple and Google are successfully operating app markets on mobile. It should be a lesson.

Peepeth still exists https://peepeth.com/

Newer projects are Farcaster and Lens.

I wrote a whitepaper for a Reddit alternative that would use IPFS (basically Bittorrent), IPNS (mutable Bittorrent) and peer to peer pubsub. It wouldn't need any central server, DNS, and it would scale infinitely for free, like Bittorrent:

Plebbit: A serverless, adminless, decentralized Reddit alternative (Whitepaper v0.2.0)

Abstract

A decentralized social media 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, but rather "public key based addressing" and a peer-to-peer pubsub network. A blockchain or even a DAG is unnecessary because 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. We propose solving the spam problem by having each subplebbit owner 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, you have "content based addressing". The hash of a file becomes its address. With "public key based addressing", the hash of a public key becomes the address of the subplebbit. Network peers perform a DHT query of this address to retrieve the content of the subplebbit. Each time the content gets updated, the nonce of the content increases. The network only keeps the latest nonce.

Peer-to-peer pubsub

Pubsub is an architecture where you subscribe to a "topic", like "cats", then whenever someone publishes a message of topic "cats", you receive it. A peer-to-peer pubsub network means that anyone can publish, and anyone can subscribe. To publish a post to a subplebbit, a user would publish a message with a "topic" equal to the subplebbit public key (its public key based addressing).

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 creating a subplebbit

1. Subplebbit owner starts a Plebbit client "node" on his desktop or server. It must be always online to serve content to his users.
2. He generates a public key pair, which will be the "address" of his subplebbit.
3. He configures captcha options, like how often and what kind of captchas to show.
4. 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 5

1. User opens the Plebbit app in a browser or desktop client, and sees an interface similar to Reddit.
2. 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.
3. The query returns the latest posts of each subplebbit, as well as their metadata such as title, description, moderator list and captcha server URL.
4. His client arranges the content received in an interface similar to Reddit.

Lifecycle of publishing a post on a subplebbit 4 6

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.

What is a "post"

Post content is not retrieved directly by querying a subplebbit's public key. What is retrieved is list of "content based addressing" fields. Example: latest post: "bGF0ZXN0...", metadata: "bWV0YWRhdGE...". The client will then perform a DHT query to retrieve the content. At least one peer should have the data: the subplebbit's owner client node. If a subplebbit is popular, many other peers will have it and the load will be distributed, like on Bittorrent.

Using anti-spam strategies other than the captcha service

The captcha service 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 his 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 service remains the most versatile strategy.

They had terrible names.

[removed]

[removed]

[removed]

[removed]