selfstore vs remoteStorage
TL;DR: Same conviction, one decisive difference. remoteStorage needs the user to HAVE a remoteStorage account somewhere. selfstore uses storage they already have - a file on their disk, their Google Drive, a WebDAV server, an S3 bucket.
What remoteStorage is
The ancestor of this whole idea, and it deserves the credit. An open protocol from the unhosted movement: applications hold no user data, users connect a storage account they control, and the app writes into it. The library, the spec and the argument have all been public for over a decade.
Everything selfstore believes about who should hold the data, remoteStorage said first.
Why it did not take over
The gap between the idea and the world. Connecting an app required the user to already have a remoteStorage server - one they run, or one from a small set of providers. That is a reasonable ask of the people who wrote the spec and an unreasonable one of everybody else, and no amount of protocol elegance closes it. An app could not tell a normal visitor “just connect your storage”, because they did not have any.
This is the failure mode selfstore is built to avoid, and it is worth being explicit about it rather than quietly repeating it.
What selfstore does differently
The destination is something the user already owns, today, with nothing to set up:
- a file on their disk - the picker in Chromium, or a real path inside a desktop shell;
- their Google Drive - the account they already have;
- a WebDAV server - Nextcloud and friends, for the people who do run one;
- an S3-compatible bucket they control.
And the app is not asking them to trust a destination with the contents: everything that leaves the device is end-to-end encrypted, so the storage provider only ever holds opaque bytes.
| remoteStorage | selfstore | |
|---|---|---|
| The idea | The user brings their storage | The same |
| What the user needs | An RS account or server | An account or a disk they already have |
| Encryption | Not part of the default story | End-to-end, always, when it leaves |
| Protocol | Servers must implement it | None: plain files on ordinary storage |
| Portable artefact | Files in their RS tree | A spec’d encrypted ZIP |
Use remoteStorage when
- You are targeting the unhosted community specifically, and the protocol’s per-app folders and permissions are what you want.
Use selfstore when
- Your users are ordinary people, and “connect your storage” has to work for someone who has never heard the phrase.