As a compromise - maybe you tell us if you make it through the voting..? 
So we have an additional motivation to throw votes at your app..?
6 Likes
Will this be similar to Syncthing?
Yes, very similar.
2 Likes
I actually think it’s spoken like rhythm - just without the t and an n instead of an m 
1 Like
I think @Southside found one of your ads that are floating around the internet 
5 Likes
I should perhaps add that in the process of developing Ryyn, there will be two independent libraries developed, that I could have entered as independent projects in IF (but didn’t think of).
These are Autonomi-backed storages:
- A Key-Value store.
- An EventStore.
Later these will have bindings to a few of the most used languages.
For those not into the technical side of things, these are sorts of databases suited for different type of usecases/applications. They will be able to be used by developers when building software.
So Ryyn is actually 3 projects in 1.
Will extract those after everything is wired up and ready for an alpha release.
13 Likes
I thought I’d give a brief overview of differences, it could be deeper, but keeping it short now.
I’m continuously looking for inspiration and learning from projects like these.
The reason is also to shine some light on what it actually is that Ryyn does, what makes its internals stand out and how it leverages Autonomi to do this (this part is more implied than directly explained here, will have to wait).
I know this is a bit too abstract and technical for many, I just didn’t have more time for this in particular. I am working on documentation in parallel with coding, and most work is on the technical conceptual level, because everything user facing just requires a few lines, so far.
Ryyn vs SyncThing
For a user doing basic sync these two systems look almost the same. Add file and it appears elsewhere. Modify file and change propagates. Delete file and deletion propagates. The systems look the same.
Superficially, Ryyn and SyncThing behave identically.
But when conditions get slightly more difficult, Ryyn’s choice of system immediately stands out.
A brief comparison:
| Scenario | SyncThing | Ryyn |
|---|---|---|
| Two edits on disconnected devices | Conflict copy, unstructured | Two causal forks, trackable |
| Accidental deletion | Gone | Recoverable from DAG |
| Reinstall, DB wipe, device loss, crash | Treated as new device | Identity history persists, pick up where you left |
| File changes back and forth | Overwrites or oscillates | Multiple versions stored, switchable |
| Merge required | Impossible | Expressible by diff ancestry |
| Data loss possible? | Yes, on overwrite | No, by design |
Ryyn is a multi-writer, eventual-consistency system, tracking ancestry with inbuilt preservation of all forks. The system creates a bounded DAG of known, ordered versions per file, per replica.
It is fundamentally more powerful than SyncThing. It’s an entirely different system class, doing distributed state tracking instead of snapshot/file-copy model.
Ryyn has a selective materialization model, not just “sync latest”, but “materialize version X” (choose version for use), since in contrast to SyncThing, Ryyn treats replicas as causally constrained emitters, not naive writers.
Conceptually, the internal cost model of Ryyn is higher to give a better and expanded user experience, where SyncThing creates a shallower internal logic, a conceptually lower internal cost, but becomes more fragile in correctness in edge cases.
(Note: This says nothing about the actual codebase which can be inflated, complicated, messy and vice versa regardless of conceptual internal cost model. Idea vs implementation.)
One thing I am avoiding on purpose is a multitude of user input options (and non-options). More fine-grained control can be implemented later, but I’ve estimated that the largest need and most powerful tool for a broad user base is pure and simple fire-and-forget backup of folders.
11 Likes
I imagine, that another difference would be, tha SyncThing needs less maintenance (unless you lose data and have to redo your changes), Ryyn will need merging, recovering etc., right? So, SyncThing requires you to stick to some rules to keep your data consistent, and it’s probably not suitable for certain usecases, when you cannot do this, while Ryyn keeps you covered, but needs your attention to recover from disaster?
Question 2 – could Ryyn be used as a simple Version Control System? Is it sitting conceptually between Git and SyncThing?
2 Likes
This is awesome @oetyng and shows why I said what I did earlier. @Erwin you need to read this!
It is a VCS or will be if someone builds UI on it.
I don’t see any way in which SyncThing is going to be better than this because if, as he surely will, Edward implements the underlying data model correctly, you can build VCS, backup, anything you want on top - including something that behaves like SyncThing (ie simple) but never loses data should you need to hit the “Advanced recovery” button.
Awesome stuff!
6 Likes
No, I wouldn’t say so. Recovery steps are practically as simple as starting a new clone.
This is because the merging is happening all the time. The replicas in a sync group (devices watching the same folder) periodically look for new events in each other’s streams, and merge them right then and there (if participating with pull_enabled), so a converging stream is always held by every replica. The sync group converges on the same state in basic configuration (more on advanced further down).
On disaster, the disk is assumed to be wiped, and the steps are just as when starting from scratch: a selected folder is cloned.
So, on disaster (or new generaly), user:
- Downloads application,
- Enters key and can view every sync group related to that key (simple lookup in network),
- Chooses to continue with all, or select individual sync groups (watched folders)
This is the default path from first iterations of Ryyn.
In later iterations, when selecting a sync group, if the user only wants a specific replica within the sync group, they clone only that one. It may have been an emitter only replica (push_enabled && !pull_enabled), or an archive (!push_enabled && !pull_enabled), and thus user only wants the specific event stream it held, not latest or more progressed streams.
First steps of implementation will not delve deep into those features, but they are there and enabled, ready to be built. I.e. first implementations will use full participants (push_enabled && pull_enabled) by default and have a default sync behaviour/strategy. From there it’s ready for expanding into the full feature set.
The merge model is also simple to begin with (though still preserving all data fully DAG-compliant), where DAG features are ready and prepared for but will not be developed and thus exposed to users in earlier iterations. (With that I’m basically referring to more fine-grained user interaction with versions etc.)
4 Likes
Yes, it’s like what @happybeing said.
3 Likes
There is a large difference, where SyncThing uses block-level diffs, while Ryyn uses binary diffs. They both have their trade-offs, but I would say that they are specifically apt for their respective system classes - and they both have considerable weaknesses, it’s not easy to do this 
Since making the choice there, I have not currently looked deeper into it, but there is possibility to optimize for different uses. And perhaps a clean solution could be made for covering more of the cases in one go.
4 Likes
This is 200% a killer app ! A fast “eventually consistent” syncer would be extremely useful for a lot of (clearnet) applications as a backend.
6 Likes