choose the right subscription plan for Sync and/or
prune an existing vault when the limits of a plan are reached.
I find it difficult to:
understand how the size of a remote vault can be much larger than the size of the local vault
identify what to prune, eg delete a complete remote vault or delete a local file or delete a remote file or …
identify where to prune, ie locally or remote
understand the timing of the pruning process
Proposed solution
Determine the storage limit not by the size of the remote vault, but by the size of the local vault. For example: Sync Standard could support the full synchronization of vaults that take up to 1GB on the local device (plus maybe a size limit for individual files).
a) It would make size management simpler for users:
The size of a local vault can be controlled by the user. They can easily determine in their local Obsidian app how big the vault is.
The size of a remote vault depends on factors that can not be controlled directly by the user, like the retention period of the version history and the frequency of syncing.
b) It would make it easier to understand the concept of Sync. Obsidian Sync syncs local vaults. The remote vault is just an intermediary storage and nothing that users should interact with directly.
c) It would make the pricing model easier to understand. To find the right plan, users only have to
count the local vaults that they want to sync
add up the total size of those vaults
Obsidian’s philosophy is local files first. Why not apply the same philosophy to Sync?
Yes. Under the current system users are charged for something they can’t directly control. Charging by the size of the local vault is much clearer. I don’t know what the norm is for other services, but I believe neither iCloud nor Dropbox count file versions against the storage limit.
Better pruning options, yes. Pricing based on local storage, no.
Pricing based on local storage is not the right solution for Obsidian because it goes against our goal of remaining profitable and 100% user-supported. Cloud storage used for remote vaults has a cost. The pricing model you describe is equivalent to offering unlimited storage for version history. Charging a fixed price for something that has a variable cost is dangerous.
However, I agree that it can be confusing when version history is consuming too much Sync space. There should be better options to clear up space.
What do you want users to expect from the service?
In my mind “syncing” happens in the here and now. I wouldn’t expect to have 1 year worth of version history for a sync service. In the words of the oficial help pages: “Syncing is not a backup”. I wouldn’t mind some history to recover from sync errors, but that could be automatically capped by time (“24 hours”) or storage (“5 GB”).
I wrote a feature request for an alternative scenario, where people would pay explicitly for the version history: Paid backup service - #8 by harr The primary expectation would not be the sync service, but a backup service.
The current situation is unsatisfactory, because users can’t do what they pay for (syncing), when the storage is blocked by an intransparent feature that is officially not supported (backup).