Thomas Eizinger

> I am only aware of [https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md](https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md?rgh-link-date=2022-08-10T03%3A02%3A01Z) and #2780. > > I am in favor of adding additional information for newcomers. The only thing I would like to watch out...

Well, ultimately, we obviously can't force (pun intended) users to not force push but I see it as a "these are our conventions, please follow them if you can". Because...

I had an idea that could perhaps solve this issue. I am calling it `libp2p-bare-stream`. Here is the **tl;dr**: 1. `BareStreamBehaviour` is constructed with an arbitrary protocol name (i.e. user-configured)...

> Oh, one more thing: it would be really great if the `BareStreamBehaviour` accepted a list of protocol names to allow the underlying negotiation facilities to be used for higher-level...

> - In case the local node is not connected, would `BareStreamBehaviour` drive the connection establishment? Should this be configurable per stream? I am tempted to say no. The method...

> > So perhaps the best we can do is to keep the knowledge of queue sizes available in the behaviour so that we can return an immediate result: >...

We could implement the Behaviour to simply wait internally for a "slot" to establish a new substream. i.e. return an ID immediately but the event with the substream would only...

> > Not _this_ sounds like a really cool improvement over TCP sockets to me! > > The more I think about it, the more I like the framing. TCP...

> to throw a use case out there, I wanted to implement a simple p2p proxy, but couldn't find an obvious way to do it using libp2p. Note that this...

You already have streams as of today, you just need to implement your own `ConnectionHandler` and `NetworkBehaviour`. I've somewhat changed my mind on [this idea](https://github.com/libp2p/rust-libp2p/issues/2657#issuecomment-1141243489) since I wrote it. The...