Add section on compatiblity and waku v1 v2 bridge #179
Conversation
| Publishing such packet will require the creation of a new `Message` with a | ||
| new `WakuMessage` as data field. The `data` and `topic` field from the Waku v1 | ||
| `Envelope` MUST be copied to the `payload` and `contentTopic` fields of the | ||
| `WakuMessage`. Other fields such as nonce, expiry and ttl will be dropped as |
There was a problem hiding this comment.
Separate from this PR, but I wonder if there's something we are missing as we drop these fields
There was a problem hiding this comment.
Well, nonce is only there for PoW, which isn't there anymore.
I'm not sure how message lifetime works in pubsub. I've tried to figure it out before, but I only noticed the use of a timed cache. No information of ttl within the message format itself afaik.
But even if there was, I doubt you could insert ttl values manually (API probably wouldn't allow that?), so you'd have to hack it in there. Probably not the best idea.
| Waku v2 network. More specifically, the bridge SHOULD publish | ||
| this through the Waku Relay (PubSub domain). | ||
|
|
||
| Publishing such packet will require the creation of a new `Message` with a |
There was a problem hiding this comment.
I suppose dealing with the contents of data field is out of scope of this PR and we can deal with it here #181 there's a question of Waku v2 receiving RLP envelopes here, but not much that can be done about it at this level I suppose.
Possibly some indication that it came from Waku v1 network? That way clients using Waku v2 can decide to drop support for RLPx in future when it doesn't feel like supporting that data content anymore. WDYT? Could be indicated in the contentTopic field perhaps, such as wakuv1/contenttopic (similar to eth2 namespaces). Or a separate field.
There was a problem hiding this comment.
The contents of data is indeed something to answer in #181.
But the idea is not to pass any RLP encoded data to the Waku v2 network. It is true that the Waku v1 Envelope type gets RLP encoded. But in the bridge it gets decoded and then the specific data and payload fields are used and placed in a new (protobuf encoded) WakuMessage.
Of course of there is any RLP encoded data within the data field, that is up to the application.
There was a problem hiding this comment.
Currently the data field is part of the protocol (though optional as you note): https://specs.vac.dev/specs/waku/envelope-data-format.html - I suppose it can be read in a custom fashion, but it isn't a straightforward protobuf. Though the payload within the data field is.
Anyway, for the other issue
Co-authored-by: Oskar Thorén <ot@oskarthoren.com>
Co-authored-by: Dean Eigenmann <7621705+decanus@users.noreply.github.com>
This should resolve #159
I will create a new issue for deciding on the optional encryption & signing of the payload.