> or do servers only hold the mutex when briefly while they persist data?
This: it's only held during document updates, which in itself is an operation we debounce to avoid unnecessarily hammering the DB. Eventual consistency is our friend here, so this isn't a high frequency requirement (as I'm sure you're aware!).
If you can nail the "sync-on-close" mechanism in browsers, then you're golden :-)
How do you handle it within y-sweet (cool project, BTW!)?
We run Y-Sweet in Plane.dev (also our open source project). Plane runs a process for every document across a pool of compute, so each process effectively has a lock on that document’s data and can persist on a loop without worrying about conflicting with another writer.
I totally agree that the UX is basic and unclear at present. Lots to do on that front; on design, documentation and otherwise! Appreciate the feedback.
You don't have to search in order to add anything, though. Focusing on the (empty, or otherwise) search and pressing Enter will add an item below. Enter on any item will do the same. However, the text within the first search-group will be invisibly prepended to each line you add whilst it's filled. This is a method by which you can group notes via a common prefix. Also, each TAB-separated search group is applied to the result set individually! There's some stuff in the help popup that might make things a bit clearer.
The binary size is an unfortunate side-effect of golang's webassembly compilation sizes. I can't (yet) use tinygo as the compiler as I rely on some unsupported packages. The app will be progressive soon enough, to minimise downloads and optimise startup.
Edit: I should probably mention as well, that on top of the basic textual capabilities, the web app is managing all data syncing/merging/playback/collaboration, continually. The cloud infrastructure is very basic, namely there as plumbing to ship DB files to the appropriate places. All the heavy lifting is done locally! Incidentally, this paves the way for potential E2E encryption (the app is ready, the key management/distribution etc is the challenge here)
Haha, good point - perhaps "TBA" would have been more appropriate here! Thanks. I've been so far more focused on getting MVP out, so haven't given a lot of thought to the specific pricing tiers yet, but I hope to get all that set up really soon (pending some profiling/feedback etc).
Manually! The CRDT itself is an event log. The client state is built from a secondary data structure which replays from the log (the extent of the "replay" determined by how much data needs to be merged etc)
There is so much good work here, good job. Just curious, what pushed you to make this aside from the obvious usefulness of it? Was there something specific? Also, while making it, did you perhaps also use it to collab with others during the process? Thanks again
Honestly, this was a personal project that got a bit carried away. The initial iteration was just a simple terminal app that allowed me to fuzzy-search through a lot of my notes quickly, with the ability to store and access a plain text file against each. I was rsyncing to the cloud so I could access my data across different machines, but got frustrated at the lack of conflict resolution, so figured I'd build a mergable data structure and use that. It _then_ became annoying that I couldn't easily access my list on the go, and hence the web app was born.
I actually (amusingly) built this completely on my own, which certainly made things more challenging WRT testing the collaborative components. Have certainly had the opportunity to test it a bit (mostly for "life" things such as sharing shopping lists...) but hopefully opening up the MVP will get some more organic and extensive usage and the opportunity for some good feedback!
Good question. It's probably not even an edge case (dependent on usage), but a limitation right now is that a unique "unit" of collaboration is a single item/line, so if two people update a line offline, the winning line will the most recently updated. I can imagine that would get pretty annoying pretty fast. Granular collaboration (updating per character rather than per line) is on the backlog, priority will be determined by feedback of course.
Another thing to solve is ever-growing data sets. I've tinkered with some mechanisms to combat this (namely compacting the CRDT event log based on a bunch of rules) but this is tricky and I'd prefer the app to mature a little before I implemented this. Also on the backlog! Lots to do for sure.
A little while ago I shared the terminal based version of the project (https://github.com/Sambigeara/fuzzynote) with the community. I since got inspired, and disappeared into my loft for 9 months to work on leveraging the core logic for use in a WASM-based web client. So you can now sync your notes between your terminal and any reasonable modern browser (some early limitations in mobile)!
The project has (finally) reached MVP and is ready for use, and any feedback is very welcome.
This is so cool :) I can't wait to use this. I was just describing something similar to a friend I was collaborating with recently, and actually uttered the words "hey you know, somebody should make ..." And here it is!
I built this one myself, it's an event log which is used to progressively build onto a secondary data structure (which is more closely tied to the client)
Currently I'm just using the hosted AWS Cognito offering straight out the box (just as a temporary measure to enable people to sign up). I hope to have this looking/operating a bit better down the line.
Providing Go has a decent enough client/interface into the tools you listed above, absolutely!!
The original "remote" I implemented was a single S3 bucket (no websockets, just a static file location), and if you set the synchronisation intervals to something in the realms of 10ths-1s of a second, you had near enough real time sync/collaboration!
I created a (really poorly named) abstraction called a WalFile which is basically an interface to implement these remote targets. Theoretically, you could build one for any service out there. If there was demand for one, I'd totally give it a go!
Sods law - I temporarily disabled support for the direct S3 remote yesterday because it's slightly broken. But it's a minimal amount of work away from having it functioning again.
The sync mechanism itself is completely agnostic. The interface I'm describing is more in regards to accessing it. Only requirement is that you can access a file and run a bunch of basic operations (list, get, put etc)
