This is a bit of an edge case for people with destinations they can control, however I agree it would be nice. There was a comment a while ago about possibly saving some of the local database content out to the destination.
If that “remote database content” included flagged-for-deletion items then destination compacting becomes much more likely, HOWEVER - there’s still a lot of work involved with coordinating.
For example, what if the destination is compacting when the source decides to ALSO compact? Just starting a source backup while a destination compact is going on could cause issues due to “missing destination files”.
Some sort of communications mechanism needs to be set up to avoid scenarios like this. I suspect it will end up be a “status / semaphore log” type file on the destination that both work-ends and check.
But even then there are still edge cases such as “Destination updated semaphore file to indicate a compact has started then crashed before flagging completion - now Source won’t run any backups because it always things a compact is running.”
Not to mention the usual (extremely unlikely) ACTUAL contention of two work-ends trying to update the status / semaphore file at the same time.
@Pectojin & @ts678 - depending on how much one chooses to trust, a “private network” such as ZeroTier could resolve (or at least centralize) a lot of the security issues. If your client and “server” are both on an encrypted ZeroTier network they can talk to each other over those IPs ‘safely’.
It potentially even solves portability issues as I believe the ZeroTier IPs are individually manageable so even if you move to a different machine you could just move the IP to the new MAC.