The hard parts

Eight problems stay hard however good the tools get, and every BSV product meets some of them. This page states each one before answering it: what makes it hard, what people ask, and what you have to decide. The pages linked under each one give the answers this guide has so far.

The payment being final is the feature

Once a payment is accepted, nobody can reverse it: not the sender, not the wallet, not the app. The review screen is the last moment anything can be put right, and the person is usually in a hurry when they reach it.

What people ask

• "Can I get it back?"
• "Did it actually go?"
• "What if I typed it wrong?"

What you have to decide

• What must be on the review screen, and what can wait for the details?
• When is a small test payment worth suggesting?
• What do you say when a payment went somewhere the person did not mean?

Answered in: Sending, Errors and failed payments, Wrong-network payments, Paying by handle.

The person holds the keys

The keys belong to the person, and nobody else holds a copy. There is no support desk that can reset them, so losing them can mean losing the money for good.

What people ask

• "What happens if I lose my phone?"
• "Who do I call if I forget?"
• "Can my family get to this if something happens to me?"

What you have to decide

• How much responsibility can this person carry, and how do you find out?
• Which recovery scheme fits the amount at stake?
• When do you ask them to set up recovery: before the first payment, or after?

Answered in: Private key management, Recovery, Time-based recovery, Inheritance wallet.

A backup is two halves

A complete backup has two parts. The recovery words restore the keys. The wallet backup restores the records: which money is the person's and how to spend it. Losing either can lose money, and some people believe a list of words is the whole job.

What people ask

• "I wrote the words down. Why do I need anything else?"
• "Is my backup up to date?"
• "Will this work in a different wallet?"

What you have to decide

• How do you explain two halves in two lines?
• How often do the records get backed up, and where?
• How does the person find out, months later, that the backup still works?

Answered in: Backups, Backup and recovery, Spending conditions (the configuration is part of the backup).

Apps ask a wallet

An app never holds the person's keys. It asks their wallet to pay, sign or prove something, and the wallet asks them. So connecting is a conversation about permission, and every later request depends on the first one going well.

What people ask

• "What can this app do with my money?"
• "Why does it want that?"
• "How do I stop it?"

What you have to decide

• What is the least the app needs to ask for on day one?
• When do you ask for more, and how is the request worded?
• Where does the person go to see and take back what they granted?

Answered in: Connecting a wallet, Permissions and allowances, Holding tokens (asking for one basket rather than the wallet).

Many very small payments

A payment of a few satoshis is practical, so a product can charge per article, per request or per second. Then a person makes hundreds of payments and cannot be asked about each one.

What people ask

• "How much have I spent today?"
• "Why are there so many payments?"
• "Can I set a limit?"

What you have to decide

• Pay per use, an allowance, or a running meter?
• How do you show four hundred payments as something a person can read?
• What happens when one payment in a hundred fails?

Answered in: Charging per use, Amounts and units, Activity.

Data on the chain is permanent

Anything written to the chain stays there and can be read by anyone. Nobody can delete or edit it, including the person who wrote it, and a button labelled "Save" does not tell them that.

What people ask

• "Who can see this?"
• "Can I take it down later?"
• "What if I got it wrong?"

What you have to decide

• Do you write a fingerprint of the data, or the data itself?
• What exactly does the person agree to, and when?
• How do you correct a record that can never be edited?

Answered in: Storing data on chain, Wallet privacy.

Software spending on somebody's behalf

An agent spends without asking each time, so the person is not there when the money moves. They arrive afterwards, and have to judge spending they did not decide.

What people ask

• "What did it buy, and why?"
• "Can it spend more than I gave it?"
• "How do I stop it right now?"

What you have to decide

• Which limits does the agent get: balance, rate, who it may pay, and for how long?
• What needs a person's approval, and how does that request reach them?
• How do you report its spending so somebody actually reads it?

Answered in: Letting an agent spend, Permissions and allowances, Wallet setups.

Identity without accounts

A person signs in with their wallet. The app gets a key made for it, and only the facts the person agrees to reveal, such as a Pass showing they are over eighteen. Nothing about that is the app's to reset or recover.

What people ask

• "Do I need to make an account?"
• "What does this site learn about me?"
• "How do I sign in on my other device?"

What you have to decide

• Which identity do you remember the person by, and what happens if they bring a different one?
• What is the single fact you need, and how do you ask for only that?
• What does somebody see when they come back on a new device?

Answered in: Signing in, Identity.

Try them

Most of these problems have a take-home exercise in Design challenges, four to six hours each. A good attempt at one is a contribution to this guide, not only an exercise.

Related

• Getting started
• Why design for BSV: what the work is like
• Patterns: what to design, by task
• Design challenges