# Local Discovery and Block Exchange protocols in Kotlin?
**URL:** https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493
**Category:** Development
**Created:** [May 26, 2022, 10:43pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493 "2022-05-26T22:43:19Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@travisfw](https://forum.syncthing.net/u/travisfw)
#### Post date: [May 26, 2022, 10:43pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/1 "2022-05-26T22:43:19Z")
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.
---
### Author:  [@AudriusButkevicius](https://forum.syncthing.net/u/AudriusButkevicius)
#### Post date: [May 26, 2022, 11:28pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/2 "2022-05-26T23:28:16Z")
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](https://github.com/syncthing/syncthing-lite)
---
### Author:  [@basiliscos](https://forum.syncthing.net/u/basiliscos)
#### Post date: [May 27, 2022, 6:48am UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/3 "2022-05-27T06:48:08Z")
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.
---
### Author:  [@travisfw](https://forum.syncthing.net/u/travisfw)
#### Post date: [June 6, 2022, 3:06am UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/4 "2022-06-06T03:06:43Z")
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?
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 6, 2022, 10:31am UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/5 "2022-06-06T10:31:49Z")
I’m not 100% sure what it refers to to be honest, I think the bep specification should cover it.
---
### Author:  [@travisfw](https://forum.syncthing.net/u/travisfw)
#### Post date: [June 6, 2022, 4:10pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/6 "2022-06-06T16:10:18Z")
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.
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 6, 2022, 5:13pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/7 "2022-06-06T17:13:37Z")
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.
---
### Author:  [@basiliscos](https://forum.syncthing.net/u/basiliscos)
#### Post date: [June 6, 2022, 5:31pm UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/8 "2022-06-06T17:31:39Z")
This is exactly what I mean 🙂
---
### Author:  [@AudriusButkevicius](https://forum.syncthing.net/u/AudriusButkevicius)
#### Post date: [June 7, 2022, 8:20am UTC](https://forum.syncthing.net/t/local-discovery-and-block-exchange-protocols-in-kotlin/18493/9 "2022-06-07T08:20:56Z")
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).