3 ms·

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 ma

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 https://dollero.app

mk89 3y 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 3y 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.
Cyphase 3y 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/ https://actualbudget.com/ [1] https://github.com/actualbudget/actual https://github.com/actualbudget/actual [2] https://github.com/actualbudget/actual/blob/d1e57340b88960d04cb906735155f7dee4748b4a/demo.png https://github.com/actualbudget/actual/blob/d1e57340b88960d0...
- evtaylor 3y 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.
dugmartin 3y ago
This is really well done. Nice job.
- evtaylor 3y ago
  Thanks, I appreciate you feedback.
kwhitefoot 3y 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.

mk89 3y 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 3y 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.

Cyphase 3y 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/ https://actualbudget.com/ [1] https://github.com/actualbudget/actual https://github.com/actualbudget/actual [2] https://github.com/actualbudget/actual/blob/d1e57340b88960d04cb906735155f7dee4748b4a/demo.png https://github.com/actualbudget/actual/blob/d1e57340b88960d0...

evtaylor 3y 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.

dugmartin 3y ago

This is really well done. Nice job.

evtaylor 3y ago
Thanks, I appreciate you feedback.

kwhitefoot 3y 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.