[Deliverable] Nwaku in Status Desktop

[chair28980]

Project board: https://github.com/orgs/waku-org/projects/45/views/1

[fryorcraken]

Looking at waku-go-bindings I am worried as this does not match my understanding of the go-waku stack as previously explained by @chaitanyaprem and @richard-ramos

Let's clarify the definition of done.

The first goal post is to have a build of Status Desktop that:

• Works in relay mode
• uses nwaku instead of go-waku for "core" protocols (discovery and message routing)
• is feature equivalent to current go-waku based Status Desktop binary

By feature equivalent, I mean that "reliability for relay" functionalities are present in this Status Desktop build, which includes (non-exhaustive):

• store message confirmation feature
• periodic store query
• periodic ping of peer subset, used to detect disconnection
• automatic store query at reconnection
• automatic store query is done on a time range that start at last successful periodic store query

My understanding is that all the logic above was moved to the go-waku repo, in what we call the "go-waku API layer".
If go-waku repo is by passed when integrating nwaku in status-go, then we loose all those features.

This first goal post is important, because it would allow us to start dogfooding nwaku in Status Desktop, and proceed with e2e tests etc.
Then we can proceed with supporting "light mode" with the same set of requirements (reliability for req-res features still available).
With that, we can then make nwaku-based Status Desktop build the default one.

Making nwaku-based Status Desktop build the default buiild distributed to users needs buy-in from Status team, and we'll have to jump through some hoop, proceed with additional QA testing, modify CIs, etc.

Once done, we will be able to move reliability code from go-waku API (golang) to libwaku (nim) without much need from Status team, apart from the usual QA checks.

This is why this first goal post is an important one, that we want to run towards too.

Now, there are two strategies to get there:

1. Integrate nwaku golang bindings in go-waku, status-go uses go-waku, the reliability logic is not lost
2. Integrate nwaku golang bindings directly in status-go, copy reliability logic to libwaku

I thought that we agreed (1) was the agreed strategy, as per this post: https://forum.vac.dev/t/how-to-sunset-go-waku/308/6?u=fryorcraken

@richard-ramos @Ivansete-status @gabrielmer - can you please clarify the current strategy and that we are indeed working towards this first goal post?

[Ivansete-status]

@fryorcraken - waku-go-bindings is meant to tackle the following @richard-ramos 's point in https://forum.vac.dev/t/how-to-sunset-go-waku/308/6?u=fryorcraken

---

Now, there are two strategies to get there:

1. Integrate nwaku golang bindings in go-waku, status-go uses go-waku, the reliability logic is not lost
2. Integrate nwaku golang bindings directly in status-go, copy reliability logic to libwaku

I vote to follow 2. We will need to rewrite the go-waku reliability logic in libwaku.

The fundamental idea of waku-go-bindings is to create a separate module (or FFI package/wrapper around nwaku, as Richard mentioned in his post.) that can be easily imported and can be testeable.

---

can you please clarify the current strategy and that we are indeed working towards this first goal post?

Having the waku-go-bindings doesn't imply any change in the original discussions. Instead, it brings the possibility to have a module that can be integrated in a tests implemented by VAC/QA ( cc @fbarbu15 , @AYAHASSAN287 .)

[fryorcraken]

This was clarified as go-waku specifies an interface that is implemented by go-waku-bindings.
Status-go is where go-waku-bindings is passed to go-waku to fulfill the interface.
Meaning go-waku reliaiblity stack is stil used.

All good