Yes, seems like there is some confusion on what exactly hybrid and clean slate means, the way I see it:
The end result in both cases is identical (only nimbus will be there, no status-go/status-protocol-go), it’s only about the process, i.e how to get there.
- Clean slate approach: No Nimbus - Go integration. Clojure/RN interacts directly with Nimbus. Thus at the level of status-react API.
- Hybrid approach: There is a Nimbus - Go integration. Go sits in-between Nimbus and Clojure/RN. Where exactly this integration happens is to decide. But it would probably start as low as e.g. Whisper API level and gradually increase.
This sounds exactly how I understood it, I am advocating for the hybrid approach, slowly chocking status-go, and eventually get rid of it completely, so when you say:
However, I think that the clean slate approach is not necessarily restricted to not having any intermediate solutions with both Nimbus & status-go / geth.
That sounds like the hybrid approach to me, so probably we are not far off in views, but maybe there are some fundamental differences in the way we see it.
Whether we do it vertically (one endpoint is fully using nimbus, while the rest will be using status-go), or horizontally (one endpoint calls status-go, which in turns uses nimbus), I guess depends on what we will be tackling and in which order, both seems reasonable approaches and we might mix and match.
The end-result in both approaches will be the same (no status-go, only nimbus), which I believe we are all in agreement and it’s the company strategy.
Would this be a good place to start?
Yes, plus https://github.com/status-im/status-react/blob/develop/src/status_im/native_module/core.cljs which are some endpoint that are only exported natively, on top of that there are the asynchronous signals https://github.com/status-im/status-react/blob/ebc2ff04cd9d27269729e3208b1fdeac46bd2cb3/src/status_im/signals/core.cljs#L47 which the app is reacting to.