# Unknowns

Topics to research and decide for the WakuV2 integration with the Status App

---

## Peer Discovery
@oskarth
> Rendezvous
> - we previously forked it to make it work with RLN/devp2p etc, the current version for libp2p should fit better
> - I've heard it said that this might not be a great solution in general, but haven't looked into it in detail. Kim might know better here. We can experiment with it I suppose but not sure it is important right now, probably more pressing things to do here.

> DNS is a good start (I think a lot of this work is done in go-libp2p already)
> it isn't something that we've actively looked into yet and it isn't implemented in nim-libp2p yet afaik. More likely to come with Disc v5, but there are issues here to investigate more (needle in haystack and from mobile). Feel free to comment in https://github.com/vacp2p/research/issues/75 above for thoughts here

@rramos
> go-libp2p provides different discovery mechanisms and @cammellos also implemented DNS discovery in https://github.com/status-im/go-waku/pull/48 . We need to determine which discovery mechanism are we going to use and plug the chosen mechanisms in status-go + go-waku. I see in libp2p kademliaDHT and mdns. DHT would require some bootstrap peers, and mdns does not make sense to use since it's for small networks.

**Research**
- https://github.com/vacp2p/research/issues/75

**Questions**
- Nimbus currently support DHT through a Discovery V5 protocol (in nim-eth). If we want to use the same, probably it makes sense to look at https://github.com/prysmaticlabs/prysm (eth2 go client). Any DHT will require bootstrap nodes.
- How can a nim-waku node be discovered? in go-waku we are using a custom rendezvous protocol. Should nim-waku support the same?
- Should status-go support DNS Discovery for bootstrapping nodes? if so, how do we determine which nodes should be used for historic messages. Currently we hardcode them into the node configuration. Should we instead use some custom peer selection algorithm after we identify a node supports store protocol?

## Peer selection
**Research**
- https://github.com/vacp2p/research/issues/89

**Questions**
- Store
- The mailserver cycle logic in Desktop was simplified for WakuV2. Currently it's set like this:
- Every 10 seconds we verify if we are connected to a specific peer
- If we are not connected, we ping all the store nodes and randomly chose one of nodes with lower response time
- We dial the chosen peer, and if the connection is succesful, we call `wakuext_setMailserver` passing the peer ID as parameter to indicate status-go that we are going to use this peer for all the mailserver operations
- Currently using a specific store node is not supported.
- Perhaps the cycle logic could be simplified even further by making the peer selection logic part of go-waku???

- Lightpush and Filter
- Currently selecting a peer is done by asking the peerstore to return the first peer that supports a protocol (similar to nim-waku). However a proper way to select a peer is needed.
- What's the strategy to determine which is the best peer to choose for a protocol?
- Should we use the ping time?

## Message Confirmations

Currently these are not implemented, so messages in desktop when using WakuV2 will always appear as not sent when the app is reset.

@oskarth:
> The current partial message ack that cluster is using is a bit of a hack. In gossip we can't really guarantee end to end delivery. This is why we introduced MVDS (which is only active for 1:1 and group chats). In general having acks like this is a bit of an anti-pattern/exploit vector due to amplification attacks.
>
> The problem with mobile is that your connectivity might be poor and your message might not reach the network. So lightpush is a compromise in that scenario, as a service node where they ack they receive a message and, behaving honestly, will relay it to the rest of the network.
>
> Assuming a node is well-functioning it should have many connections, and a message is likely to be propagated to the rest of the mesh.
>
> Whether desktop fits into the poor connectivity or the fuller node scenario might depend on specific environment and usage. It should be doable to watch mesh peer count and other health metrics to see if relay works or if it is required to outsource to other service nodes using lightpush.
>
> As for other health metrics, for go-libp2p I'd check what people tend to look for there, outside of just peer count, maybe things like disconnects, how long you had connections etc. @Hanno might have some ideas here too that are/could be in the peer/config spec

**Questions**
- How do we determine which service node to use for Lightpush
- Should mobile by default use Lightpush instead of Relay?
- Which health metrics to use in Desktop/Mobile to determine if we want to use Lightpush or not, and when should we mark a message as delivered.

## Technical
- MultiaddressPing used in the mailserver cycle does a ping to the TCP port of a multiaddress. Should it instead use the ping protocol? [ping](https://github.com/libp2p/go-libp2p/blob/0797df7cbc94e72a612eea0329be36e324d3061f/p2p/protocol/ping/ping.go#L86) returns a `time.Duration`, so for practical purposes it achieves the same result.