Solar Punk
Own first, pay when it counts: onboarding, hosting, and sharing for Swarm Desktop
Swarm Desktop asks new users for money before they own anything, hides the network's best trick — that any folder can be a website — behind raw hashes, and has no honest sharing verb at all.
This project redesigns those three journeys as one mechanism, built on a fact the product already has: your identity key is free and portable; only storage costs money, and it costs money by the calendar.
Every screen is designed to leave the user believing true things about their own data — what is public, until when, and what cannot be undone.
Executive summary
A product spec is a mechanism: the behavior it actually produces is its equilibrium, and if the behavior we want is not the user's natural move, they will deviate — quit at the money wall, publish something they thought they could take back, or trust a backup that only saved half their keys. So we redesign the payoffs and the information, not just the screens. Onboarding: create and back up the free identity first, use the app free, and meet the funding step only when a chosen upload makes it worth paying — quoted as a date, delivering both tokens in one step. Hosting: a Publish button on any folder makes a deliberate public copy with a stable address that survives every edit. Sharing: two plainly named verbs — hand a key to named people, or make a public copy — with the one-way doors stated before the click, and one panel that always answers "who can see what."
Select any line to jump to the section that develops it.
00The problem
Three failures, one root. New users hit a token-acquisition wall before the app has given them anything — so quitting is the rational move. The Files tab can technically publish a website, but it speaks in raw hashes next to a File Manager that speaks in names — two mental models, and the friendly one lacks the public path. And sharing barely exists as an action, even though the protocol underneath is precisely a sharing machine: per-person encrypted grants on one side, public references on the other.
The root: the product hides its own best structure. The identity key that makes files yours is free and works on any machine. Only storage costs money, and it costs money by the calendar. Public content is a copy into a commons that no one — including us — can pull back. Designed around instead of hidden, each of these becomes a feature.
01The method
We treat the specification as a mechanism, following the marketplace canvas:
A mechanism's equilibrium is the behavior the product actually produces. So every flow below is checked twice: is the desired action the user's easiest and most rewarding move at each step? And does the user walk away believing true things — about what is public, what is backed up, what expires when, and what cannot be undone? A design that produces the right clicks but the wrong beliefs has only postponed its failure.
02Actors, interactions, incentives
Five actors, and only one of them is a person sitting at this app. The owner holds the identity key and makes every real decision. The node is not a decision-maker at all — it is the owner's payment engine, buying dated storage time on command. A named recipient holds a wrapped key the owner handed them. A public visitor holds nothing but a link. And the commons — the network itself — is where all content actually lives, belonging to no one. A mechanism works when each arrow below is worth following for the actor at its tail, given only the information the product shows them.
The table below is the incentive audit: for each actor, what they do, why doing it beats not doing it, and what the product must tell them at the moment of decision. If any row's "why it's worth it" fails, that actor deviates — and the mechanism, not the actor, is at fault.
| Actor | What they do | Why it's worth it | What they must be told, and when |
|---|---|---|---|
| Owner, arriving | Creates an identity, backs it up, tries the app | Ownership and reading are free; every step gives more than it asks, so continuing always beats quitting | What the key is (one sentence), what the backup protects — before anything else |
| Owner, storing | Funds the node at their first upload | The cost buys a concrete, dated thing they just chose; both tokens arrive in one step, so the path has no hidden dead end | "This much data, kept until ~this date, if top-ups continue" — at the moment of the upload, not at the front door |
| Owner, publishing | Turns a folder into a website | One verb on files they already organize; the link survives every edit, so it is worth giving out | Public copy · kept until ~date · unpublish removes the pointer, not the copy — before the click |
| Owner, sharing | Hands a key, or makes a public copy | The private verb is the easiest verb, so the safe act is also the low-friction act | Forward-only revocation (private) or non-recallable copy (open) — before the grant, never after |
| Named recipient | Opens what was shared with them | One link simply opens, from any machine — no protocol lesson, no setup ceremony | Who shared it and what "you can open this" means; if they lack an identity, a one-time creation step with a plain reason |
| Public visitor | Reads a site or an open share | Zero setup: the link is enough, through any gateway | Nothing — needing to tell a visitor anything would itself be a design failure |
| The node | Pays gas, buys batches, signs stamps | Structural role, not a choice — it acts when the owner commands and never decides | Nothing; but the owner must always see what it paid for, until when, and from which wallet |
Two interactions deserve their own line because they are where trust is won or lost. Owner → node is the only place money moves, so it is the only place quotes and dates are mandatory — a funding step without a kept-until date is a rule violation, not a style choice. Owner → anyone else is the only place exposure is created, so it is the only place one-way facts must precede the click — and the single review panel exists so the owner can afterwards enumerate every arrow of this kind they have ever drawn.
03Onboarding: own first, pay when it counts
The identity key costs nothing and is the user's one portable asset — so it comes first, with its backup, before money is ever mentioned. Reading the network is free at the protocol level — so the unfunded app is a working reader, not a locked demo. The funding step waits for the first upload the user actually chooses, and then it quotes a calendar, not tokens: "keep 2 GB for 12 months — until about July 2027." One in-app step delivers both required tokens, so the classic dead end — a wallet holding one token and not the other — never happens.
- Two keys, two backups. The identity key and the payment wallet are backed up separately, each at the moment it first protects something. No screen ever says a bare "backed up" while only one is safe — that false belief is the most dangerous thing this product could manufacture.
- Every promise carries a date. Never "saved" — always "kept until about this date, if top-ups continue," with early warnings and a one-tap top-up.
- Portability is rehearsed. A short drill re-reads the user's catalog from the network with nothing but their key, turning "your files outlive this machine" from a slogan into something they have personally watched happen.
04Hosting: publish a folder you already have
Hosting stops being a separate raw-hash workflow and becomes one verb on the File Manager. Select a folder with a start page, press Publish. The app makes a deliberate public copy of it in the commons and wires a stable address — a pointer owned by the user's own key — so the link survives every edit. Editing the folder offers an update; version history gains a rollback; and because the address belongs to the identity key, the website itself is as portable as everything else the user owns.
05Sharing: two honest verbs
Every file gets one Share entry with two choices, named by their consequences. Hand a key to named people: the lock stays on, each person gets their own wrapped key, and the recipient receives one link that simply opens — from any machine. Make a public copy: the same gate as publishing, because it is the same door. The limits are said before the click: cutting someone off stops future versions but cannot un-read the past; a public copy cannot be recalled at all.
06The honesty rules
A short list of rules every surface obeys. Each one exists to prevent a specific false belief.
| Rule | Prevents the false belief |
|---|---|
| Identity before money | "This app wants my money before giving me anything" — and the quitting it causes. |
| Every promise carries a date | "Saved means forever." Storage is a subscription; the date is always visible, warnings come early. |
| Two backups, never one word | "I backed up" — when only one of two unrelated keys is safe. |
| Unpublish is not delete | "I can take it back." Removing the pointer never recalls a public copy, and the app says so first. |
| Revocation is forward-only, said at grant time | "Removing someone un-shares the past." It only protects the future. |
| One panel answers "who can see what" | "I probably haven't shared anything sensitive" — hope where a checkable list should be. |
| Friction follows irreversibility | "Warnings are wallpaper." Reversible acts are one click; only true one-way doors get a gate, so the gate still means something. |
| Portability is rehearsed, not promised | "My files are probably safe somewhere" — replaced by a recovery the user has personally watched succeed. |
Everything above is specified in full — actors, flows, locked records, eight rule contracts with acceptance criteria, and a risk register keyed to belief distortions — in the companion canvas document. Each contract passes the strategy's leak test, so the same rules serve the File Manager wherever it is embedded, not only inside Swarm Desktop.