PER-NUMBER STORAGE
A restaurant menu assigns numbers to dishes. Number 8 is the noodles with all extras. Anyone can order number 8. The restaurant does not know who you are. It knows what you want.
The web forgot this distinction.
THE CONFLATION
When the web needed personalization, it reached for identification. To remember your preferences, it remembered you. Cookies were invented. Sessions were created. Accounts were required.
The logic seemed obvious: to give you your settings, we must know who you are.
But the restaurant never needed to know who you are. It only needed to know: number 8. The dish exists independent of the customer. The customer references the dish. The dish does not reference the customer.
The web built systems where every dish was created for one person. Each user got their own menu, their own numbers, their own private kitchen. To order the pad thai, you first had to prove your identity.
This was not necessary. It was merely conventional.
THE DISTINCTION
Per-user storage maps identity to data:
user_123 → dark mode, large font
user_456 → light mode, small font
Per-number storage maps numbers to data:
42 → dark mode, large font
43 → light mode, small font
The first requires knowing who someone is. The second requires knowing what they want. These are not the same.
With per-user storage, the question is: who are you?
With per-number storage, the question is: what number?
Anyone can say "42." No one can say they are user_123 without proving it. The proof requires infrastructure: passwords, sessions, tokens, databases. The infrastructure requires maintenance: security, compliance, breach response.
The number requires nothing. It is just a number.
THE MECHANISM
Per-number storage is content-addressable. The number identifies the content, not the person.
This pattern exists elsewhere. Git commits are identified by their content. IPFS files are addressed by their hash. The identifier derives from what is inside, not who created it.
Apply this to preferences:
{dark mode, large font} → hash → 42
{dark mode, large font} → hash → 42
Same settings always produce the same number. Different users with identical preferences share the same number. The system cannot distinguish them. This is not a flaw. It is the point.
When identification is impossible, surveillance is impossible. When surveillance is impossible, privacy is guaranteed — not by policy, but by architecture.
WHY THIS WORKS
Most personalization is not personal.
Dark mode is not a secret. Font size is not confidential. Language preference is not sensitive. These are preferences, not identity. They describe what someone wants, not who someone is.
The web treated preferences as personal data because it stored them per-person. But the storage model was a choice, not a necessity. Store preferences per-number, and they are no longer personal. They are just configurations — like menu items.
A thousand users can share number 42. They all get dark mode and large font. The system cannot tell them apart. It does not try. It simply serves the configuration that 42 represents.
THE BENEFITS
Caching becomes trivial. Number 42 always returns the same response. Cache it once, serve it to everyone who asks for 42.
Sharing becomes natural. Send someone your number. They see what you see. No accounts required. No permissions to configure. The number is the access.
Privacy becomes structural. There is no user database to breach. There are no sessions to hijack. There is no personal data to subpoena. The system stores configurations, not people.
Compliance becomes simple. GDPR asks: do you process personal data? If you cannot identify individuals, the answer is no. Per-number storage does not identify. It cannot identify. The architecture precludes it.
THE OBJECTION
Someone will ask: but what if users want private settings that others cannot access?
The answer: then you need identification. Per-number storage does not apply. Use a different pattern.
But notice how rarely this is true. Most preferences are not secrets. Most personalization is not private. The web assumed everything required identity because identity was available. It never asked whether identity was necessary.
For the vast majority of "personalization" — themes, layouts, display options, view preferences — identity is unnecessary overhead. A number suffices. The number is simpler, more private, and more honest.
THE TEST
When building a feature that stores user state, ask: does this need to identify the user, or just reference a configuration?
If the state is a secret specific to one person: use identity.
If the state is a preference that could be shared: use a number.
The first requires all the machinery of accounts, authentication, and data protection. The second requires a lookup table.
Most features are the second kind. Most systems are built as the first kind. This is the gap.
THE IMPLICATION
The web assumed personalization required identification. It built accordingly: cookies, sessions, accounts, privacy policies, consent banners, breach notifications.
Per-number storage suggests an alternative: personalization without identification. Configurations without customers. Preferences without people.
The menu exists. The dishes have numbers. Anyone can order. No one is tracked.
This is not a new technology. It is an old idea that the web forgot: you can give people what they want without knowing who they are.
---
Lingenic LLC
2026