fix(bridge): include fluffy executable in docker image

[njgheorghita]

What was wrong?

In our bridge, we support using fluffy as the bridge client. This is done by passing an "executable path" via cli. This is possible when you run the bridge locally, but it's not possible when running a fluffy bridge via docker (eg. in kurtosis).

Also, our method for adding bootstrap enrs to the fluffy executable was broken.

How was it fixed?

• Included the fluffy executable inside the bridge docker image
• Fixed the bootstrap enrs cli arg formatting for fluffy

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

Our bridge requires clients to support trace_gossip to be used

Fluffy doesn't support trace gossip

[KolbyML]

So if fluffy can't be used, why include it in the dockerfile. I am not against making fluffy a usable option it just currently doesn't work.

[njgheorghita]

Ahhh, ok good to know. These were just the initial steps to getting the fluffy executable to run as a bridge client. I hadn't quite reached the part to validate that the client was successfully gossiping content yet.

Ummm..

1. We could update the bridge to support simple gossip endpoints instead of trace_gossip.
2. I've heard @kdeme mention they're working on their own bridge.

• Is it likely that fluffy will support a trace_gossip endpoint down the road?
• What's the status of your bridge? Would you be 👍 / 👎 on removing support for fluffy from this bridge implementation?

IIRC, we've decided for leaving fluffy support inside this bridge implementation in the past. Maybe this was before fluffy was making progress on their own bridge implementation? Obviously, this bridge's fluffy integration is broken / has been for some time. Now seems like a good time to revisit that decision.

[KolbyML]

Our bridge code for limiting the amount of current content being gossiped at a time wouldn't work with gossip, it only works with trace_gossip. And gossip doesn't provide enough information to make it work no? Of course you can make a bridge which only uses gossip, but making a bridge using gossip uses a different design with different guarantees no?

[KolbyML]

That is to say if we made the backfill bridge use gossip there would be no way to limit how many utp connections are happening at a time other then allocating arbitrarytime allocations you think it will be done in, but that would be fairly inaccurate prone to error and you are likely to have either too many or not enough open at a time. Where using trace_gossip we have guarantees of knowing when something is done or not.

As in gossip is non-blocking so it will return instantly. Which doesn't give you an indication if the uTP stream is done.

Trace_gossip is blocking and returns once the gossips are done, which then can be used to limit the amount of overall gossips at a time

In short trace_gossip gives the bridge more control over what is happening which is a good thing, when without it can be challenging to properly load the portal client with data to gossip

[njgheorghita]

Yeah, I think that's a good point. Imo, this depends on fluffy and what their plans are for their bridge / support of trace_gossip