Why every app you open still has to interview you — and what a second permission layer might fix
Part 1 of 2 on Context Auth, an experiment I've been building.
A small annoyance that turns out to be structural
You sign up for something new. Before it does anything useful, it interviews you.
What's your role? How technical are you? How do you like answers formatted? What are you working on right now?
You answer. Six questions, maybe ten. The app thanks you and finally lets you in. And somewhere in the back of your mind is the thought that you've answered these exact questions before — in the last tool, and the one before that, and in a settings page you've since forgotten about.
I started calling this the cold start tax, because both sides pay it.
You pay in repeated effort, and in the low-grade irritation of explaining yourself to software that has no memory of you. Many people avoid the immediate cost by skipping the wizard, clicking through, and accepting a generic experience instead.
The product pays too, and more than it realizes. The day-one experience is generic for everyone who skipped onboarding. Personalization then has to be reconstructed gradually from behavior, and some users leave before the product learns enough to become useful.
The tax is small each time. It's structural in aggregate.
Identity became portable. Context didn't.
Here's what makes this strange: we already made the harder-sounding half of this problem portable.
"Sign in with Google" made identity portable. An app knows your name, your email, and that you control an account authenticated by Google, on day one, without you typing anything. That was a genuinely hard coordination problem — and it's now so universal that a signup form without it feels broken.
But identity answers exactly one question: who are you. It says nothing about the question that actually determines whether the software is any good: how should it treat you.
Those are different kinds of data, and they deserve different treatment:
- Identity is a fact about you. It's stable, it's verifiable, and it mostly doesn't change.
- Context is an instruction about you. It's a preference, a constraint, a current goal. It changes. It's situational. You might want one app to have it and another absolutely not.
An email address is the same email address everywhere. But "I want blunt answers with no preamble" is something I'd happily hand to a coding assistant and would find intrusive coming from a shopping site. Context needs a permission model that identity never did.
That gap is the whole thing I've been building against.
What I mean by "context," precisely
This word is doing a lot of work right now, so let me narrow it hard.
Context here is not your chat history. It's not a transcript archive, not a memory graph, not everything-you've-ever-said stuffed into a retrieval index. It is a small set of named, structured, plain-English facts that change how software should behave:
- your role, your years of experience, the domains you actually work in
- the tone and format you want answers in — and what you'd rather never read again
- what you're currently working toward
- how you prefer to learn something new
- your dietary preferences and ingredients you prefer to avoid
- what makes an interface usable for you
Four properties matter, and each one is a deliberate constraint:
Named. Each fact belongs to a scope with a stable name, so an app can ask for that one thing and nothing else.
Structured. An app receives values it can use directly, not a paragraph it has to interpret. "Tone: direct" is usable. "The user seems to prefer directness" is a guess.
Small. The whole thing is closer to a page than a corpus. This is a thin, high-leverage layer — not an attempt to hold everything about you.
Reviewed. A human looked at every entry and said yes. Nothing arrives implicitly.
The unit is the scope, not the profile. That distinction turns out to be the entire design. A profile is all-or-nothing, and all-or-nothing is why nobody wants to share one.
Where the context lives
If context is going to be portable, it needs a home that isn't inside any one product. That home is a user-controlled context store.
The input is material you already have lying around. An export from an assistant you already use. A résumé PDF. The archive a professional network emails you when you ask for your data. A paragraph you paste. Or a live source you connect and let stay connected.
What comes out the other side is a set of suggestions — structured, scoped, and explicitly not yet shared with anyone. You review them. You edit the ones that are close but wrong. You reject the ones you don't want to exist at all. Only what you approve becomes something an app can ever ask for.
Two things about that middle step are load-bearing:
Nothing is automatic. This is deliberately not an ambient memory that watches you and quietly accumulates. Every entry in the store is something a person looked at and accepted. That's slower. It's also the only version of this I'd personally use.
The raw material doesn't stay. The store's product is the structured, approved values — not the pile of text you fed it. What you pasted or uploaded isn't the thing being kept.
Turning messy source material into trustworthy suggestions introduces its own problems — provenance, conflicting sources, and stale information. Those implementation questions deserve a separate piece. The important constraint here is that nothing becomes shareable without your review.
The interesting part is what happens next.
The consent screen is the product
Everything above is setup. This screen is the actual bet.
An app asks for named scopes. You get a screen that shows you, before you agree:
- exactly which scopes are being requested, described in plain English rather than in permission-jargon
- the actual values that would be released — not a category name, the real content
- a checkbox per scope, so you can grant three of the four
- toggles within a scope, so you can hand over your role and years of experience while withholding the specific domains you work in
- which persona you're sharing as, because the version of you a work tool should see isn't the version a health app should
- and, when a project is involved, which project
Compare that to the consent screens we've all trained ourselves to click through. Those are a formality — a wall of permission strings standing between you and the app you already decided to install. Nobody reads them, because reading them changes nothing: it's accept-all or leave.
The bet here is simple. If you show people the real value, and let them cut the request down instead of only accepting or abandoning it, consent stops being theater. A screen where "grant three of four, and hide one field" is a normal thing to do is a screen worth reading.
And it means an app's request is a genuine ask, not a toll gate.
What this deliberately is not
Positioning discipline matters here, because every adjacent category is crowded and would set the wrong expectation:
Not an AI memory product. Memory features accumulate everything implicitly, for one assistant, invisibly. This is explicit, reviewed, small, and — the important word — cross-app.
Not a notes app. Raw text is an input, not the product. There's no document library here, and no ambition to build one.
Not a personal data vault. No aspiration to hold all your data. Just a thin layer — "how to serve this person" — made safely distributable.
Not a chatbot. There's no conversation surface at all. The apps in the demos are deliberately third parties, because the entire point is context leaving the store and going somewhere else.
Next
That's the concept: identity told apps who you are; this would tell them how to serve you — built once, granted per scope, and revocable.
Part 2 gets into what that actually looks like as a working system: the four-beat flow it borrows from a pattern every developer already ships, the vocabulary of scopes that makes granular consent possible, a second kind of subject that turned out to matter as much as people, and what happens the moment you press revoke.
Identity tells apps who you are. Context tells apps how to serve you.
Top comments (0)