Publishing the Fallback Code
In Section 8 of the Terms of Service, titled "Designed on Trust," I published the code to check credit balances, view token history, and rewrite them. A service that promises to preserve data for a thousand years must not assume its own servers will survive that long. Even after the servers are gone, users should be able to inspect their data and, if necessary, correct it. That is the minimum honesty a permanence-oriented service owes its users.
The code is written in JavaScript. Paste it into the browser's developer console and it runs. It reads, displays, and rewrites credit balances and token history stored in localStorage. Technically, there is nothing complex about it. Rather, it is the natural consequence of transparency in a design that places no server-side authentication.
The Console Is Unreachable
The problem became obvious almost immediately. TokiQR is installed as a PWA. When launched in standalone mode, the browser's developer tools cannot be opened. There is no address bar, no menu, no way to reach the Console.
Consider a disaster scenario. You have only a smartphone. There is no PC for remote debugging. The network may be severed entirely. The fallback code is unreachable in the very situation that demands fallback. The means exist, but the path to them is blocked.
Building a Recovery Console
The answer was straightforward. If developer tools are unavailable, build a console inside the app. A textarea, an eval button, an output area. Zero external libraries. A 150-line recovery console, embedded in the settings page.
Users open the settings page, expand the recovery console section, paste the code from the Terms of Service, and execute it. It works in PWA standalone mode, offline, in any environment. A browser is all it needs.
The Link Rendered as Plain Text
I included a link to the settings page in the instructions for the recovery console. Section 8 of the Terms of Service read "Use the recovery console on the settings page," with an embedded hyperlink. But what appeared on screen was not a clickable link. The raw HTML tag was displayed as a string.
<a href="settings.html">Settings</a> rendered verbatim. The text had been injected via textContent, which does not parse HTML. Tags within the string are drawn as literal text. Switching to innerHTML resolved it.
Visible Only to Humans
Right after fixing the bug, something struck me. The fallback code in the Terms of Service does not exist in the HTML source. For i18n support, all text is rendered dynamically by JavaScript. The HTML elements remain empty; JS injects the text after the page loads.
This means that crawlers and AI fetchers retrieving the HTML see nothing. Static analysis of the source reveals only empty elements. The code appears solely for a browser executing JavaScript—that is, for a human who has opened the page themselves.
The fallback code appears only when a human opens the page in a browser.
Three Layers
Looking back, the design of trust had three layers.
- Layer One: Data never leaves the browser—All data stays within the user's browser. The server has no means of accessing it. The layer of privacy.
- Layer Two: The modification code is published—The code to rewrite credit balances is documented in the Terms of Service. Rather than making tampering impossible, the method of tampering is disclosed. The layer of transparency.
- Layer Three: Visible only to humans—Due to JS rendering, the fallback code is displayed only to humans who open the page in a browser. Crawlers see nothing but empty elements. The layer of unintended coherence.
Layer Three was never intended at design time. It emerged as a byproduct of choosing JS rendering for i18n. A pragmatic decision for multilingual support had, as it turned out, produced a structure where the code reaches only those who need it.
A Service Activated by Trust
Design based on trust did not stop at data recovery. The Pearl Soap Ambassador program—a service worth ¥55,000—can be activated by executing a few lines of JavaScript in the console. There is no server-side authentication. No payment verification. A single line of JSON written to the browser's localStorage starts the entire service.
The activation code is published in Section 8 of the Terms of Service. It is open to everyone. Anyone can read it. Anyone can execute it. There are no technical gates whatsoever. Yet “accessible to all” is not the same as “used by all.” Because the path is open, the decision to walk it becomes a matter of personal judgment. This is not a gate that only the qualified may pass through. It is a road open to everyone, where each person chooses for themselves whether to step forward.
Wise was chosen as the payment method. Opening a Wise account is itself a form of peacetime preparedness—there is no need to build international transfer infrastructure from scratch when disaster strikes. Try it when you have funds on hand, at a timing that suits you. Moreover, a gratitude payment is sent in return, so there is no financial risk. An open road you can walk at your own pace, with zero risk. Preparedness and experience converge.
Even if the power grid goes down, financial systems can be restored with a solar panel and satellite communication. Infrastructure is a chain. When power stops, communication stops; when communication stops, payments stop. That cascade threatens daily life. But if each layer has an alternative, a failure at any single point remains contained. Opening a Wise account in peacetime is nothing other than holding an alternative at the financial layer. Resilience does not mean never breaking—it means being able to rebuild when something does.
That is precisely why, during peacetime, the normal payment flow through the credits page is the path to take. Power is on, communication is up, payments go through. The very fact that this normalcy holds becomes something to be grateful for. It is because the fallback exists that the privilege of walking the peacetime path becomes visible. Preparedness for emergencies and gratitude in peacetime—the two coexist within the same design.
At the same time, this is a tangible experience of thousand-year sustainability. Activation without server dependency runs under the same conditions as a world a thousand years from now. Published alongside the fallback code, through the same means, both recovery and activation complete with nothing more than a browser. Permanence is not an abstract concept—it already exists as a mechanism working in your hands right now.
Lay an open road for everyone, and leave the choice to each individual. That is the structure of trust.
Where Precedent Ends
Commercial services built on trust do exist. But none go this far.
The closest in spirit is GOG.com. As a DRM-free game store, it sells games with no copy protection whatsoever. Its stated position: "People who want pirated copies will get them regardless. Rather than inconveniencing legitimate users, build trust." Yet GOG's stance is "we do not restrict"—it does not go so far as to publish the bypass method for users.
The shareware culture of the 1990s operated on an honor system—"try it, pay if you like it"—but that was partly driven by the practical constraints of distribution, not a deliberately articulated philosophy. Radiohead's "In Rainbows" (2007) was a pay-what-you-want experiment rooted in trust, but it was largely a one-time marketing exercise. itch.io lets developers set their own prices and allows users to pay above the asking price, but it does not document bypass methods in its terms of service.
The uniqueness, then, lies not in the philosophy of trust-based design itself, but in how far it is carried out. Documenting the tampering method—source code and all—in the terms of service. Intentionally publishing the HMAC key. Designing on the premise that the company itself will cease to exist. Justifying all of this under a philosophy of "a thousand-year relationship of trust." No commercial service I could find combines all of these.
The philosophy of trust is not rare. What is rare is following it all the way through.
What Trust Means
Not binding through technology, but stating what is possible and then choosing to believe. Publishing the HMAC key in the source code. Not making tampering impossible, but assuming that tampering is possible, and still choosing a relationship where it does not happen.
This is not naive optimism. Naive optimism assumes that people are inherently good. Design based on trust makes no assumption about good or evil. It discloses the means, delegates the choice, and accepts the outcome. Because we chose not to surveil, we ask for trust.
A Thousand-Year Horizon
Servers will vanish. Companies will dissolve. Laws will change. Domains will expire, APIs will be deprecated, authentication systems will leave no trace. What remains is the code, the browser, and the human who opens it.
To design on trust is to write for that last person. A thousand years from now, when someone discovers this code, they will need no server to query, no authentication to pass. They will simply open a browser, and everything will work. That is what permanence means. That is what trust means.
The code, the browser, and the human who opens it. Design on trust writes a world that is complete with just these three.