u/rfrancocantero

Like a lot of people here I back up my Proton Drive from a headless Linux server (restic, nightly) to whatever, Synology, pCloud, you name it.

The usual route is rclone's protondrive backend, and like others here I watched it get slower and slower until a flat folder with 785 photos took 160 seconds to list on a good day and never finished on a bad one. Six-hour hangs, dead mount points. The throttling is pattern-based: rclone walks the whole tree with thousands of metadata calls every night, and Proton's API understandably stops picking up. The part that surprised me: the official Drive SDK (github.com/ProtonDriveApps/sdk, MIT) is already good enough to fix this yourself. I built a small read-only gateway with it:

- metadata lives in a local SQLite cache, kept fresh through the SDK's event stream (the same mechanism the official apps use, polled once a minute)

- the tree is exposed as WebDAV on localhost, so restic reads it through a boring rclone webdav mount

- file contents are never stored, just streamed on demand, decrypted and integrity-verified by the SDK

Results on the same account that was being throttled: that 785-file folder lists in 0.106 seconds. First full snapshot (3,069 files, 42 GiB) took 22 minutes.

The nightly incremental run now takes 0.82 seconds and makes zero calls to Proton unless something actually changed. Restore came back bit-for-bit identical. It follows the SDK rules: identifies as external-drive-*, event-based, no recursive scans, personal use only (which the license explicitly allows). It can't write anything, so the worst it can do to your Drive is read it well 😊

Two things I ran into that might interest the Proton devs if they're reading: the incubating account package isn't on npm yet (vendoring works fine), and getSeekableStream() deadlocks under parallel load (32 of 70 concurrent ranged reads hung, reproducible; the regular download path is rock solid). Happy to file a proper issue with details.

Full write-up with all source code (free to reuse for personal setups): Medium (free) article

Not affiliated with Proton, just a subscriber who wanted his 3 a.m. backups back, and if the native Linux client lands before you build this, even better. That's the outcome I'm actually rooting for.

I'm building a self-hosted personal assistant (just for me, no commercial intent) and I'd love to pull workout, sleep, HRV, and step data from my Suunto Vertical 2 into it.


Reading Suunto's developer docs carefully, they're explicit: 
*"We currently don't offer the API access for personal use"*
 — only to companies/organizations with apps for a public audience. So my use case (one user, me) wouldn't pass their partner review.


What I've already considered:


- 
**Strava relay**
: works for workouts since Suunto auto-syncs there, but loses sleep/recovery/HRV
- 
**Apple HealthKit via iOS Shortcuts**
: workable for some data, awkward to maintain, and not everything in HealthKit comes through cleanly
- 
**Manual FIT export**
: kills the automation point
- 
**Partner program**
: explicitly excludes personal use


Curious if anyone here has:


- Gotten API access for a hobby/personal project (pitched it differently? framed it as something more?)
- Found an unofficial route I'm missing (local sync data on phone or desktop maybe?)
- Built a workaround they'd recommend
- Other ideas I haven't thought of


Not trying to break ToS — happy to apply through the proper channel if there's a realistic way. Just trying to gauge whether it's worth the effort or if I should commit to the Strava + HealthKit combo and accept the data gaps.


Any advice appreciated.

Hi,

I have an iPhone with dual sim (work and private). Would it be possible to only let the Vertical 2 pass (ring) notifications for the private sim?