In the not to distant future I plan to release some code open source. They are private projects for now, but I realised it may not be appropriate to use the Syncthing name as they are not official projects?
The code is client only, so only connects to a single Syncthing instance. so I was going to call the projects SyncthingClientCore for the library and SyncthingClientDrive for the first project that uses the library to mount the shared folders as a FUSE mount. I will put a clear message that these are not official (and at the moment they are very alpha) in the README, but I didn’t want to cause any confusion or annoy anyone.
Sounds very interesting!
It’s anyway cool your building on Syncthing and even nicer your planning to open-source it. Can you add some more spoilers about your project, i.e. about what the library implements (full BEP?), what technologies you use and/or which platforms do you intend to support. Don’t get me wrong, I don’t expect any in-deep answers, I am just curious and looking for any tidbits you want to share - I am looking forward to your release.
There’s quite a few community projects using “Syncthing” in their names (Community Contributions — Syncthing v1 documentation, also a long unmaintained fuse client: GitHub - burkemw3/syncthingfuse). As long as the project actually does interact with Syncthing, I don’t think there’s an issue per se. The examples you gave in specific may be a bit too generic, especially “SyncthingClientCore”. In my opinion the name should either have a unique element (e.g. like SyncTrayzor) or something that links to what is special about it/what it does (e.g. Syncthing-GTK). So something like “SyncthingFUSELib” or “SyncthingFUSECore” and “SyncthingFUSEDrive” (or just “SyncthingDrive”) would in my opinion be preferable (though also not very catchy).
The library is written in TypeScript using node. It uses SQLite to store the index, so we should see reasonable performance even for relatively large numbers of files (no test results on this though!).
It so far implements the authentication scheme (Luhn with a twist etc.), all the BEP protocol required to setup the index locally in the db and to request blocks. As well as the global discovery and relay protocols. So you can start up the library with just the device ID and the URL set to “dynamic” and it will connect as long as the device is signed in to a discovery server.
As I wanted a client only library it doesn’t sign itself in to a discovery server, or advertise itself for local discovery. It also does not accept any incoming connections on the Syncthing port. It’s to be used in a star network topology with a Syncthing instance.
I also wanted to have different way of working with the files built in to the library. So every file / folder can be set to always sync (which replicates the normal behavior) or you can just request the file manually which will cache the blocks locally and mark them as stale if an index update invalidates them. Cached blocks that aren’t marked as stale will be served on subsequent file requests, otherwise they will be re-requested. I will need to implement a sane cache control scheme, as the whole point of the caching system is to be able to work with huge folders from clients with more limited drive space.
It works as read only at the moment, I wanted to get that solid before moving on and getting Index Updates from this client working. But I thought it may to useful to someone, so thinking about a release on Github.
The idea with the library is to bring out all the BEP and db stuff so any type of client can be made, hence the reason the name is so generic. I wouldn’t want to use FUSE in the name, because all the FUSE stuff is in the first project to use the library. But thank you for your suggestions I will have a think.
OK that was much longer than it was supposed to be!
Makes sense. I guess with “Client” you want to express that it’s not a fully integrated continuous sync node of a “Syncthing Cluster”. At the same time every node is a client, there’s not really the usual distinction between client and server for Syncthing. That’s why my initial impression is, that “Client” is pretty generic and doesn’t add much to the name (though FUSE was obviously a bad suggestion). Maybe include “TS”? Anyway that’s deeply into bikeshed territory, of course feel free to disregard this and name it whatever you feel comfortable with
I think I’ll go SyncthingTS for the library as this describes what your getting and may help discovery for people looking to use Syncthing with TS. As well as SyncthingDrive for the first client. Naming things isn’t really my forte, so being catchy isn’t a priority!
As a name has been chosen I thought I’d quickly up the project to a public repository.
No one should use this yet, the API will likely change with every push and I have not done nearly enough testing. I should also write some tests, but as this is purely spare time and I like writing features more, it hasn’t been done.
