An illustrated guide to TEPP Zeta
TEPP
Trust Extended Permissions Protocol
A home, not a prison.
How guardians can bound a person's world on Nostr — people, places and things — while that person's own software enforces the rules, explains every decision, and changes who governs only with their signature.
How to use this slideshow
Part I (slides 1–16) is the big picture, for anyone. Part II (from slide 17) is mid-technical: the event kinds, the evaluation steps, private messages, and how the engine keeps its state.
Keys: → ← to move, C contents, N opens every “more detail”
panel, M switches between page-by-page and one long page, F full screen. Every
diagram has a zoom button. Identifiers such as IN-005 point into the TEPP Zeta specification.
Where we start
Nostr is open by design
- Everyone holds their own key and signs their own events.
- Relays are plain servers that store events and pass them on — plural and interchangeable.
- Anyone can publish, and anyone can reach anyone. No platform decides.
That openness is the point. But for a child — or anyone who wants a curated corner of the network — it needs a frame they can live in.
TEPP builds permissioned environments out of permissionless parts: no new server, no special relay — just Nostr events and the subject's own software.
More detail
The motivating case is parents and a child, but the machinery is general: any set of guardians can bound any subject that consents to be bound. Policy is ordinary Nostr events; enforcement happens in the subject's own signer and client.
TERM-001 · TERM-002 · TERM-020 · NF-094
The idea
Guardians publish policy that bounds a subject's world along three axes — people, places and things. The subject's own engine assembles it and answers two questions, each with a verdict and a trace.
May this arriving event reach the subject?
Input — reading.
May the subject sign this event?
Output — acting.
More detail
The subject is the identity being guided — a child's key, say. The guardians are the
keys the subject names. The construct is the merged permission state the engine assembles
from their policy. Every answer is permit or deny, with a trace naming what
decided it.
TERM-001 · TERM-002 · TERM-005 · TRACE-005 · TRACE-006
The cast
Who is who
The subject
The identity being guided. Its own TEPP software — a signer, a client — enforces the rules on its own devices.
Guardians
Named by the subject. Each writes and edits their own policy: one guardian's grant is enough to admit, one guardian's deny is enough to block.
Curators and peers
Anyone whose published grants a household chooses to adopt — a school, a helpline directory, another family.
Relays
Where everything lives. A relay never enforces a subject's rules — though it may run rules of its own, for its own space.
The engine
The subject's own. It assembles the policy, answers the two questions and explains every answer.
Profile authors
Anyone may publish a reusable rule set — a school-night curfew, say. It binds nobody until a guardian adopts it.
More detail
Guardians compose 1-of-N: any guardian's grant admits on its own, and the deny gates of all guardians add up. Nothing needs the concurrence of another guardian — the one instrument that crosses between guardians is the deny.
CONS-001 · CONS-003 · NF-039 · NF-094 · LOCI-030 · PROF-001 · PROF-006
TEPP at a glance
Who writes policy, where it lives, where it is enforced.
The vocabulary
People, places and things
People
npub
Who may reach the subject — and whom the subject may address.
Places
relay
Where events may come from — and where the subject's own may be hosted.
Things
event
A particular event, by its id — a post the subject may see, or answer.
view
May reach the subject: reading.
interact
May also be acted on: tagged, answered, messaged privately.
extend
Its members are sources: the grants they publish — or, for a peer, the grants made to it — flow in.
Diagram 02 lays out all eight categories. Open it →
More detail
The eight categories are interact/npub, view/npub, interact/relay,
view/relay, interact/event, view/event, extend/npub and
extend/relay. There is no extend/event: an event is not a party, so it cannot
be a source.
TERM-007 · TERM-008 · POL-025–POL-033 · NF-015
Narrowing
Rules that narrow, and nevers that hold
Restrictions
Allow or deny by kind of event, weekday, time of day, direction — reading or signing — and whether it is encrypted.
On one grant they narrow that grant. In the subject-wide global set they gate the subject as a whole, guardians included.
Deny gates
People, events and relays that are out, full stop.
A deny over-rules every grant, from any guardian, wherever the engine meets it, in both directions.
Profiles
Reusable, public rule sets anyone may publish — a school-night curfew, no long-form posting.
They bind nobody until a guardian adopts one, and can never admit anyone.
More detail
A guardian's “never” is a deny. Leaving something out of a whitelist is not a never: whitelists from different guardians add up, so the widest one anyone references applies. A household that means never writes a deny.
POL-008 · POL-019 · CONS-005 · CONS-006 · CONS-007 · RESTR-040 · PROF-001 · NF-028
Who governs
Who governs changes only by the subject's signature
Mutual consent as two ordinary signatures: the guardian's on the offer, the subject's on the association that names the guardians.
No valid association at all? Then nothing is signed and every evaluation denies: the unbound state is fail-closed, not free.
More detail
The association (kind 17710) names the guardians, publicly or privately. Offers are kinds 7710 (open) and 7711 (sealed). Where a guardian holds the subject's key, both signatures come from one hand: what remains is a public record of who governs, not consent — the specification says so rather than pretending otherwise.
The exit is custody: whoever holds the subject's key can sign a newer association outside the regime, and every engine follows it — a loud, public, timestamped act.
ASSOC-001 · ASSOC-020–022 · ASSOC-038 · CERE-001 · CERE-009–015 · NF-013
The two questions
Reading is not acting
May this reach the subject?
- Is it genuine?
- Is it allowed now — this kind, this day, this hour?
- Does it touch any deny?
- One permitted place, person or thing — or the subject's own authorship — admits it.
May the subject sign this?
- Is it allowed now?
- Does anything it references — and what that references — hit a deny?
- Is everyone and everything it names covered — by an interact grant, or as the subject's own event?
- Are its destinations allowed?
A stranger seen inside a trusted thread is not a stranger reached.
More detail
Input is permissive behind the denies because a curated feed has to be livable: real threads contain strangers, and a feed where one stranger blanks the whole thread would drive the subject out of the home. Output is strict because a tag in a signed event is an act — clients notify everyone tagged.
The deny sweep is bounded (by default 16 references deep, CAPS-013): what the subject names directly must resolve, while a deeper branch that cannot be followed is reported, not refused.
IN-001–IN-007 · IN-013–IN-016 · OUT-001–OUT-007 · OUT-030 · OUT-031
Two questions, step by step
With one thread seen from both directions.
Trust extension
Whitelists that scale
Nobody can list the world by hand. So the members of a grant can double as sources of more grants:
Adopt a curator
A school publishes who the classmates are; a helpline directory publishes its keys.
Inherit from a peer
What a friend's own guardians permit that friend, taken from their open policy.
Follow a relay's operator
The rules a community relay's operator publishes.
More detail
A harvested entry carries four restriction sets — the adopting grant's and the source grant's, each
with its profile — and all four must allow. It never brings routing of its own, so no source can
redirect where the subject's events go. Choose interact deliberately: adopting a source
at interact opens private messaging with everyone it names, and keeps doing so as the source adds keys.
CONS-018–CONS-056 · TOOL-044
Precedence
A guardian's never survives every grant — from any guardian, at any depth, in both directions.
Grants compose 1-of-N
One guardian's narrow grant never poisons another's broader one: a restriction on a grant only voids that grant, for that evaluation. (One exception: a direct interact/relay grant keeps the relay whitelist on even while void.)
Denies cross between guardians
The deny is the one instrument that reaches across. A deny that names a current guardian is a contradiction: the assembly refuses — nothing is signed and nothing reaches the subject until it is lifted.
More detail
Precedence holds wherever the engine meets a deny; on output, a branch beyond layer 0 that cannot be followed is reported rather than refused.
RESTR-040 · RESTR-041 · RESTR-042 · RESTR-043 · NF-039 · CONS-095 · CONS-114 · OUT-020
The sealed channel
Private messages: analysed, not exempted
- Encryption hides who a message involves. Where the engine can reach the subject's key, it peels the message, finds who it is from and whom it names, evaluates that — and discards the plaintext. Its question is who, never what.
- To be admitted on its own, a private message needs an interact grant on its sender — or must be the subject's own copy. One referenced inside an admitted event is only deny-checked. Sending needs exactly what a public mention needs.
- A household can close private messaging — for one grant, or for everyone — but there is no middle setting: a permitted private channel is private, guardians included.
What the household keeps: who, never what.
The trace on the device names the correspondents. Where a guardian routes a monitor copy, a private send shows up only as volume and timing.
More detail
The engine is the subject's own and hides nothing from the subject, but it does read the plaintext — any interface presenting TEPP must say so in plain words. A monitor copy of a private send is ciphertext, but signed by the subject: a public, attributable record that a message was sent.
OPQ-012 · OPQ-051 · OPQ-119–OPQ-124 · IN-019–IN-024 · TOOL-036 · TOOL-037
Legibility
Every verdict explains itself
Named, not guessed
Every answer names the layer that decided it — and, where a grant decided, that grant and every other grant that would have.
Strangers stay legible
Someone's kind 0 metadata — name and picture — renders without any grant, so the subject can see who someone is, and ask.
Reproducible
The same inputs always give the same verdict and the same trace, on every implementation.
Never silent
What cannot be loaded is reported: to the subject at once, and to the guardians — as an ordinary, policed message — once it has stood a day (by default).
So the subject can ask well — and a guardian knows where to act.
More detail
TEPP defines no request kind and no ask protocol: asking is ordinary messaging, and every guardian is always covered as a correspondent by being a guardian — the global set, such as a bedtime, still applies.
TRACE-006 · TRACE-018 · IN-031 · IN-044 · INTRO-002 · CONS-105–CONS-107 · CAPS-029 · LOCI-044 · NF-005 · TERM-009 · CONS-069
Said out loud
Honest limits
- TEPP cannot open a channel the guardians have not permitted. Where the guardian is the threat, TEPP is not the remedy.
- Enforcement binds a cooperating subject and produces evidence about a defecting one: the boundary is key custody and device control.
- A TEPP signer cannot be evaded by switching clients; a TEPP client on a plain signer can.
- Protected posts (NIP-70) are protected only on relays that implement it — and stay readable everywhere.
- What the subject names must resolve; deep inside someone else's thread, a branch that cannot be followed is reported, not refused.
- There is no release ceremony: a regime ends outside the protocol — by deleting the association or signing a newer one (both signed and public), or by no longer running TEPP software.
More detail
TOOL-039 · TOOL-043 · README “Honest limits” · OUT-020 · NF-013 · ASSOC-038
“TEPP is not a prison, it is a home. It's the walls and structure your parents provide […]. The restrictions are, hopefully, in your best interest, to guide you on your way to get on your own two feet. In this case to at some point walk the digital plane permissionlessly.”
Part II · mid-technical
How it works
- 18The six event kinds
- 19The association
- 20The ceremony
- 21Where policy lives
- 22The policy document
- 23Restriction regimes
- 24Restriction profiles
- 25Trust extension
- 26Assembling the construct
- 27Fail loud, never silent
- 28Input evaluation
- 29Output evaluation
- 30The one edit
- 31Where signed events go
- 32The sealed channel
- 33The loci
- 34Keeping the construct
- 35The trace
- 36A week under a starter profile
- 37What TEPP does not define
Six event kinds — and where they live
The kind number is the type and the version.
More detail
Each kind's tags are an allow-list: a tag a kind does not permit invalidates the event, because relays
index single-letter tags and an unintended tag would be a leak. Only the two offers may carry an
expiration tag.
EVT-001–EVT-029 · NF-001 · NF-002
Kind 17710
The association — and the unbound state
- One replaceable event names the guardians: publicly as
ptags, privately encrypted to the subject's own key, or any mix. - A valid guardian set has at least one guardian, no duplicates, and never the subject.
- The newest valid association applies at every locus; a newer invalid one never hides an older valid one.
- No valid association → unbound: the signer signs nothing and every evaluation denies.
- A high-water mark blocks rollback: an older association never displaces a newer one the locus has seen.
- The founding association comes from outside the engine — typically the signer product's key-creation flow.
- Whoever holds the key can sign a newer association outside the regime. That exit is a signed, public, timestamped event at a coordinate the guardians already watch.
More detail
A fresh key and a governed key whose association cannot be found are the same state — unbound, the most closed state there is. No state holds a key in a regime just because it once was in one.
ASSOC-001–ASSOC-039 · NF-007 · NF-008 · NF-013
The re-association ceremony
Guardians define; the subject ratifies.
More detail
The ratification is itself the permission for the guardians the offer names: the subject needs no separate grant on a proposed guardian. It is otherwise an ordinary sign request, gated like any other.
CERE-001–CERE-047 · NF-011 · NF-012
Addressing
Where a subject's policy lives
Open binding coordinate
37710 : guardian : subject
The d tag is the subject's pubkey — a public statement of the relationship.
Sealed binding coordinate
37711 : guardian : blind(G,S)
A hash of a key only the guardian and the subject share — to anyone else it is noise.
- A carrier binds the subject only if a current guardian wrote it at one of these two addresses — so the subject knows exactly where to look.
- A withheld carrier is not silence: on first load, a coordinate that every counting relay answers and none holds is known-missing — a conclusive outcome, not a failure.
- A curator's general carriers live at other addresses and bind nobody directly — only through extension.
- A carrier is retired by republishing
{}: policy shrinks only by a signed act.
More detail
blind(G,S) is the first 32 hex characters of SHA-256 over "tepp-sealed-policy-addr"
and the NIP-44 conversation key of G and S. A keyless client cannot compute it, so it learns the address
once by trial-decrypting the guardian's sealed carriers through its signer.
ADDR-001–ADDR-022 · CONS-158
Anatomy of a policy document
One schema, open or sealed.
Restrictions: four regimes, two places
Where a set lives decides what its deny does.
More detail
An allow-shaped set fails safe as new kinds are minted: regime 4 closes over them. A deny-shaped list of
kinds rots open instead — which is why breadth is written with * or the opacity axis, never
with longer lists.
RESTR-001–RESTR-043 · NF-019 · NF-063
Restriction profiles
Rules as reusable, immutable values.
Trust extension, in detail
One hop, four restriction sets, the routing law.
Assembling the construct
Ten steps from the stored known world to one construct.
Failure polarity
Fail loud, never silent
Strict where TEPP writes
An unknown key, a duplicate key or a
null in TEPP's own JSON invalidates the payload. In a guardian's binding carrier that refuses
the assembly — harsh, but loud, immediate and local.
Absent, and reported
What cannot be loaded is left out of the construct and reported. On the grant side that only narrows; a deny list that has not loaded is an accepted, visible risk.
Refusal for contradictions
The assembly refuses only for a rollback below an anti-rollback mark, a deny naming a guardian, malformed binding content or a breached integrity cap — and no valid association at all leaves the subject unbound.
Lenient where others write: a list's members and a relay's information document are read the way the network reads them.
More detail
Why refuse over a guardian's typo instead of skipping the broken carrier? Because a discarded binding carrier could hold deny gates. A broken harvested carrier is grant-side, so it is simply dropped.
POL-066–POL-093 · CONS-084 · CONS-105–CONS-118 · LIST-010
Input evaluation
Seven steps; the verdict needs no network.
Output evaluation
Seven steps; the first failure decides.
The rebroadcast demand
The one edit: ["-"]
An allow restriction can carry rebroadcast: "deny". When such an entry matched a
permitted sign request, the signer appends NIP-70's ["-"] tag — and never changes anything
else in what the subject signs.
Relay implements NIP-70, with AUTH
Only the subject may put the post there, after proving the key.
Implements it without AUTH
The relay refuses the post.
Does not implement it
Stored and served like any other event — anyone may put it there.
Everywhere, the post stays public and readable. The event the signer returns is authoritative: a client publishes exactly that.
More detail
The tag is never added to an envelope (such as a seal) or to TEPP's own kinds; the mutation is traced. Publishing to a NIP-70 relay needs a NIP-42 AUTH, itself a sign request the policy must admit (kind 22242).
OUT-040–OUT-047 · RBC-001–RBC-014 · TOOL-028–TOOL-031 · NF-082
Destinations
Where signed events go
- By default: the ordinary outbox model — the subject's write relays, and the inboxes of those it addresses.
- A denied relay is never a destination, whatever the label.
- Once a guardian writes any
interact/relaygrant, every destination the client supplies must be a member relay — the subject's own relay lists included. - A covered recipient's declared inbox still passes: where a message is delivered is the recipient's address.
Monitor copies
On a permit, the monitorRelays of every
grant that covered something receive a copy of the signed event: oversight of what the subject signs.
A monitor copy of a private send is ciphertext — but signed by the subject, so it is a public record that a message was sent, then.
More detail
The destination set is supplied by the client; a signer reached over NIP-46 receives none today, and then the check is reported as unenforced rather than treated as passed.
OUT-048–OUT-069 · TRACE-033 · LOCI-003 · NF-059 · TOOL-037 · TOOL-046
The sealed channel
Reduction, the three oracles, the regime.
Where TEPP is enforced
Signer, clients, relays and spaces.
Keeping the construct
Knowledge only advances.
Every verdict explains itself
Layers, attribution, findings, determinism.
A worked example
A week under age-13-school-household
The starter composite profile, referenced from a guardian's global array. These are the
decisions of the global gate: a deny here is the verdict; an allow lets the rest of evaluation run.
| when | what | the profile decides |
|---|---|---|
| Wed 10:00 | sign a note (kind 1) | deny — school hours: no signing |
| Wed 10:00 | a note arrives | allow — school hours close signing only |
| Wed 23:00 | a note arrives | deny — the school-night curfew |
| Sat 23:00 | a note arrives | allow — no curfew on a Saturday |
| Fri 23:00 | sign a note | allow + ["-"] — Friday evening is free; notes get the ["-"] tag |
| Tue 21:30 | send a private message | deny — the sealed-sending curfew |
| Tue 21:30 | a private message arrives | allow — the curfew only closes sending |
| Sun 14:00 | sign a long-form article | deny — never |
| Sat 12:00 | sign a video (kind 21) | deny — the cohort does not name it: regime 4 |
| Sat 12:00 | sign a repost (kind 6) | allow, no tag — named without the demand |
More detail
The curfew is two entries — Sunday to Thursday evenings, Monday to Friday mornings — because a window is matched against the instant's own weekday, never the day the window started.
profiles/README.md · PROF-034–PROF-040 · RESTR-004 · RESTR-005
Deliberate absences
What TEPP does not define
No ask protocol
No request kind: asking is ordinary messaging.
No release ceremony
No terminal state; a regime ends outside the protocol.
No middle setting
A private channel is closed, or exactly as open as the public one.
No relay enforcement
Relays never enforce a subject's regime.
No people in profiles
Profiles carry shape only: no npubs, hashtags or patterns.
No version fields
A breaking change is a new kind.
No hint-following
Evaluation never fetches where a third party points.
No silent edits
The signer changes nothing it signs except the one ["-"].
More detail
NF-005 · NF-013 · NF-078 · NF-094 · NF-029 · NF-001 · NF-053 · NF-082
A home, not a prison.
Guardians write the walls; the subject's own engine enforces them, explains every decision, and lets the subject see — and ask about — everything that bounds it.
Based on the TEPP Zeta specification. Identifiers such as IN-005 refer to its
statements. Every diagram is a draw.io file you can download and edit.