@roman, not only. Things like adding a new 3rdparty module to mobile that wasn’t included in desktop build. Or updating only ios/android part of
react-native-status when interface changed. But of course that can be fixed by proper automated testing.
@roman, not only. Things like adding a new 3rdparty module to mobile that wasn’t included in desktop build. Or updating only ios/android part of
just want to share my vision of the desktop application,
first, it’s never been a priority and clojure core developers have never worked on it full time. What we’ve been trying to do is to run status-react code on desktop, this approach has several drawbacks. We add conditions and complexity to mobile code. On mobile we have lots of functionality and libraries we don’t need on desktop (camera, gestures, biometric etc ). Instead we could create a separate code base for desktop and reuse as much code (business logic and UI components) as possible from status-react. With re-frame framework it should much easier to do. Next
react-native-desktop-qt , it is not yet production-ready for sure and needs lots of effort to maintain it, also react native is changing every day, and even in status mobile version updates is not smooth and easy. Last time i was able to run desktop app based on
react-native-desktop-qt it was laggy and has different issues with rendering and had memory leaks, so we can say for sure 1 developer is not enough for such project, we can just look at react-native-windows repo
, and here I agree with @Ferossgp, Microsoft actively working on this repo and even added macOS support, so its worth a try at least, status-react has also changed, app storage was moved from realm.js to status-go, shadow-cljs instead figwheel, we’ve spent a lot of effort to support this in desktop. So my suggestion would be
- run a new clojure project on windows and mac using
- integrate status-go and implement simple sign in flow using UI components and code from status-react repo
- implement chat using UI components and code from status-react repo
i would say if 1 and 2 went smooth, we can have a fully functional chat in 1w by 1 dev, I’ve already done that trick twice
In status-react repo we have 200 contributors and more than 5500 commits, we had lots of contributions from bounty contributors, and our codebase still clean and good, and application is production-ready and has zero bugs or crashes in runtime (i believe its because of clojure and re-frame), developing status react we have hot reload with the persistent state, repl, lisp (clojure), re-frame, and removing any part is a step back
There are good arguments for both approaches here. If there was ever a time to simply try both approaches, this is it. In the end, the users will decide which approach works better and the two teams will be able to learn from each other and keep each other accountable in terms of delivering the best user experience. This iterative approach may work much better than the big bang approach where we plan it all out and commit to one well defined path as there are many unknowns along any given path.
I end here with a summary of a quote about IBM in the early 1980’s and how they choose to try pursuing the PC even though they already proved with near scientific rigor that the mainframe will be the way forward. Then in launching their own PC, they had two separate teams work on it. In the end it worked out as their approach to PCs became the standard for years to come.
The future, IBM knew, and could prove with scientific rigor, lay with the central station, the ever-more-powerful mainframe into which a huge number of users could plug. Everything—economics, the logic of information, technology—led to that conclusion. But then, suddenly, when it seemed as if such a central-station, mainframe-based information system was actually coming into existence, two young men came up with the first personal computer. Every computer maker knew that the PC was absurd. It did not have the memory, the database, the speed, or the computing ability necessary to succeed. Indeed, every computer maker knew that the PC had to fail—the conclusion reached by Xerox only a few years earlier, when its research team had actually built the first PC. But when that misbegotten monstrosity—first the Apple, then the Macintosh—came on the market, people not only loved it, they bought it.
Every big, successful company throughout history, when confronted with such a surprise, has refused to accept it… IBM, the overlord of mainframes with as much in sales as all the other computer makers put together and with record profits, could have reacted in the same way. In fact, it should have. Instead, IBM immediately accepted the PC as the new reality. Almost overnight, it brushed aside all its proven and time-tested policies, rules, and regulations and set up not one but two competing teams to design an even simpler PC. A couple of years later, IBM had become the world’s largest PC manufacturer and the industry standard setter.
A few random thoughts on this subject:
- how much manpower is needed to maintain react-native-qt once it works?
- is it satisfactory to ditch linux and only support mac/win?
- are we willing to adopt nim-qt? this wrapper will likely end up needing contributions from us - trivial and mechanical unlike native-qt, but there nonetheless.
- what would extensions/plugins look like, across mobile and desktop, if different frameworks were used? most of the web world already makes the distinction between desktop and mobile versions of sites, so this may not be a such a big problem, but…
- Qt has android/ios support as well, what would it look like / what would the implications be of a qt version on mobile?
There are a few things that have changed that make this less of a dramatic choice than it used to be:
- The protocol is described in a spec, separately - it no longer resides in the UI
- Much of the actual logic is now in
status-go- this trend would / should continue, with the UI becoming thinner and thinner, in terms of functionality and logic - ie the UI should focus on being pretty and productive while the logic lives elsewhere
- Much of the difficult design work of crafting a good user experience is independent of the actual framework used - ie with sketches, user flows, screens etc done, maintaining parity becomes much less of a deal.
I would tend to agree. It might be worth making a post mortem on how this decision came to be and how we can avoid it in the future. “It” being the lack of transparency, surprise aspect, potential double effort, etc. Considering we’ll be working together for a while, and keep making decisions of this kind, getting this out of the way in a fashion where everyone feels heard seems like it’d be worth the effort.
@andre @iurimatias @hester what do you think? I don’t have a lot of the facts of how this came to be, so it’d be best if people familiar with the matter kick start it, and then we could bring in other people to fill it in. Shouldn’t take too much effort, and we can use Core dev calls for this too.
I’ll spin off a separate thread on decision making here, we can then also discuss on Core dev call if that makes sense. Please bear with me.
My initial thoughts on this are: This was not a flawed process, we simply don’t have a process, nor clarity on who makes decisions and how they are made. I think we can also improve our decision making skills (identifying decision, gathering information, propose resolutions, etc.). Until we reach the point of having structured community input, pitches and voting in place we need clarity and process.
Takeaways from #standups on Discord:
a We need to create clarity around who decides
b Whoever decides needs to collect input publicly (b can’t happen without a)
c Decision and motivation need to be communicated publicly
b might not be feasible or convenient, but should be the exception, not the rule.
c should justify why
b has not been followed in such cases
This was not a flawed process, we simply don’t have a process, nor clarity on who makes decisions and how they are made.
I think that’s a bit of sugar coating, we might not have a process true, but there’s an explicit hierarchy in the company, and some people were involved or were in the known, which to me counts as a process . if there’s not one that is spelled out explicitly.
At any point anyone could have stepped in, but no one did, and the lack of responses in this thread is louder than anything.
Kudos to @oskarth to jump in, I would have expected someone (anyone in the known) to do similar as soon as the issue crop up, instead of having a single sided conversation between us.
I can’t tell if you’re referencing me, I’ll respond as if you are. The answer is simply because there’s no decision to be made yet, I am exercising patience and if it’s not obvious by now I’ll state it clearly - I don’t value enforcing my will over the people having to work with their codebases - and I prefer decision-making to be bottom up. The times I’ve exerted my position is when I’ve absolutely had to, and if you haven’t noticed, I’ve even backed off on technical decisions and implementation because these days I can delegate to the absolutely talented and wonderful team that we are. There’s absolutely no need for any management layer to enforce a violent decision here.
Why is there no decision to be made yet? The situation as it stands to me is that Embark team and Vitality and Volodymyr were given a month to push their respective implementations as far as they could, why? So we would then have tangible material artifacts of 2 desktop implementations, which will allow us to make a more informed decision collectively.
The month to push of each implementation will be up next week, and I expect to see 2 workable demo desktop implementations.
From there, I am looking forward to us resuming the discussion about the implementations as an organisation. What are the pros and cons of each direction. Maybe one of them will be a clear winner.
Now, here is the reality check, the Embark team isn’t likely to switch to Clojure. It’s a foreign language to them and it’s a large codebase for a team that hasn’t grown up with it. So the rn-desktop implementation has to be damn good and there need to be large support from the core team to win over Embark team.
If core cannot make a compelling case, then the core team will be put into a position to decide whether they want to continue allocate 2 resources to continue maintaining rn-desktop.
If we end up doing 2 implementations, ultimately the market will decide which client is best.
Either way, I am indifferent, both implementations have great arguments for them, which is why we’re doing it this way. I think giving both sides a month to prove their efforts is the most fair approach to all involved, it respects the efforts of all, gives everyone else time to cool down, weigh the pros and cons, and bring clarity to collective decision making. Surely you would agree?
If a decision is demanded of me after end of next week, be assured I will give it.
I am getting a feeling that this conversation is beginning to have several focal points.
Just to reiterate:
- I was most appalled by abrupt switch to nim-qt, without any involvement in a related decision-making process, with a secret repo, with myself unknowingly working on making sure that status-react works for Embark folks.
In hindsight, i think i was not properly aware of the fact that this is up to Embark team to decide. But i would have liked to know the rules of the game in advance. My reaction overall was quite emotional, apologies if it wasn’t appropriate.
- I was happy to find out that Volodymyr’s suggestion to have a 1-month effort was supported by Jarrad, so that we can push it as far as we can. But this wasn’t the original plan i think. I think originally the intention was to make a decision together, then follow it. Not to follow 2 competing paths.
- My understanding of your words @cammellos (“the lack of responses in this thread is louder than anything”) is that there are no responses from Embark team themselves here. Probably i’m wrong, but this is also a part of an issue i think.
- To be super-honest, I do think that nim-qt is really interesting and cool, and Embark folks are making really cool progress, and it’s nice to have an alternative client, this will help clarify API for sure. It’s just that on a human/emotional level, I don’t like how it originally came to be. We need no sugar coating, what happened is what happened, there was in my opinion some unhealthy attitude involved. I for one got over it already.
Thanks @vitaliy that captures my thoughts accurately, as I mentioned earlier, it’s not about technology but people.
I shied away from pointing out who’s role is to respond to this as I don’t think is appropriate for me to say explicitly, only to nudge.
So when I said "At any point anyone could have stepped in, I specifically wanted to keep it vague, as my knowledge of things is very partial, and it’s all a black box from an outsider perspective.
My 5 cents:
I don’t want to “win”, “lose” or “compete” against anyone in the same company So how I see things - me and Vitaliy are doing timeboxed research to check rn-desktop potential. Outcome of this research can be used for a decision re-evaluation if needed.
Sorry I haven’t replied earlier, I wanted to give things a chance to settle down a bit.
First for some context, when the Embark team took on desktop, we had the choice to choose our stack which didn’t necessarily had to be status-react, however due to lack of any real alternatives status-react became the default path while we explored other possible alternatives.
So we did several experiments (which included electron, node-ffi, nodegui, clojure+javafx, and even forking firefox), the goal which was in part for learning purposes as it helped us better understand status-react & status-go itself, and in part to explore other stacks, until the last moment we were still going with status-react as the default route (and thus still inquiring about the progress of rn-desktop-qt) before realizing the nim+qt stack was a solid choice for desktop and helping out with nimbus integration.
Now, the part that is important to understand is that on Embark we were used to do things a bit differently and I was not fully aware about the culture in Core and lot of this misunderstanding seems to be caused by that.
For example due to competitive reasons we were used to do things in private repos until they were minimally ready, this was particular true for experiments like it was the case here or something that needed to be proposed.
And myself in every organization I ever worked in, even the most flat ones, typically communication always flows in a similar manner. i.e the lead communicates with the team, his/her peers or relevant people (for e.g @petty for security), as well as their own manager. Then it flows from there to the other teams. So on this aspect, from my perspective, everything was ok as I was communicating this way.
However in practice 1) as I learned this is not how we’re suppose do things, I understand that now 2) I didn’t communicate well enough to everyone it seems, and information wasn’t flowing as I thought 3) I made the mistake of assuming that communicating this in the PM meetings was enough.
Sharing rn-desktop investigation resuls:
Fixes we had to do to develop branch:
- browser and wallet disabled
react-native-safe-area-contextpackage was patched to return View instead of native RNCSafeAreaView that doesn’t exist for desktop. That allowed us to use navigation.
- fixed few functions in
- Packages blocked using shadow-cljs.edn:
quo/animatednamespace functionality was fully mocked because it relates on
react-native-redash(both not supported for desktop)
- qrcode commented everywhere because relates on
react-native-svgwhich is not implemented for desktop.
- setInternetCredentials commented out for keychain - this means that Save password is disabled for now
The biggest obvious problem is a performance, especially on lists. Scrolling quite small list leads to significant cpu and memory consumption. Can’t say if that will be easy to deal.
Our opinion: it is possible to use
react-native-desktop-qt for Status Desktop but performance problems should be addressed. Also we tend to think that desktop repo should be separate from mobile. It should reuse logic and could reuse some components but attempts to reuse full UI will slow down everyone. For desktop it would be easier to create own UI taking into account
react-native-desktop-qt restrictions rather than chase mobile UI.
Nim Status Client:
-> Note: currently needs to chmod a+x
-> Note: first run, need to right click -> open (due to new apple requirements for notarization); if in the applications folder, then you need to manually open the folder, right click -> open
- Ensure there is no existing status app running (like status-rn-desktop, ios simulator running status mobile, etc…)
- Ensure firewall is allowing the status app
- There is a ~2 second lag moment after login, we’re currently working on optimizing this. (It’s due to wallet requests we need to optimize)
- Browser not working on linux yet. (On mac it’s experimental)
- In 4k / high resolution screens the fonts might be blurry (something we’re currently working, seems to be a QT config)
- Stickers will display, sticker selection is WIP
-> Note: the video is completely unedited, => sometimes there are long pauses which is me grabbing my phone or looking in etherscan for some random ethereum address for the wallet <=
i like this quick nim development progress, looks like it only takes one and half month atm.it’s faster than ever lol
your shared mac bundle need authority to access, WDYT, it should be public.
Great job team!
The nym client is pretty cool! Congrats! Could the same stack be easily ported on mobile?
It’s possible, from my tests Qt on Android is kind of slow. I am still waiting on a PinePhone to see how it would fair on mobile linux if it does then freedom respecting hardware, operating system and app would be a great combination.
I have to say that this has been impressive progress. The desktop team have been absolute executing machines. This demo has made me really excited about the future.
Thank-you very much all involved.
or, as they say down under, BLOODY BONZA MATE!
An attempt to recap and wrap up a month of investigation and prior discussions with soft conclusions. So we can close this topic with consensus and keep building awesome stuff. Please share whether you think these are valid conclusions.
- Two experiments were run
- They differed in technology stack, using
nim-qt, to develop a Desktop client, allocated resources and design support
- Other stacks were used during an earlier experimentation phase, e.g. electron see reply by Iuri, but dismissed and not actively worked in over the last 30 days
- The Desktop implementation using react-native-desktop-qt focused on chat and porting the react-native UI currently in production on mobile; The implementation using Nim-Qt focused on the chat and wallet features mimicking Status mobile logic based on specs
- Both teams delivered a demo bundle in 1 month time (see above)
- Understanding of ease/complexity to rebuild logic in nim-qt
- Understanding of ease/complexity to port react native to desktop
- There’s work to do to improve cross-team communication and decision making
I think Stimbus discourse went better. Communication around implementation decisions for iOS notifications are also a prime example. There’s no golden ticket here. Transparent communication and decision making requires continuous effort, to push and pull information from everyone involved. Kudos to @oskarth and @cammellos for being strong advocates of this.
- Desktop team will continue to develop a Desktop client using nim-qt, as it has emerged as a solid choice and helps with Nimbus integration that the team will also lead in the coming months.
- As discussed here Sequel Core dev call #32 - YouTube, summary on Discuss to follow shortly.
- Next steps for rn-native-desktop are to be decided by the Core Mobile team. There are two decisions that need to be made:
- Should work on Status Desktop, built with the help of react-native-desktop-qt, be continued?
No, nim-qt is showing good results and has a team working on it. At the same time, Core Mobile team needs to focus on acquisition and user facing features and can use all it’s core contributors for this
- Should react-native-desktop-qt technology development be supported?
No, not if it’s not used in Status
Thanks to @volodymyr.kozieiev for fact checking how I describe the different technology investigations and formulating decisions that need to be made at this point.