Beta test my new iOS app for Syncthing

Unrelated : I have sent you a few emails and reports via the TestFlight beta. But maybe you would prefer to receive feedback / requests / ideas from another channel instead ?

  • This forum thread ?
  • Github discussions ?
  • Screenshot + email from TestFlight ?
  • Other ?

Your app is really a life changer :heart: !

I would be open to that, sure! (And indeed, at least if someone could dig into the whole paperwork thing, it would help a lot, and then the app could simply be made available in France).

The preferred channel for feedback on the app itself is via TestFlight (I don’t always see a reply e-mail address so be sure to turn that on, I try to reply in many cases). You may also send an e-mail directly. For general discussion (like the France situation), either here or Github (and I suggest we continue via e-mail together on the paperwork for France).

Does Synctrain support untrusted devices? I can’t find any reference to these algorithms being used in Synctrain’s source code, only Ed25519 signing.

EDIT: I’ve just seen your were replying on behalf of Syncthing and not Synctrain. This is exactly what I was looking for regarding the Syncthing part of things. And I’m now looking for which potential additional algorithms are used by Synctrain in itself…

I’d be willing to help here but I need to get answers regarding which algorithms are actually used by Synctrain.

Also, when you say you don’t want to get support requests for this version, what are you meaning exactly? This version would be an exact copy of yours, just with the paperwork done (as long as it follows your release pace, of course).

Because on the other side, asking someone who only made the paperwork and published the app to support it while they don’t develop it would be even more inefficient.

Synctrain incorporates all of Syncthing in its binary form and therefore must declare encryption used by syncthing. (Additionally Synctrain uses a signature scheme for creating secure localhost http URLs for streaming video, also implemented in Go libraries and not iOS provided ones, so also to be declared).

1 Like

Awesome! Also opensource!

Is it possible to publish in Kazakhstan App Store? Mobius Sync is already available, so it’s in the clear?

Thank you anyway!

Any way to donate? I didn’t see a link in your github. Also, no IAP?

hello :slight_smile: Just came across this and have tested it out on my iPhone, so far working great :slight_smile: Even got it to work over Tailscale.

I too would not mind to donate to this, this is what I been looking for for years.

Only question I have is: The description and update log on AppStore is only in Dutch?

Thanks!

Currently I am not accepting donations for fiscal reasons (the small amounts donated likely won’t even cover my accountant’s fee for dealing with the donations properly). Don’t feel guilty about using the appp for free, I built this for myself and I am just happy others can benefit from the work as well.

App Store changelog etc. should be available in English and Dutch. Apple may display Dutch for you instead of English depending on your locale settings/preferences or in specific countries. A detailed log of changes (technically) is always available here in English. The current App Store version corresponds to tag v1.7.23 (shown as “1.7 build 23” in the App Store).

4 Likes

I’m new to iPad/IOS but when I search the App Store from my device (in the US), I don’t see Synctrain. Is the app available in the US?

The app currently is only available in the EU and a handful of other countries. This is due to regulatory requirements for publishing apps that contain encryption (Synctrain doesn’t use iOS built-in encryption but rather the Go encryption libraries Syncthing uses, hence the requirement). An application for an exemption has been filed with the US BIS but so far I haven’t received a response.

2 Likes

Thanks for writing such a great app and article! I’ve tried so many (self hosted) syncing tools over the years. Only Seafile, Resilio and Syncthing are able to sync my dataset of 750.000 files performantly. About 600.000 of them are smaller than 100 kilobytes. Last time I checked (again) tools like Nextcloud and Pydio Cells choke on many small files…

So we’ve been using Syncthing on a NAS and MacBooks in our household. I installed Nextcloud on the NAS to make the files synced by Syncthing available to our iPhones via the Nextcloud app (which also handles photo upload). This way I can search and browse (with thumbnails) from my iPhone the files I sync with Syncthing. But I’m not too happy with the (maintenance) overhead of Nextcloud.

Synctrain gets me excited, because I may soon no longer need Nextcloud. :slight_smile: In its current state it’s already better than accessing my files via SBM, thanks to the search feature and thumbnail support. The video streaming is very neat too! I’m very much looking forward to a non-copy photo sync feature solution and improved thumbnails.

Out of the box it shows thumbs for some JPG files, but not all of them.

This screenshot is from Synctrain on my Mac but the same happens on my iPhone. I tried pre-generating thumbs on my iPhone, but this obviously takes really long. The process never completed as it seems to crash randomly. And when I pre-generate thumbs with the Folder as destination (to distribute the thumbs cache), they are put into new directories named 0 to z in sync folder root. Can they be put inside e.g. a .thumbs folder instead?

Ideally, for my use case, I’d schedule my NAS to pre-generate thumbs and store them inside a hidden directory in the root directory of each Folder. All Synctrain clients could then use these thumbs for faster previews.

Congratulations on creating this neat app, I really dig the file-centric approach!

Thanks for the kind words!

I am not sure why certain thumbnails are not being generated in your case. Thumbnails are generated on demand only for files that are below the configured maximum file size (see settings). When the original is not available or many downloads are already in place, the app may not be able to fetch the file in a timely manner. Generating thumbnails in advance should preferably be done on a device that has all the files locally. Finally, thumbnail generation uses the system QuickLook functionality, so if that is unable to produce a thumbnail for some reason it won’t work either.

For syncing thumbnails, I suggest you create a separate shared folder, so that the thumbnail files do not end up together with the original files. Thumbnails from different folders can be stored in the same thumbnail folder without issue.

That must have been it! The two thumbs in my screenshot are from images < 2MB and the ones that didn’t show are all larger.

I’ll try that!

This seems to work, but only when I sync the entire thumbs Folder on my iPhone. Which I can’t do as my thumbs Folder would be about 170GB (that’s the size of my thumbs cache in Nextcloud).

Besides, the thumbs “Cache location” is a global setting. This means each Device can only use a single thumbs cache sync Folder. This is inefficient in this scenario:

  1. Two or more users
  2. Each user has a private sync Folder (shared only with Devices owned by user)
  3. One Folder shared among all Devices
  4. Users should not have access to thumbs from private sync Folder owned by other users

When using a single thumbs folder shared by everyone, I’d violate point 4. The alternative is to create a thumbs Folder for each user, but this would duplicate all the thumbs for the shared folder (point 3).

That’s why I think a .thumbscache directory each sync Folder would be better. We can be sure only devices with access to the shared Folder have access to the associated thumbs. While browsing a selectively synced Folder, Synctrain could presumably fetch the thumbs from .thumbscache in a similar way it currently fetches previews (for files smaller than 2MB). For each image to preview in a selectively synced Folder (with no files present locally), it could go like this:

if .thumbscache contains thumbnail for image
	fetch thumbnail and generate preview on demand
else if image is smaller than 2MB
	fetch original image and generate preview on demand
else
	show no preview

What do you think?

The use case for thumbnails as implemented in Synctrain is to speed up browsing folders of pictures by keeping all relevant thumbnails locally on the device, removing the need to fetch from the remote. This assumes the thumbnail folder fits on the local device.

If I understand you correctly, you propose to (also) fetch thumbnails on demand. Although this would save bandwidth and some computing power compared to just fetching the originals, I am not convinced it would be a good experience (while scrolling a list, dozens of requests would be fired for small files, and latency over i.e. a mobile connection is not that good).

(Note that the current logic, when ‘cache thumbnails on disk’ is enabled, to: (1) use the locally stored thumbnail image if it exists, (2) if file is smaller than x MB, fetch original, generate thumbnail and save to thumbnails folder).

I agree having a global cache directory setting is not ideal - I think it is a good idea to allow setting (or overriding the global setting) at the folder level. Perhaps additionally, adding a setting to choose a lower thumbnail quality might help?

Yes, but of course only the first time. These thumbnails could be cached locally (or perhaps even un-ignored) after fetching/syncing them on demand. Seems like a good option for folders so big that the full thumbnail cache won’t fit on the local storage.

Interesting! My proposal would be to pre-generate thumbnails so that “(2) if file is smaller than x MB” is basically always true and Synctrain can fetch this one instead of the original (and cache this substitute locally for subsequent folder listings). If that makes sense. :sweat_smile:

Hm, I think what you are proposing is exactly the current behavior (when thumbnail cache is enabled, and with the ‘maximum size for preview’ setting set to a high value). Synctrain in that scenario should already do the following whenever it needs a thumbnail:

  1. If there is a thumbnail in memory cache, use that (about ±100 images are kept in memory to facilitate quick scrolling)
  2. If there is a thumbnail in the local disk cache, use that
  3. If the file is available locally, generate a thumbnail from that and place in disk+memory cache, and use that.
  4. If the file is available remotely, fetch and generate a thumbnail from that, and place in disk+memory cache, and use that.

Disk cache can be either a (shared) folder, or the iOS designated ‘Caches’ folder for the app. The latter will be automatically emptied by iOS whenever the system needs more disk space, the former will not (but you can remove files from it, Synctrain will simply start filling it again).

If you select ‘generate thumbnails’ in the app for a folder, it will basically do the above process for each and every file in the folder (except the size limit is not observed). This is fastest if you do it on a device that has all the files locally (and you use a shared cache folder), but it can be done remotely, and it can be done just as well for the iOS-managed local-only cache folder.

I tried your suggestion to increase the ‘maximum size for preview’. It’s pretty cool that this way I can see thumbs of a folder of about 300 .CR3 Canon RAW images on my iPhone, on demand, while within my LAN on WiFi! Unfortunately the app crashed while scrolling through the file list. But more importantly I won’t be able to quickly preview this directory when on a 4G connection. Which is why I’d like to preprocess them for faster on-demand preview.

In my mind it would be an improvement to add an additional step in between the last two.

  1. If there is a thumbnail in memory cache, use that (about ±100 images are kept in memory to facilitate quick scrolling)
  2. If there is a thumbnail in the local disk cache, use that
  3. If the file is available locally, generate a thumbnail from that and place in disk+memory cache, and use that.
  4. If there is a thumbnail in the local disk cache, and the local disk cache is a selectively synced folder, fetch it and place in disk+memory cache, and use that.
  5. If the file is available remotely, fetch and generate a thumbnail from that, and place in disk+memory cache, and use that.

Nextcloud takes this approach. It preprocess images to generate thumbnails. When scrolling through the folders in the iOS App thumbnails are fetched on demand and show quickly. Close and re-open the app, thumbnails are cached locally and show immediately. Without pre-processing the app would have to fetch the original images on demand, which is not feasible.

P.S. I noticed no thumbnail is generated for images > 2MB, even after having manually viewed the full-res image. Going back to the file list it still doesn’t have a thumbnail. Would be an opportunity to fill the local thumbs cache :slight_smile:

Hm, the app shouldn’t crash - given you are previewing large RAW files I assume this is some kind of memory limit thing. Please run the TestFlight build and be sure to send the crash report whenever it occurs. This way I can see what’s going wrong.

The app currently doesn’t generate thumbnails for files on viewing, because that (depending on the file type) could require two requests for the file (one from e.g. web view or video streamer and one from the thumbnail generator) which may be undesirable (when e.g. on rated connections).

I will consider on-demand thumbnail downloading from a (shared) thumbnail folder.

1 Like

Hi @pixelspark,

I was reading a bit on your vision for this app and was looking to step over from Mobius, but I can’t seem to find any info on syncing my folder outside of the sandbox folder of Synctrain. Mainly, I wanted to sync my Obsidian notes.

I searched online and this forum topic, but could only find one response by you in september 2024 that the feature was already in TestFlight. Is it already on production, or is it still in development?

Thanks for this great app, ui is already way more friendly.