You are reading content from Scuttlebutt
@SoapDog

The last couple days, actually since I did the little PR to remove the host app from #scuttle-shell, I've been doing a little skunkworks project here. I was feeling that I was duplicating too much work from our community in building #patchfox. Lots of the problems I'm having to solve were already solved in other clients. I felt quite frustrated with simple stuff such as finding and caching avatars in a good manner, the kind of stuff that we have ready-made code for already.

So, as an experiment, I picked many of our current clients and tried to see how far I could go trying to port them to the browser (aka remove electron). My obvious pick was #patchbay because the code is similar to TickTack which is something I am familiar with and is has basically all features under the sun. I've spent two days decoupling electron from patchbay until I realize I was basically being a rock trying to find the oncoming tide, there was no way I could win without rewriting a lot of the dependencies.

I thought Electron was going to be the main challenge but it was not, the problem is our pervasive usage of the filesystem module and other NodeJS stuff. Lots of the dependencies read files in runtime by storing or generating paths in runtime. This makes it a lot harder for things like browserify to work. I started decoupling a lot of stuff such as electron events and file system access, just to realize that our whole ecosystem has a ton of bulk-require and micro-css, both of which are using file system and sometimes runtime values. When I reached that point I knew I couldn't move further with patchbay, so I picked another client.

I tried #mvd, which is much smaller, so I thought it would be easier to port but there is still a lot of filesystem access on the dependencies, specially in some very deep places in #patchcore. I couldn't move it further too.

So, I am back with my somewhat reinvention of the wheel but I felt I needed to write this message as a potential call to action for future implementations of stuff in our community. I think we should:

  • Restrict or concentrate filesystem access to a single module/library which is called by the others. This might make it easier to port code.
  • If the paths are known in design time, we should try to pass them explicitly instead of relying on runtime generation of glob strings. This helps browserify.

This is not only to benefit browser people like me but this should help us in the future move more stuff to WASM or other future technology.

Be aware that the exercise I did the last couple days was done to see how far I could go. To learn where our hard edges are in terms of libraries and dependencies. I was not expecting to port those clients to the web, I wanted to learn where were the places that would give me trouble. There is nothing wrong in how those clients were built, personally I admire Patchbay and mvd a lot. I think they both show how versatile scuttlebutt is. You can have both simple and complex clients without sacrificing usage. I think they are awesome but I think in the future, we might benefit from restricting the nodejs-only parts of our code to a more confined space while the rest of the code is standard ES stuff.

User has chosen not to be hosted publicly
@Ham Nox
Voted this
@Gergely Polonkai 📱

The problem, as i see it, is n\that a lot of SSB devs think in JavaScript (i heard about plans on rewriting stuff in Rust, but still…)

Few weeks ago i started working on a GTK based client in C. It connects to an sbot server, does the SHS authentication, and issues a whoami query. While doing the basic networking stuff, i realised that there are a lot of things i’ll have to do myself, like Markdown parsing (of which i recently read a post from cel, that some clients have problems with it).

So yes, there might be a lot of coupled things, but for me right now the strongest coupling is JavaScript itself (but at least i can use the actual libsodium, not a binding :)

User has chosen not to be hosted publicly
@kas
Voted this
@cel
Voted this
@lzlr
Voted this
Join Scuttlebutt now