fc-updates

Scaling Gossip with Bundles

Hubs are running into scaling issues with libp2p. We're proposing a change to "bundle" messages to fix some of these issues. 

This may add a ~1s delay to casts moving between clients.

Scaling Gossip with Bundles

Hubs are running into scaling issues with libp2p. We're proposing a change to "bundle" messages to fix some of these issues. 

This may add a ~1s delay to casts moving between clients.

https://warpcast.notion.site/Scaling-Gossip-in-Hubble-e66c766fa6b04afcb407f4800134cd72?pvs=25

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

Curious if there were any out of the box ideas on the table that got thrown out, but worth exploring longer term?

For instance, reading this, my mind immediately goes towards federation. i.e. Solve scaling longer term by clustering hubs (by channel?) and letting clusters communicate

I was going to say...the original model for farcaster looked more like what bluesky is doing with their concept of "personal data servers". The main problem is that getting all actors to agree on the same state becomes very difficult when you don't merkelize.

Software Engineer @ Cadence Design Systems. B4: Stanford EE / Illinois ECE

It can be frustrating when you reply to someone and you're never actually sure if the other person got the reply, but the tradeoff is more message passing. I think the main difference between farcaster and bluesky is that farcaster is choosing to have a public mempool.