vyzo

@lanzafame i didnt suggest that the application implements the interface, the library would provide the default implementation. I just want to avoid polluting the code with metrics invocations, which would...

asn no, the rest is reasonable proposition.

I think we should keep core separate, it's the interface after all.

Yes, but it allows libraries to just depend on core and not pull the whole go-libp2p except for trsts. On Sat, May 28, 2022, 20:17 Marten Seemann ***@***.***> wrote: >...

It is semantically different; i think a separate interface is good practice for something as complex as libp2p. After all, apart from instantiation and tests, user code only cares about...

think of it as the header file.

Any changes in interface should be carefully considered and too much velocity there is indicative of instability. We dont have to release before creating the implementation pr, and only release...

My main rationale for the interface being a separate repo is that libp2p is a very complex system, and that applications and libraries only ever care about the core interface...

I don't think 2 is the right option here; the application has to explicitly opt-in to 0-RTT, so it has to be prepared to handle early rejection as well. Let's...

this is rather complicated...