Why there is no account, and what we give up for it

Not having accounts is a decision, not an unfinished feature. It costs us things people genuinely want, so it is worth setting out what those are rather than pretending the trade is free.

What accounts would give you

• An audit trail. Who shared what, when, and whether it was read. Some organisations need exactly this.
• Revocation. A dashboard of your live links, with a button to kill any of them.
• Delivery confirmation. A notification when your secret is opened.
• Recipient identity. Restricting a link so only one named person can open it.

Those are not small. If you need them, you should use a tool that has them.

What accounts would cost

The first cost is friction, and it is larger than it sounds. The realistic alternative to this service is not a competitor - it is pasting the password into the chat window. Anything that adds a signup between the person and the safe option loses to the unsafe option most of the time. A tool for sharing credentials has to be quicker than the bad habit it replaces, or it does not get used.

The second cost is the one that decided it. An account system means holding a database of who shares secrets with whom. Not the secrets - those stay encrypted - but the pattern. Which is, on reflection, an unusually sensitive thing to accumulate: a map of trust relationships, credential rotation timing and who talks to which vendor.

That database would be worth attacking, would have to be defended, would need a retention policy, would be subject to disclosure requests, and would be the single most damaging thing we could lose. Right now it does not exist. That is not a control we implemented well; it is a category of risk we do not have.

What we do instead

Every feature an account would have provided has a smaller, stateless version:

• Revocation becomes the view limit and the clock. You decide up front instead of intervening later, and the recipient gets a delete button.
• Delivery confirmation becomes the burn itself. If the recipient reports it already viewed and it was not them, something is wrong - which is arguably more useful than a read receipt.
• Recipient identity becomes the passphrase. Not "only Alice can open this", but "only someone who also has the phrase", which is the part that was doing the work anyway.

Who this is wrong for

If you are under an obligation to produce an audit trail of credential access, this tool cannot help you, and no amount of configuration will change that. The absence of records is the product. Use something built for that requirement, and use it for those secrets.

For everything else - the API key a contractor needs today, the password for the account you are handing over, the recovery code that should not live in a thread forever - not having an account is the feature.