Nathaniel Cook

I am still able to reproduce the error on master. [Here](https://github.com/nathanielc/rust-libp2p/tree/repro/debug_assert_master) is a branch with a reproducer against master. To repro run from within the `examples/file-sharing` directory: ``` RUST_LOG=info,libp2p_swarm=debug cargo...

I took a stab at a fix here https://github.com/libp2p/rust-libp2p/pull/4777 open to other ideas for how to fix this.

> This is a breaking change so'll have to hold off on it for a while. I hope that is okay. Yep all good,no rush on this feature from us.

> > I am still of the same opinion that I think we should design `RecordStore` to: > > > > * Implement `Clone` > > * Return `Future`s that...

They are used for the republish logic. The current implementation calls `provided` and collects all records into a Vec and starts to publish them in small batches. In our use...

For our use case we are using provider records exclusively and so the key is the significant portion of the data. We expect 10M+ keys for a single peer. That's...

Thanks for the context, re IO in behaviors vs handlers that's really helpful to understand. Currently we use a custom implementation to publish the records. Instead of once every publish...

As an aside once you get enough records it can become more efficient to invert the republish logic. The current implementation iterates through each record and contacts the closest peers...

> How does the PublishJob learn about the records that need to be re-published? Would it internally connect to the same record store, e.g. by accessing a shared hashmap or...

Another question re the two behaviours design. My understanding is that to pass messages between behaviours that happens outside the swarm. Meaning what ever type contains the swarm is responsible...