GP, I'm curious about the frontend stack as well.
The frontend for desktop/browser React, and Electron is used to create standalone apps. I don't love Electron, and if you don't want it a browser version is available too: https://app.actualbudget.com/
The mobile app uses React Native and has a custom UI just for mobile, but it shares styles and a few small components with web. I don't believe that you can build one UI that works well on both desktop and mobile.
All platforms share the backend code which runs in a separate process/thread. On mobile, I use https://github.com/JaneaSystems/nodejs-mobile to run the JS backend locally.
That's mostly it. No UI frameworks are used. I love UI/UX design so I built it from the ground up to be as usable and performant as possible.
* A custom rules engine (to be released in a few weeks). You'll be able to write a list of conditions for matching transactions, and a list of actions to apply when matched. The system will automatically encode what it learns as rules (apply category X to payee Y) so you can see what it's doing and adjust.
* Multiple budget types. Zero-based budgeting is cool, but Actual is just a tool for you. If you want, you can use a simple report based that just shows income vs expense. You choose the type you want adapt it to your lifestyle.
* Custom reports. This is really where having all your data local is incredible. You'll be able to write queries into your data, process it, and render any kind of visualization.
Now that sounds very cool.
Out of curiosity, do you have any plans to handle things that cannot be local first (for example with YNAB I like the Plaid Integration to pull transactions data out of banking).
Something like that for your application would need to clear through your own API right?
It's tough. I've wrestled with this for over a year. Bank syncing has to come from my server, which means by doing so you are giving us access to your transactions. No banking provider has any way for clients to contact them directly. I think this is possible with the right encryption, but nobody is working on it. I've given this feedback to Plaid but they don't care.
The majority of people need the convenience of syncing though. So I plan to launch it, and it'll go through my server, and I plan to communicate clearly the privacy that you are giving up by doing so.
I keep hoping to find a (maintained/viable) open source project that uses headless browsing to login locally and extract transaction details.
For my credit union, I "reverse engineered" the API and export multiple times throughout the day.
I wrote an extension that exports the data for CapitalOne, but I haven't gotten around to trying it either headless or even just in any automated fashion.
Easy automated export of user data, even beyond financials, is something I'd like to see more of. Feels like it could be a workaround while there's so little decentralization.
There _sort of_ is a solution where your computer directly connects to the bank. The format is called OFX (https://github.com/libofx/libofx), and there is a directory of banks that provide these files directly online. This site (https://www.ofxhome.com/) lists the URLs to use for each bank.
I used that for a while many years ago. But it's terrible and requires massive maintenance. For an app that requires connections to arbitrary banks, there's no way developers can support these direct downloads. There's always different errors in data for different banks, etc. Unfortunately, Plaid is solving a real problem
I'm doing a similar quasi-local-first project with p2p. Ive been toying with libp2p[1], which underpins a number of distributed storage solutions, and originated from ipfs.
> [1]: https://libp2p.io
What causes these problems? NAT?
For JavaScript, see: https://github.com/feross/simple-peer
It's just a mess of documents referring to other documents for details.
I'm sure it all makes sense if you just spend a few months making sense of it all, but it's very not much accessible to someone looking do it as a weekend project.
Not understanding the byte protocol is understandable but a quite different topic. You really don't need to understand it, there are libraries for many programming languages doing the hard work for you. And if you want to understand it, it's normal you have to read a lot of different documents. If you would have no understanding of HTTP/2 you would have to read a lot of RFCs too as every version is built on the former version with retaining many of it's concepts
That was another person, I don't struggle with that.
> If you would have no understanding of HTTP/2 you would have to read a lot of RFCs too as every version is built on the former version with retaining many of it's concepts
The turd doesn't smell less because you managed to find another.
The reason I wanted to read about it was because some sources say STUN requires two public IPV4. I wanted to know what would happen if I had only one. Or if I had two IPV6.
Does Actual expose any api stuff?
Having all of the data local is a superpower. It changes how you build the app, and you just never have to worry about the network. Everything is fast _by default_. It's great.
The app uses CRDTs to sync and it's unlocked a lot of powerful stuff like a robust undo system. We also offer end-to-end encryption.
On the negative side, over time I've stepped back a little from being truly local-first. The mobile app used to connect to the desktop by pointing the phone's camera at a QR code on desktop, and it would literally sync peer-to-peer. Maintaining that was nightmare and users had endless networking problems. Our network infrastructure unfortunately is not built for truly peer-to-peer apps. Maybe ipv6 will help, I don't know. My app now has a "centralized" server but it's really just a backup that gives some convenience - the app is still totally local but syncs through a single server. You can work on it for weeks offline and then sync up. In the future when p2p is ready, I'll be ready for it.