Comment by evtaylor

2 years ago

My side project is a personal budgeting web app [0] based on these principles. The technologies to support this type of architecture are available and fairly mature.

For example in my budgeting app:

  - All of the user's budget data is stored client side in IndexedDB
  - Offline support via a service worker
  - Peer to peer synchronization between devices via WebRTC data channel
  - Lightweight IdP server which also handles the WebRTC signalling (via web sockets)

This setup is nice because the user's data never touches the server and very little server side infrastructure is needed (none at all if you don't need data synchronization). One downside with the data sync is that both devices must be online with the app open at the same time to sync, but perhaps this could be improved with web workers?

[0] https://dollero.app

7 comments

evtaylor

Reply
Cyphase  2 years ago

Looks visually quite similar to Actual[0][1][2] (open-source, local-first). Did one influence the other? Are they both inspired by some other budget software?

[0] https://actualbudget.com/

[1] https://github.com/actualbudget/actual

[2] https://github.com/actualbudget/actual/blob/d1e57340b88960d0...

  • evtaylor  2 years ago

    I discovered Actual while I was working on Dollero although it was not open source at the time. I believe we were both influenced by YNAB classic, hence the similar layout. I imagine hosting Actual was time consuming and expensive for the author because all syncing appears to rely on a centralized server and database. I'm hoping to avoid this with Dollero because the peer-to-peer syncing requires a much simpler server and is cheap and easy to host.

mk89  2 years ago

> but perhaps this could be improved with web workers?

This also means that I need to have a constantly running web worker on my phone/tablet etc...? In my time I am also trying to solve this problem of "data never touching a server" but I believe we're not there yet, despite all the devices we have: sometimes the smart watch is off, sometimes the laptop is off, etc., so you need a mechanism similar to "Google drive", and who never had sync issues with that? And that's a supercentralized solution. It's super hard to "merge" in a distributed async system.

  • adr1an  2 years ago

    You can add push notifications or whatever, the issue will be resolving the conflicts. I think the local-first ethos is valuable in situations (e.g. resilient communications a la reticulum network), but misses to address another bigger problem. Perhaps someone with knowledge on CRDTs, or data structures, knows better how much of timestamp this might be able to catch... maybe one day we have Transformers Models that take the data on both ends and just 'hallucinate' a merge that you can then manually intervene (in the case of code, run tests).., idk.

kwhitefoot  2 years ago

You could use an IMAP email account to send synchronization messages. Then the peers do not need to be online at the same time.