# selfstore vs remoteStorage
Source: https://selfstore.dev/compare/remotestorage

remoteStorage pioneered "the user brings their own storage" and asked them to run a server for it. selfstore keeps the idea and drops the requirement.

## 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.

Map of this site for a model: https://selfstore.dev/llms.txt
Every page in one file: https://selfstore.dev/llms-full.txt