[BOUNTY] Farcaster over Waku

Bounty summary

Farcaster is A protocol for building sufficiently decentralized social networks. Specs

It uses gossipsub for communications between hubs. A protocol is also defined to enable hub to catch-up when offline. Warpcaster is the most used client, available on mobile (iOS, Android) and Web. Warpcaster runs its own backend to enable access to light clients.

The reference implementation of the Farcaster Hub provides a browser package. This library implements client side of a gRPC protocol implemented by the Hub NodeJS package. When using the browser library, one has to provide the URL of a given hub (no p2p discovery).

Note: I haven't checked how discovery of hubs is handled.

Benefits

There can be a number of benefits for Farcaster to replace the gossipsub layer with Waku. It would be good to discuss with the Farcaster community to understand if they see value in any of these benefits. Such benefits are:

Frontend only/light client app/infra-less development

By using Waku and its suite of light client protocol, a FE only, browser, mobile app could access the farcaster network content without the need for the developer to build and host a BE near a hub (or ask user to run a hub on mobile/browser).

Scalability/Running hubs on household broadband

Farcaster uses two pubsub topics: one for contact info, and one for messages.

Proper calculation should be done of the traffic size on both topic. Yet, without calculation, it may be fair to assume that the traffic generated for messages, especially if direct messages are added could reach a point where it becomes unrealistic to run a hub on a typical household bandwidth, stopping user to run hubs at home.

By splitting the traffic for messages in separate Waku content topic (based on sender), then Farcaster could take of Waku auto-scaling feature (research wip) to keep the bandwidth consumption of a hub reasonable.

Capping bandwidth to enable users to run a hub at home would allow:

Users to run native applications that participate to the network (gossipsub).
Users to run hubs at home to support the network (Raspberry Pi, Dappnode, etc).

Privacy

Depending on how Waku is integrated, users could gain some privacy. Out of the box, it would remove the ability for the centralized dev app backend (ie, Warpcast backend) to aggregate metadata and PII such as IPs.

However, privacy does not seem to be a strong need, so will not expand on this.

Design Considerations

Sync Protocol

The Sync protocol may have to be reviewed to fit in Waku. The Waku lib API may need to provide access to the libp2p API to enable remaining the implementation of the Sync protocol, but this would mean that Farcaster hubs would need to connect to other Farcaster hubs. Instead, a Waku store sync protocol may be preferred to enable the sync functionality.

Waku SDK

The Hub software is written in TypeScript, targetting NodeJS. As developers currently use js-libp2p, they may prefer using js-waku instead of a wrapper to another Waku library. However, js-waku lacks server-side features. This may be an obstacle to adoption.

Content Topic usage

To fully benefit from auto-sharding, message and contact info should be split to several content topics. The assignment of topics to messages could be done in a similar manner to 54/WAKU2-X3DH-SESSIONS. Where messages are sent to a topic derived from the sender's public key. Same for contact info. When retrieving messages, the reader client can deduce the content topics to subscribe to based on who the user is following. This becomes less straightforward for trending topics, etc. More research would be needed. An early stage idea would for a client that is added the nth interaction to a message (E.g. 1000s like), would forward the message and related likes/comments to a "popular" topic. Content topic validation could be done on this topic to protect from spam

Spam protection

Further investigation in Farcaster is needed to understand what type of spam protection it uses and could be applied to the Waku network.

See https://github.com/farcasterxyz/protocol/blob/main/docs/OVERVIEW.md#4-authentication Users generate a signer keypair that is used by the application to sign all messages. The address key -> signer key mapping is stored in a smart contract.

This current design does not offer any privacy property to the user. One needs to dox a Ethereum address to participate to the network. A feature that seems to be mainly used for NFT PFP:

A connected Ethereum address is associated with your Farcaster account via an off-chain proof, allowing you to display NFTs on your profile. After connecting, it may take a few mintues for everything to appear. We currenly only support Ethereum NFTs. --- Warpcaster Web

Yet there are no visual difference between a PFP uploaded or selected from a NFT. I imagine future improvement such as visual identification of NFT PFP or ENS ownership is planned (haven't checked).

Replacing or supplementing this system with RLN would enable users to still prove ownership of an Ethereum address (and one could apply several criteria on such address) without doxing their address to the Farcaster network.

Again, it would be best to understand the interest of the Farcaster community to propose the best design.

Impact

Farcaster is an upcoming sufficiently decentralized social network. For using it a couple of days, I can see that there is activity and it is generally of good quality, with regular participation of names such as Vitalik or Balaji.

However, Farcaster does not seem to have much focus on privacy, something that is not line with Waku's principles.

Timeline

This is a long term project. A bounty hacker would need to propose a roadmap and refine it as they understand Farcaster design and propose deliverable.

Deliverables

The first step could be to mirror the Farcaster traffic on Waku and demonstrate some of the benefits listed above such as building a decentralized (no hardcoded farcaster hub/BE) FE/light client only.

Rewards

TBD

Evaluation criteria

TBD

Resources

TBD

waku-org / bounties