4 ms·

> Dropbox! Well, not necessarily Dropbox, but any cloud-based file-syncing solution. iCloud Drive, OneDrive, Google Drive, Syncthing, etc. > It’s perfect — man

by klabb3 2y ago

> Dropbox! Well, not necessarily Dropbox, but any cloud-based file-syncing solution. iCloud Drive, OneDrive, Google Drive, Syncthing, etc. > It’s perfect — many people already have it. There are multiple implementations, so if Microsoft or Apple go out of business, people can always switch to alternatives. File syncing is a commodity. This doesn’t work for collaborative software. It’s also highly questionable for realtime software like chat. That’s a solution looking for a problem. There is exciting movement in the space but imo people focus too much on CRDTs, seemingly in the hopes of optimal solutions to narrow problems. What we need is easy-to-use identity management, collaborative features without vendor lock in and most importantly, a model that supports small-medium sized businesses that want to build apps while making a living.

mweidner 2y ago
> This doesn’t work for collaborative software. Is the issue the lack of real-time updates? In principle, you could work around that using a separate WebRTC channel for live updates, with the slower Dropbox sync serving as the source-of-truth. (It does indeed take >=5 seconds for Dropbox to sync a collaborative app in the way the author describes, in my experience.)
- fwip 2y ago
  I think concurrent editing is where Dropbox collaboration falls down. E.g: you edit the intro paragraph, and your buddy adds a conclusion, both while offline (or simultaneously). Dropbox can't/doesn't resolve the conflict in your files, and instead picks a winner. This is still solvable by your app, but requires additional logic/storage above what the "shared folder" model provides.
doctorpangloss 2y ago
Some of that will sort itself out naturally. Is there any normal person who goes, “Man, I love going through the toil of coordinating file structures with other people!”
euroderf 2y ago
If somehow Dropbox ran SQLite and sync'd it across devices for me, I'd pay for that.
- mweidner 2y ago
  Sounds like ElectricSQL (though they assume an additional central node running Postgres): https://electric-sql.com/ https://electric-sql.com/
- ochiba 2y ago
  I work on PowerSync which does Postgres-SQLite sync, FWIW: https://www.powersync.com/ https://www.powersync.com/
unshavedyak 2y ago
> This doesn’t work for collaborative software. It’s also highly questionable for realtime software like chat. That’s a solution looking for a problem. Yea, a lot of good foundations won't work in specific requirements. Live collaboration is a very different experience though than other applications need. Why pay the cost for something you aren't using?
- klabb3 2y ago
  > Why pay the cost for something you aren't using? If you don’t have multiple users vanilla Dropbox with old-school file based apps are fine because you don’t need concurrency for one person. So I agree with you: why pay for CRDTs if you aren’t using it? This has been solved for 15 years at least. For local first to be a meaningful term, it has to provide something that can compete with modern apps while providing some meaningful change in terms of portability, data ownership, privacy, hackability, self sovereignty, etc. Otherwise we’re just over-engineering ourselves into spurious idealism.

by klabb3 2y ago

mweidner 2y ago

> This doesn’t work for collaborative software. Is the issue the lack of real-time updates? In principle, you could work around that using a separate WebRTC channel for live updates, with the slower Dropbox sync serving as the source-of-truth. (It does indeed take >=5 seconds for Dropbox to sync a collaborative app in the way the author describes, in my experience.)

fwip 2y ago
I think concurrent editing is where Dropbox collaboration falls down. E.g: you edit the intro paragraph, and your buddy adds a conclusion, both while offline (or simultaneously). Dropbox can't/doesn't resolve the conflict in your files, and instead picks a winner. This is still solvable by your app, but requires additional logic/storage above what the "shared folder" model provides.

doctorpangloss 2y ago

Some of that will sort itself out naturally. Is there any normal person who goes, “Man, I love going through the toil of coordinating file structures with other people!”

euroderf 2y ago

If somehow Dropbox ran SQLite and sync'd it across devices for me, I'd pay for that.

mweidner 2y ago
Sounds like ElectricSQL (though they assume an additional central node running Postgres): https://electric-sql.com/ https://electric-sql.com/
ochiba 2y ago
I work on PowerSync which does Postgres-SQLite sync, FWIW: https://www.powersync.com/ https://www.powersync.com/

unshavedyak 2y ago

> This doesn’t work for collaborative software. It’s also highly questionable for realtime software like chat. That’s a solution looking for a problem. Yea, a lot of good foundations won't work in specific requirements. Live collaboration is a very different experience though than other applications need. Why pay the cost for something you aren't using?

klabb3 2y ago
> Why pay the cost for something you aren't using? If you don’t have multiple users vanilla Dropbox with old-school file based apps are fine because you don’t need concurrency for one person. So I agree with you: why pay for CRDTs if you aren’t using it? This has been solved for 15 years at least. For local first to be a meaningful term, it has to provide something that can compete with modern apps while providing some meaningful change in terms of portability, data ownership, privacy, hackability, self sovereignty, etc. Otherwise we’re just over-engineering ourselves into spurious idealism.