Bitswap messages via GossipSub

Hi,

I wanted to share a random thought.

Why not send Bitswap messages via GossipSub? Why would Bitswap have it’s own messaging layer?

GossipSub already have a scoring system with a app specific parameter!

It feels like Bitswap is using Floodsub to spread it’s IWANTs then flood again with CANCELs not super efficient.

:man_shrugging:

1 Like

We want to move away completely from random flooding.
It just don’t scale. A single node can send up to 2Kreq/s you don’t really want to listen the hundrenths of thousands of nodes talking on the network.

Actually we will probably keep it but as a heavily metric oriented thing, so for example if 30 out of your last 50 requests were all done with 2 nodes, thoses are probably pinning services pinning the website you are using, so we can probably probe them with 1 or 2 WANT_HAVEs.

1 Like

Not exactly gossipsub, but one thing we do at actyx is to proactively broadcast data to the currently connected peers.

Basically we know due to how the application works that they will want some data soon, so we just proactively send it. That way if two nodes are reliably connected they don’t have to bitswap at all.

See Ipfs in ipfs_embed - Rust

But whether this makes sense or not heavily depends on the application.

1 Like

go-bitswap does the same thing, we want to stop this.
Most of the background CPU usage and network usage is shitty bitswaps requests people send you even tho there no almost no chance you host the blocks they want.

It does this always? That is a bad idea. Unsolicited spam.

In the case of Actyx, which is a distributed event sourcing system, we know for sure that the peers will need the data, since every node is replicating the event log of every other node. It is also happening in a small private swarm.