Clarification of the framework

[SoylentGraham]

Can someone clarify the structure of the underlying syncthing implementation for me?

I was reading that go doesn't compile to libraries very well (Im presuming from these comments that maybe it doesn't do CAPI?) and that this project has a go-swift bridge.
Given that this is for ios, I figured it's not launching a process like the official macos syncthing app, but then its using the syncthing code directly (kudos!) and the readme say's its running a node in-process (a fork()?) - or is that just implying its in the same process?

Getting to my point... if this core IS an actual library and not just IPC to a process, maybe it would be beneficial to spin the core -> xcframework into a seperate repository that just provides a swift package?

[keybits]

This is covered quite well in Tommy's blog post announcing the project: https://t-shaped.nl/posts/synctrain-a-rethought-ios-client-for-syncthing

(While I'm here - thank you so much for making synctrain - it was the missing piece in making iOS tolerable for me!)

[SoylentGraham]

Okay, if I understand that blog correctly then (it's all high level...) it's using bits of syncthing's core code for some standardised bevhaiour...

My first attempt was to try and use the Syncthing code’s functions for generating a device identity.

....Syncthing function called RequestGlobalFile was accessible from the Go wrapper. This function can be used to fetch a block (part of a file) from a Syncthing peer on demand. This, combined with access to the global folder tree, ...

But then as it mentions parsing protobuf, I guess this implementation is handling the protocol in swift.

So I guess this framework is running the node, rather than using the core/go code to run a node (and thus skipping all the file system stuff)

[pixelspark]

The app is written in Swift and that is the entry point for it. The app relies on a library (SushitrainCore.xcframework) that is built from Go code using gomobile. This Go code imports Syncthing packages, so effectively the xcframework library contains all of Syncthing. The framework additionally contains various 'glue functions' and e.g. the streaming server.

On startup, the Swift side calls into the (Go) framework, which calls into the Syncthing packages. Roughly speaking at startup it does all the things the main function of the regular Syncthing binary will do to start up a full Syncthing node (in the current process, so not forking or spawning a separate one).

We are not doing any protobuf parsing in Swift. There is a little bit of protobuf parsing in the Go framework for locally decrypting files created by encrypted peers (as Syncthing's packages do not expose these functions). All the filesystem stuff is handled in the Syncthing Go code (with the exception of the virtual 'photo filesystem').

[SoylentGraham]

These reason for this enquiry was because I wanted to connect to other nodes and get information of what folders/files were around, but not just IPC to another process, thats interfering with the file system, just an interface. (I have made a macos filesystem-sync extension for the official macos client which lets me browse other nodes with a virtual filesystem/folder, but its obviously running a whole other node and adding files, so have been trying to see if someone has implemented the protocol and not just a wrapper around another exe :)

[pixelspark]

Cool, is it open sourced?