oskarth

I feel like we are jumping the gun here a bit. First, let's get 2-4 specs to a desirable state, _then_ we can see about how to best indicate this....

Also see https://github.com/status-im/nim-libp2p/issues/727

Thanks for the initial issue! I'm not going to comment on specific approach suggested here (though Hanno might have stronger opinions here). What I'll do instead is to give some...

Re Waku Message: https://github.com/vacp2p/rfc/issues/373 not sure how we want to deal with this uncertainty here

> do we want to move to a different struct such as format: 'raw'|'status-enc'|'eth-sign' etc What would you specifically suggest here that would be a minimal diff? In terms of...

Answering my own question, we could follow something like https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#keys Looking at https://github.com/status-im/js-waku/issues/179#issuecomment-869117193 I think we need to clean up the encryption spec story, it is a bit diffuse right...

Thanks for the update @staheri14! Question on timestamp: I see the rationale for float64, though it does strike me as a bit odd for some reason (maybe due to precision?)....

Brief update: general Waku v2 main spec improvements https://github.com/vacp2p/rfc/pull/444

Let's add this to Vac PM and discuss next call

It'd be good to look at and briefly document existing ways of solving the same problem. For example: https://rfc.zeromq.org/, libp2p, EIPs, IETF, etc.