Local Discovery and Block Exchange protocols in Kotlin?

I’d really like to write some tools to interact with Syncthing peers in Kotlin. Is there any such implementation, or plan to implement the protocols in other languages? Python? Ruby? I wish I had the time to read the spec in detail and write a library, but I don’t see much probability of actually doing that.

1 Like

There is some very very old code here that you could revive: GitHub - syncthing/syncthing-lite: A Sync Browser: a browser app for Syncthing-compatible shares


Syncthing protocols are quite easy to implement: they are just protobuf messages send over TLS-connection. However, the Syncthing model is quite complex and it is not exposed directly (which is hard to do), only client-API, which is, probably, not what you are looking for.

Is the Syncthing model fully documented anywhere? Or is it all under one folder in any source repository? Or is it not well encapsulated in any software, even for internal purposes?

I’m not 100% sure what it refers to to be honest, I think the bep specification should cover it.

If the BEP spec covers everything, why does @basiliscos say the model is “quite complex and it is not exposed directly”? Getting a bit confused, I am.

I’m not sure. I mean, implementing a program like Syncthing is like a hundred thousand lines of complexity, and the protocol is a teensy part of that. But you’re asking about the protocol I think.

1 Like

This is exactly what I mean :slight_smile:

1 Like

Also, we tried really hard not to break the protocol over the years, which means certain features are implemented without having changed the protocol when we in theory should have.

For example there is no explicit message for renames, we rely on a certain order of add and delete messages arriving to best-effort interpret that as a rename etc.

There is quite a lot of logic in just using the protocol, there is quite some amount of state that needs to be tracked, etc.

There are other parts like relays, discovery, nat punch through, database schema, which are all not part of the protocol but have significant though that went into them, and wouldn’t be trivial to replicate (on the other hand could potentially be done better if not carrying the need for backwards compatibility, legacy etc etc).