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!