So, there has been a back and forth on how to move forward with Desktop. There has been experimentation among different cohorts in the organization, and a lot of back and forth on what the tech stack should be. This thread is an attempt to bring the conversation to a more public forum so that everyone can follow and stay up to date / opine if they wish. I’ll add two recent “summaries” to give a bit of context, and others can add more if they feel it doesn’t summarize things enough:
The Embark team has been getting familiar with the current tech stack and running different experiments, having identified Nim/Qt as a potentially simplified and impactful technology stack, demonstrating a proof of concept with some screens implemented, status-go integration and basic chat.
Andre has raised some great counterpoints around the risk of a new implementation, the risk of having bugs, split teams on different codebases, potentially long time to market.
At the same time we’re looking to productionise a desktop application sooner rather than later, so we need to choose wisely, however we don’t appear to have clarity on which approach is best.
I reached out to Volodymyr, as last year he was for a C++/Qt implementation yet he is the goto man for react-native-desktop, he made the good point that we did have a working desktop in the past, albeit with a simpler interface and Volodymyr himself wasn’t convinced which direction would be best. So it sounds to me we don’t have enough information to make the call.
Volodymyr suggested that perhaps Volodymyr and Vitaliy push status-react and react-native-desktop as much as they can within a fixed period of time (1 month?), to see how far they can get.
I think this is a really good idea.
Another consideration, we want to replace status-go with a clean interface, and integrate Nimbus in the application. This should be sdk lib that other developers might want to use.
So another idea might be that, while Volodymyr and Vitaliy are working on the status-react desktop stack, we can have people working on this status-go replacement, and they can have Nimbus folk overseeing their code quality as they learn Nim.
That way in the future we will have a clear picture of what direction to go, and we’ll have significant progress on integrating Nimbus into the app (mobile and desktop).
Let’s think about this, if there’s any other ideas on how to proceed please share, then let’s come to an agreement on the best path forward, I would be happy to join a call next week, (keep in mind Andre has well-deserved time off and we should respect not to disturb him) - we should aim to be on the same page by end of next week, how does that sound?
enjoy your weekend !
and @vitaliy said:
I am not at all entitled to hard opinions, some thoughts that could be very wrong:
react-native-desktop path: benefits of code reuse, but difficult to integrate and to maintain w.r.t. mobile code. Definitely worth to try nevertheless. Would be a pity to waste so much effort.
On the other hand, the stack is extremely complex and prone to breakage at various places. I don’t know how we can tackle this. It’s inherent to ReactNative i think. There is a major update coming soon (JSI/Fabric etc.), so this should help make things more performant (but more complex again maybe?)
Nim/Qt: it’s great to have a client from scratch, helps to throw light at various parts of the whole client<->status-go interaction. And will help in improving the Nimbus client interface.
Wondered about Nim vs C++ choice specifically, apart from it being a powerful lang in its own right. Meaning, how sure can we be it’s not going to cause unexpected issues along the way? E.g., i was looking through Status’s Nim repo to get a feeling of how it’s used, and quickly came across https://github.com/status-im/nim-faststreams/commit/6ce0472ec0d857bb5a3615574580f631f29a4931. Also nim-qml library might need to be updated/fixed, but the stronger version of the same argument applies to react-native-desktop-qt anyways.
We have made a stance that Nimbus will eventually be the backend of Status. We fund a relatively large team to work on all of the things, and have a large budget to do security auditing on it, for a reason.
Whatever option is the one that makes it easy to incorporate Nimbus work into our future application development cycle is the correct one forward. This is my personal top priority. There are tradeoffs of course, and potentially wasted work from what we have, but the end goal is to have something that unifies the work being done now, and what we have made clear we will be working on in the future.
I think it is reasonable to do what @jarradhope mentions and see what is what at the end of that. I do not want to waste too much time discussing and arguing while not working forward. We as an org have a tremendous amount of hard work ahead to do what we’ve all set out to do. If there exists dissent and argument at the end as to which to do, fuck it, do both.
That being said, I really do appreciate the input from all the domain experts of Status. This org is one that has many opinions, all of which are valuable to me. So I’m at a cross roads of how much do we talk vs how much do we do?