Thread

Over the past 6 weeks we've been rebuilding the White Noise flutter app from scratch. We use flutter_rust_bridge to keep all core logic and crypto in Rust. But trying to follow Flutter "best practices" led to too many providers, unclear state ownership, and caching at too many layers. When we were in Costa Rica back in late November, we took a hard look at what we had and decided to do a spike based on a collection of ideas that @pepi had. That spike quickly showed a lot of promise and we've combined it with a beautiful new design from @Vladimir KrstiΔ‡ The new approach (codename Sloth πŸ¦₯): - Hooks for local/ephemeral state, not stateful widgets - Providers only for shared app state - whitenoise-rs crate is the source of truth, no Flutter-side caching - 99.7% test coverage Simpler patterns, faster iteration, way easier to reason about. Sloths might be slow but they're the most efficient animals on the planet! This has also given us a chance to incorporate all the security audit feedback into MDK and whitenoise-rs so not only will the app be faster and more beautiful, it'll also be more secure! I'm getting excited to launch the new White Noise in just a few weeks!

Replies (16)

↩ replying to Boog
The sloth repo (where we're currently working on app changes):
GitHub
GitHub - marmot-protocol/sloth: Whitenoise playground app
Whitenoise playground app. Contribute to marmot-protocol/sloth development by creating an account on GitHub.
 The whitenoise-rs repo (the rust backend to the flutter app):
GitHub
GitHub - marmot-protocol/whitenoise-rs: The Rust brain for the White Noise app
The Rust brain for the White Noise app. Contribute to marmot-protocol/whitenoise-rs development by creating an account on GitHub.
 The MDK repo (this is the general library that can be used by anyone who wants to build a Marmot Protocol powered app):
GitHub
GitHub - marmot-protocol/mdk: Marmot Development Kit
Marmot Development Kit. Contribute to marmot-protocol/mdk development by creating an account on GitHub.
 The sloth repo will eventually disappear and all that code will be moved back to the whitenoise repo (
GitHub
GitHub - marmot-protocol/whitenoise: The White Noise Flutter app
The White Noise Flutter app. Contribute to marmot-protocol/whitenoise development by creating an account on GitHub.
)
It might be different, but this kinda reminds me of something I'm doing with my library for processing payments cashu spilman channels. (I have a question at the end of this long comment) I have Rust code for processing payments, wrapped around a transport-neutral and stateless core The wrapper needs to do complex stuff, while also managing state ("how many payments have been made on this channel so far?"). But I didn't want the wrapper to hardcode an arbitrary choice about how to store the state, e.g. SQLite So, I have a relatively dumb 'Host' interface, where the developer specifies how state is managed. For example, it has a methods "mark_closed(channel_id)" where the developer fills in the code that writes to the database of their choice to record that a channel is now closed. The developer will typically not call those functions directly from their code. They just call a higher level "process_payment" method in my library which does all the complex stuff and which calls the Host object when needed The Host also handles all the "pricing policy" Anyway, I should get back on topic and ask a question πŸ™‚: I guess you might have something similar? The MDK doesn't need to know where state is stored? I vaguely remember dealing with this when I used the MDK a little on my toy app. I think I had to do something special to get it working with localStorage in the browser, but I forget the details
↩ replying to SatsAndSports
Yeah! Sounds very similar. We're using a set of storage traits in MDK so that the storage layer is abstracted from the code. The traits define the interface that any storage backend has to implement, then MDK can just call those methods when needed and doesn't need to know exactly what is happening in storage. We have two implementations that we maintain; a simple memory storage backend (mostly for tests) and a sqlite storage backend (which is now also encrypted at rest using SQLCipher). I hope that more storage backends will crop up from the community for other databases over time. I only talked about the Flutter app refactor here but we've done a massive refactor of MDK and the whitenoise-rs crates as well over the last two months. Largely based on the audit feedback but also cleaning up and improving a lot of things based on learnings of having the app out there in the wild over the last 7 months.
this is why i'm not a fan of flutter for desktop apps. not so complicated if it's flutter, dart and kotlin on android/ios but really a problem with integration because of the way they designed flutter. and it pleases me to hear that using rust doesn't solve any of this problem, because using Go to build the core of apps has the same difficulties with flutter/dart/kotlin/swift stuff as rust. the lack of polished, mature GUI libraries for both rust and Go is a big problem. the both languages are far better for writing software than trash like swift, kotlin (fuck you java) or javascript (which microsoft implements the start menu with, react native). the whole mess of app development frameworks and languages and the utter shit that it all is right now, is absolutely infuriating.