Announce Bitswap service multiaddrs to the Network Indexers

[jacobheun]

Currently only Graphsync records are announced to the network Indexers. When Bitswap is enabled we need to announce the multiaddrs of the service to the network as well.

Considerations
As Bitswap runs as a separate service we need a way to pass its multiaddrs to the index provider for announcing records.

[jacobheun]

With the current state of index announcements we need graphsync and bitswap records to all point back to the same node. We'll need to be able to route bitswap requests through the index announcement libp2p node (which is the Boost node today). It's currently not possible to point different protocol indexing records to different multiaddrs (even if the libp2p keypair was shared).

[ribasushi]

@jacobheun @willscott this is potentially a blocker, can we dig into the source of this limitation? My understanding is that elasticprovider does exactly this: they announce a peerid which is different from the announcer...

[willscott]

It's the addition and removal of identities that's expensive for the indexer. elastic provider has a single provider identity that all the cids map to.

the ask here was to take all the cids sp's have already announced, and now say "this new provider also announces all of that same content"

in the current indexer model, that's a whole new chain of a new provider, and as expensive as re-ingesting the whole chain. (each cid gets a new value entry put in to it's entry)

having those flap isn't something we'll really be able to tolerate right now, but we're working on it.

[LaurenSpiegel]

As an interim solution, there has been discussion of the SP's running a load balancer like https://github.com/mcamou/go-libp2p-kitsune. By using a load balancer we will be able to retrieve old and new CID's via bitswap even before work is done on ipni/storetheindex#678.

Putting diagrams from @willscott here for future reference --

Current state--

[LaurenSpiegel]

Since the indexer will be accepting different transport protocols in q4 (ipni/storetheindex#678), is there still a strict need for a load balancer?

[LaurenSpiegel]

Sounds like we can work on the load balancer as a separate effort.

[hannahhoward]

@willscott looking forward on this ticket for Q4 Bitswap + Evergreen, what work is needed from the indexer side? Is it tracked somewhere?

[willscott]

we can track under ipni/storetheindex#678

[jacobheun]

This is complete. #951 is a new version to update to index families, so tracking that separately.