Manyverse Desktop Dev Diary

I think it'll be good to share little by little how Manyverse Desktop is shaping up, since it'll be a long journey.

@Powersource (phone) and I agreed to share the responsibility of building it, for a couple of reasons: (1) the workload is large and both me and him have limited time budget, so it makes sense to merge our time budgets, (2) Jacob can work on this earliest in July and we need to speed up mv-desktop development in May and June somehow, (3) some obstacles are Cycle.js-specific and since I created that framework, I should tackles those obstacles, (4) people need hope for an actively-maintained desktop app.

mv-desktop challenges eerily remind me of my first dev diary in 2017, where I was trying to cram scuttlebot into React Native, except this time the challenge is in the opposite direction, where I try to cram React Native stuff into conventional web and Electron development. In 2017, the challenge was mostly with the backend, i.e. running the ssb-server (database and networking parts) on mobile. This time, the challenge is mostly with the frontend, adapting React Native and Cycle.js to an Electron environment. The basic hurdles are solved by using react-native-web, but the devil is in the details, and there are lots of details (see mv-desktop roadmap).

That said, I'll leave most of the nitty-gritty details to GitLab issue discussions. In this thread I'll share the fun stuff: the achievements, the frankenstein gradually coming alive, some diagrams, etc.

Here's the big-plan diagram:

The right side of that tech stack is what we're trying to build. I started by handling the lowest layer, with electron-ssb-client, and then Jacob handled all of the other low-level right-side stack (react-native-web etc), and now the biggest missing piece is "Cycle Native Navigation Web", which will handle "page navigation". There are specific challenges related to that which I'll try to share in another update.

So far what we got working is: the backend is fully functional and correctly communicates with the frontend, and all the Electron/webpack/react-native-web machinery is working. Jacob once demoed the Thread screen working.

This time, I got the Welcome screen fully functional. Sounds easy, but there were lots of CSS and React to struggle with until everything looked pretty. Below is a demo:

The next big task will be switching to other pages. I.e. Cycle Native Navigation Web will need to be built.

fantastic work!

Before working on page navigation in Electron, I wanted to have a clear picture of the current state of screen navigation in Manyverse. So I dabbled with a script to inspect the source code for all screen transitions, made a graphml file, loaded it into yEd and tweaked it a bit to produce this:

(open in browser and zoom in to read it properly)

Hey @andrestaltz, One of my colleagues is going completely insane over some new kind of front-end framework called "Tauri" which runs on Rust. it seems that Tauri is much less resource hungry than Electron is and the base application size sits at around 500kb if you build a fairly clean hello world instance (in stark contrast with Electron which will eat about half a hundred of megs).

Website with info:
https://tauri.studio/en/

We actually talk about this in one of our podcasts
https://patraden.knightec.se/podcast/2021/04/25/apropa-git.html (that's in Swedish though)

Jacob and I got back to collaborating on mv desktop and it's been steady progress. This time we focused on getting the Compose screen working, and it works surprisingly well, not a lot of bugs in the basic use case of writing, previewing, and publishing.

One of the bigger challenges was setting up a system for dialogs and popups. Basically iOS and Android come with their own dialogs (and design guidelines for that), but when it comes to Electron (and the web), there isn't. I mean, there is window.alert and window.confirm but those are hideous. Most websites with pretty-looking dialogs have to role out their own solution.

The tricky thing with dialogs is that the cover the whole screen, and in the Cycle.js architecture in Manyverse, we took an ad-hoc solution where we're just providing dialogs as a driver, basically "shimming" the operating system's lack of dialogs (and/or their use in Electron). This is the smallest departure we can do from the existing app architecture. The other option was a complete overhaul of how dialogs work in the app, and that seemed like too much refactoring.

So I set up a funky "shim" of dialogs in Electron as a React app that runs in parallel to the Cycle-React app controlling all the screens in Manyverse. And @Powersource (phone) did the job of finding and integrating a sweet Material design component library that matches almost perfectly the dialogs in Android, and we got to this point (the dialog that appears when you press "..." on a message):

great work @andrestaltz and @Powersource (phone) :D

It is impressive how much we need to reinvent when using Electron. This is not me dissing it, I like it to some extent. It is just that in case of operating systems such as macOS, there is so much available for native developers that can't be easily tapped by Electron-based apps. :-(

makes me appreciate even more all the work you folks been putting into Manyverse Desktop. :D

@SoapDog (Macbook Air) Yeah I noticed that Manyverse M1 uses macOS's own pretty-looking dialogs. It would be awesome if Electron gave us a way of using those. I really wish I knew how to do that.

@andrestaltz does the Electron native dialog API helps? Don't know if you have tried that before.

Jacob finished porting all the dialogs in the app, and here's a sweet example. The following dialog component comes from Material-UI. And when you press "Yes", it actually logs you in and opens the room's site in the browser.

Today was productive, I did a bunch of small improvements:

• Updated Electron to 15.x
• Enabled the Backup (24 words) screen
• Enabled some settings screens: About, Libraries, Thanks
• Custom (for MV Desktop) progress bar for indexing status
• Enabled the Edit Profile screen (although changing profile pic is missing)
• Enabled Manage Aliases screen

@Tod Robbins (he/him) not yet, but soon! Special testing help will be needed from Windows and macOS users since my main computer is Linux and I won't be testing super often on Windows and mac.

@moid Smells to me like you're using some very bleeding edge version of Node.js. Can you check that node -v says 12 or 14?

v10 should work but try v12 just in case. It could be that the latest Electron is not compatible with an old Node.js version

• Supports attaching pictures to posts and changing profile pic
• Supports toasts to notify you e.g. when an invite code works

@moid Good questions and good that you're already alpha testing this to give some feedback. I could still change it back if that ends up making sense.

Overall what we're aiming for is to have a dedicated feed and database for each app, and then in the future with Fusion Identities (@arj and @Mix are keen to work on that) bind all these feeds together. The reason why we're forced to do this now is that Manyverse has ssb-db2 while all other apps have flume, and these write to different logs.

There are a couple different scenarios:

• I don't have any other SSB app using ~/.ssb and I want to start using Manyverse
  • Manyverse will create the feed in its dedicated folder
• I have another SSB app using ~/.ssb and I want to use that feed with Manyverse
  • "Migrate button" and delete the ~/.ssb
• I have another SSB app using ~/.ssb and I want to try out Manyverse
  • Use Manyverse in read-only mode
• I have another SSB app using ~/.ssb and I want to keep it like that while creating a new feed for Manyverse
  • Create the ~/.config/manyverse/ssb folder and open Manyverse
  • OR
  • Rename ~/.ssb to ~/.ssb-backup, open Manyverse and create a feed, close Manyverse, rename ~/.ssb-backup to ~/.ssb
• I want to use the same feed on Manyverse and other SSB apps
  • No
• I really want to use the same feed on Manyverse and other SSB apps
  • Symlink ~/.config/manyverse/ssb to ~/.ssb
  • Accept the risk of forking your feed if you're not careful about both logs having all of your messages in the same order

The "read-only mode and then migrate" was an idea that emerged from a session at #svendsolar by @cblgh if I remember correctly, and it's a decent one.

Question: would it have better to just present the user with a dialog asking them to choose between the 3 options below? (Typically it's just the 2 first options)

• Create a new feed
• Restore from 24-words
• Migrate from ~/.ssb permanently