Hanno Cornelius

> Note: this issue has been recreated from a similar issue in a private repo (it's not possible to transfer issues from a private to a public repo, hence the...

Comment from @oskarth previously: > Nicely scoped issue. Few points: > > 1) Should this issue be in a private repo like pm? If it isn't sensitive, I suggest we...

Good suggestions, thanks!

Indeed. There should be no more use of named sharding in any clients.

Yes, we can close. In future, I think it could worthwhile specifying the implied trust and reliability assumptions in Store protocol. Even if we do not implement any strategies, rigorous...

>Regarding circuit relay. Indeed. Circuit relay is already used quite extensively by go-waku and nwaku supports the relay process as server. I think following the process as described [here](https://docs.libp2p.io/concepts/nat/circuit-relay/#process) would...

For Filter, the following enum is a good starting point: https://github.com/waku-org/nwaku/blob/91c85738a0e45f9bf88d11bc1b36308755a5b5d0/waku/waku_filter_v2/common.nim#L13-L19 (The idea is that when the protocol moves to `stable`, the error codes will be specified. For now the...

Indeed. For each of the "new" req-resp protocol the pattern should be the same - an error enum in a `common.nim`. This has been implemented for store v3: https://github.com/waku-org/nwaku/blob/22f64bbd447985e375b9cb7e0302448fcd7f6636/waku/waku_store/common.nim#L61-L67 Lightpush...