# 15/WAKU-BRIDGE | Vac Research
- Status: draft

Skip to main content

# 15/WAKU-BRIDGE

- Status: draft
- Editor: Hanno Cornelius <hanno@status.im>

## Abstract​

This specification describes how 6/WAKU1 traffic can be used with 10/WAKU2 networks.

## Wire Format​

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in 2119.

A bridge requires supporting both Waku versions:

- 6/WAKU1 - using devp2p RLPx protocol
- 10/WAKU2 - using libp2p protocols

## Publishing Packets​

Packets received on 6/WAKU1 networks SHOULD be published just once on 10/WAKU2 networks. More specifically, the bridge SHOULD publish this through 11/WAKU2-RELAY (PubSub domain).

When publishing such packet, the creation of a new `Message` with a new `WakuMessage` as data field is REQUIRED. The `data` and `topic` field, from the 6/WAKU1 `Envelope`, MUST be copied to the `payload` and `content_topic` fields of the `WakuMessage`. See 14/WAKU2-MESSAGE for message format details. Other fields such as `nonce`, `expiry` and `ttl` will be dropped as they become obsolete in 10/WAKU2.

Before this is done, the usual envelope verification still applies:

- Expiry & future time verification
- PoW verification
- Size verification

Bridging SHOULD occur through the 11/WAKU2-RELAY, but it MAY also be done on other 10/WAKU2 protocols (e.g. 12/WAKU2-FILTER). The latter is however not advised as it will increase the complexity of the bridge and because of the Security Considerations explained further below.

Packets received on 10/WAKU2 networks, SHOULD be posted just once on 6/WAKU1 networks. The 14/WAKU2-MESSAGE contains only the `payload` and `contentTopic` fields. The bridge MUST create a new 6/WAKU1 `Envelope` and copy over the `payload` and `contentFilter` fields to the `data` and `topic` fields. Next, before posting on the network, the bridge MUST set a new `expiry`, `ttl` and do the PoW `nonce` calculation.

### Security Considerations​

As mentioned above, a bridge will be posting new 6/WAKU1 envelopes, which requires doing the PoW `nonce` calculation.

This could be a DoS attack vector, as the PoW calculation will make it more expensive to post the message compared to the original publishing on 10/WAKU2 networks. Low PoW setting will lower this problem, but it is likely that it is still more expensive.

For this reason, it is RECOMMENDED to run bridges independently of other nodes, so that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2 traffic.

Bridging functionality SHOULD also be carefully implemented so that messages do not bounce back and forth between the 10/WAKU2 and 6/WAKU1 networks. The bridge SHOULD properly track messages with a seen filter, so that no amplification occurs.

## Copyright​

Copyright and related rights waived via CC0.

## References​

- 6/WAKU1
- 10/WAKU2
- 11/WAKU2-RELAY
- 14/WAKU2-MESSAGE
- 12/WAKU2-FILTER