This is a continuation of Deleted triggers keep coming back since my follow-up no longer concerns the original topic. Note that I'm not allowed to post more than 3 links at once, so I'll just change the others to hxtps://.
The relevant part of the last message in that thread (@Andreas_Hegenberg):
Unfortunately I currently don’t think I‘ll add other sync options. (You could script preset import and export to some Dropbox folder, but this won’t handle the many edge cases)
Could you expand on those edge cases? I actually only need to overwrite the config (meaning global settings and presets) in one direction at a time, as changes are never made to both sides simultaneously. It's also not like I'm making dozens of changes every day. I do use some custom WebViews, but I'm already syncing the underlying HTML/JS in a different way (outside of BTT entirely), as the contents are slightly different for every device. The HTML inside BTT itself is just some inline JS to get the current homedir and redirect to the main HTML for the WebView, so that will work on any device regardless.
I also found something else that might be interesting, which could allow for signing in to an Apple account specifically for BTT only while still using CloudKit:
Some database operations require that users sign in using their Apple ID. Your web app will need to handle these authentication errors and present the user with a dialog to sign in. Apple will present the actual sign-in page through a redirect URL so that the user’s credentials remain confidential. If the user chooses to sign in, the response contains a web authentication token that you use in the subpath of subsequent requests.
While the URL contains archive, it seems the API is actually still supported even by the native framework. For the sign-in you could just let macOS open the default browser with Apple's redirect URL, which is also how it worked for the old Dropbox sync. It would even still be possible to use the private DB (hxtps://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/ModifyRecords.html).
hxtps://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/SettingUpWebServices.html#//apple_ref/doc/uid/TP40015240-CH24-SW11 mentions the token rotation and expiration:
Each token is intended for a single round trip to the server. Whenever a token is sent to the server, a new token is provided in the response from the server. Once the response is received, the previous token is no longer valid. It must be discarded and the new, returned token used in the next request.
By default, the web authentication token expires 30 minutes after it is created. If the user selects “Keep me signed in” during the sign-in window, the duration of the token is 2 weeks.
There really wouldn't be any reason not to use Keep me signed in, so 2 weeks should be more than enough to check the CloudKit DB even only once (the docs seem to suggest every new token has a fresh 2 weeks). And if it does expire then BTT would simply show the login page again, which isn't much different from the Dropbox sync either. That would be more than acceptable for being able to sync without system-level iCloud.
It is HTTP-based instead of using a fully native framework, but the iCloud feature description within BTT states that it uses preset-level snapshots, which should still be possible without adding a lot of needless complexity. Perhaps even better: BTT could implement only the HTTP backend for the actual storage, and when someone is using system iCloud it could just use a CKFetchWebAuthTokenOperation to get a compatible token via the framework, then transition to HTTP for the rest.