We started using Syncthing about two weeks ago as a replacement for Dropbox with a fairly large group. So each node/device is a person and i have no control over them other than to kindly ask .
We are now up with about 15 Devices and will be about 30-50 at the end, sharing a single folder.
As part of the concept, we decided to let everyone be an introducer. Therefor, everyone can help make our mesh grow and there is no single responsibility.
While we did know that this will come with problems regarding the deletion of -now dead- devices, we relied upon the fact that it should (with the newer versions) be possible to delete the device by the first node who added the device.
Well, this didn’t work out at all. CRAP. Now the device gets reintroduced by a randomly choosen node every time.
So i politely but energetically call for help now.
Well, my idea of a solution is simple but not very elegant:
Implement a new standard-set option to eliminate devices, which aren’t seen online for a specific period of time. If this device comes online after it has been removed this way, it should be readded silently. This would work because a device notifies another device that it is in its list but not the other way around.
Therefor, devices that are removed this way have to be tracked locally.
Of course, the deletion of a device with this “simple” method shall not be broadcasted
to other nodes, but the readd should. This also means that the “last seen” has to be a global view from the network perspective rather than being a local view of the node.
Short- this information must be synced across.
I hope my idea is worth taking a look by the developers. Because at least we need a working solution now, not a perfect and elegant solution in a couple of years.
Thank you all in advance and sorry if this specific problem (and possible solutions) are already discussed a thousand times (without being any practical).
This is what i expected.
The initial device adding the node in question was a Android client v0.14.32. On this device, i deleted the “dead” node just to get it reintroduced by another node shortly after. Now the dead device is referenced/“introduced by” several nodes in a cyclic way, because i tried to get rid of it by disabling the introducer mode and removing it on some nodes under my control. There is now no end to catch, as every node sees this dead device as beeing introduced by someone else.
Also, even if it would have worked this way, i think there should be a self-healing feature like the simple rule for device deletion i mentioned. This is because its only me and another guy who solely care about how this mesh works out a year or two. If nobody removes the dead devices, its going to be a real mess.
What I mean is that when a device is added on an introducer, the other devices that once got it from that introducer will also remove it. Maybe there’s some other interaction if you have a cyclic introducer setup - don’t do that…
It’s not really clear to me how
Implement a new standard-set option to eliminate devices, which aren’t seen online for a specific period of time. If this device comes online after it has been removed this way, it should be readded silently.
differs from just not removing the device to begin with.
Imagine X was added on A, A introduces it to B, B introduces it to C.
C in general talks to A, but at the time it was added on A, C was offline, and came online when A was down hence why the introduction on C came from B rather than A.
Now you remove X on A, B is down for the time, C reintroduces it back to A. Once B comes back online, it still sees it on A (as it was introduced by C) hence does not remove it.
I don’t think there is a reasonable way to handle his.
Even if you advertise who introduced you to the device (if anyone), and if that changes on your introducer, assume removal, you’d still end up with a reintroduction just at a different part the chain based on who is online or not.
So sadly I think you are on your own unwinding the mess, and there is nothing reasonable we could do in this scenario.
Well, this was the main idea after all.
Let me short tell you more about our use case.
The folder we share contains educational material and also some inoffical tests gathered from alumni if our shool. We do not want someone to maintain this cluster. We do not want anyone to restrict who can add someone. Wie do also not want to exclude someone from sharing with everyone else. After our class will leave the shool, the next generation -already sharing this folder today- can add other following classes as well.
[quote=“calmh, post:5, topic:10441”]
It’s not really clear to me how … differs from just not removing the device to begin with.[/quote]
You see, most of the students will never ever understand the tweaks, bells and wistles of syncthing. They just dont care and thats fine. But something needs to clean up the ever growing list of dead devices.
If a device gets deleted after, say, 3 month not being online, thats nice. But what if this wasnt a dead device and it comes back again shortly after? In this case, the device is found in a list of previously “deleted” and silently restored.
If you care about the lengh of this list of locally deleted devices, it shall not be synced and fades away with time, as eyeryone is expected to reinstall syncthing from time to time. New Computer, Tablett, OS etc…
What if the creation was time stamped (or version vector or whatever could be used to track most recent) on node A that added it originally? Then that same time stamp was carried to all the introductions (only changed on add/remove not on introduction). Later if you remove it, that is time stamped (also on A in your example case). Now C reintroduces to A and it rejects because it has newer timestamp of removal.
This involves carrying a list of all removed devices indefinately. Not ideal, might work, but then you’ll have the other spectrum of users complaining introducer doesn’t work as its not readding a device I removed.
Or you could broadcast the originator (leaking things), so if A is proposed a device which it has introduced to thw cluster itself, you can ignorw it.
Personally not interested in solving this, but I’ll happily review and think through any PR that gets proposed.
.
We are now up with about 15 Devices and will be about 30-50 at the end, sharing a single folder.
As part of the concept, we decided to let everyone be an introducer. Therefor, everyone can help make our mesh grow and there is no single responsibility.