Nostr facilitates permissionless use of the web, in what you publish, what you watch and with whom you associate. An open and permissionless web is important for a variety of reasons, but also causes an obvious issue. Even though you don’t have to ask permission, you are still responsible for the things you do; and as it happens there is a subset of users that inherently are not responsible. The solution was first imagined in the context of parents facilitating appropriate and safe environments for their children, but in recent times the prospect of using this type of system for bots has emerged as well.

Introducing TEPP, a permissionless system for the creation of permissioned environments. TEPP stands for Trust Extended Permissions Protocol, a predominantly permission-based restrictive overlay moderation system for Nostr that allows for controlled environments that scale by flexibly leveraging trusted third parties. Albeit the system is general in nature, its primary design consideration is to facilitate parents in defining an adequate and safe online experience for their children utilizing their social network of family, friends, like-minded parents and institutions like schools and other trusted organizations and businesses.

Explicit permission-lists of people (npubs), places (relays) and things (events) can be collected throughout social networks in order to define the type of interactions (kinds) that can occur and when. These collections form a construct that can be run at various places, be that remote-signers, clients, or, in some cases, relays. This construct then determines whether any action, be that to query, render, or interact, can occur, allowing for flexible parallel implementation of the system throughout the Nostr ecosystem. Because any action requires explicit permission in the first place, any possible unwanted occurrence is directly traceable back to the permission used, and is therefore clearly addressable in order to prevent such occurrences in the future.

The system operates at the lowest level of Nostr’s logic and uses its core aspects of kinds, events, npubs, and relays, meaning it is agnostic to and compatible with any possible NIP or client. A TEPP regime applies to a particular npub, defining only what is available, while the key pair in question is free to perform any normal Nostr behavior (who to follow, construct feeds, etc.) within those restrictions. The temporary nature of the TEPP regime allows, for example, a child to continue utilizing a profile into adulthood in a permissionless manner.

What follows is a general description of how the system is supposed to work. TEPP is still in active development and details, entire components or the system as a whole are subject to change. The system itself could be used in any context, but for narrative purposes the usecase of a parent and their child will be used.

Brief overview: The parents and child mutually create the association among them, defining that the child operates under the TEPP regime. Any TEPP enforcing system will look to see if such an association event exists, and can use it to start finding all the required events to construct the TEPP regime in question. In this association event, the child is defined as the subject, and the parents are the guardians.

Each of the guardians mentioned in association event subsequently define the people, places and things the child can see and/or interact with via so-called permission events. These permission events are at their core just a list of either npubs, relays or events, together with some context. This context defines the relevant restrictions placed on the list of people, places or things; be that whether the list is view-only, or the subject is allowed to ‘interact’. Interaction here in a technical sense means the ability to reference the npub or event in question in their own posts; meaning that if it is restricted to view-only, they can’t reply and can’t mention the thing in question. The other restrictions that can be placed are time-, kind- and relay-based. This means that interaction could be restricted to certain moments in the day, only based on certain types of events (for example articles, videos, audio, etc.) or can only take place in certain places, or will always send a copy to some monitoring relay. The last bit of context is the crux of the TEPP system, being the trust extension that can be applied on the list. This extension means that the system will look for any available permission events that are tied to the entities mentioned in the list, and will add those to the construct of the child. For instance, if the list represents neighborhood friends, a trust extension can be applied where all the people the neighborhood friends are allowed to interact with, now also are people the child can interact with. Mutations could be applied, for example turning all the ‘interaction’-lists into ‘view-only’; this way the child is aware of all the interactions the neighborhood friends have with their social circles, but additional permissions are required for the child to join in.

All these permission events that a guardian creates, are bundled into a state-event, such that it is clear what is supposed to be part of the construct, and allow for efficient fetching.

While the system is primarily whitelist-based, the ability to blacklist is included, as well as global restrictions. These global restrictions are the same type of time- and kind-based restrictions that can apply on a particular list, but apply globally, regardless of what is defined in the individual permission events.

A TEPP enforcing system will look out for an association event related to the child in question. Once found, it knows who the guardians are, and can look for the state events of each of those guardians. Once it has acquired those, it can fetch all the mentioned restriction and permission events. Then, it can look out for any trust extensions that are defined in the permission events and perform a similar routine for each of those extensions, with perhaps some mutations at the end if specified.

All of this can then be combined into a comprehensive construct. Every action will then run past this construct to see if it hits any restriction (at which point it is denied), or any permission. If it fails to hit any permission it is denied as well.

It is important to note how different types of permissions interact with each other. Relay-based permissions are very powerful. Particular things might only have view-only permissions for example, meaning the child can’t reference those people or posts. Yet, if it has a general relay-based permission, any post, including those with such references is permitted based on its location alone. While the design of the system allows for very granular control, it is assumed that when implemented in an app for parents for example, defaults and simplifications are applied. One such simplification for example could be reducing it to High, Medium and Low trust; where Low is view-only, Medium allows for interactions and High would apply trust extensions. The system is list-based, because the general social heuristic people apply is group-based. Kids from school, people in the neighborhood, family etc. People generally are able to reason about trust in relation to some social context, and at the end of the day setting permissions in relation to some individual simply means a list of one.

What is described is the core. TEPP is at the basis of a system that will require other components when utilized out there in the world. Systems that allow children to ask for permissions, or report content; networks that allow parents to share otherwise encrypted permissions; web-of-trust metrics that help parents or automated permissioning systems to make informed decisions. Once TEPP as such exists, the way is open to start building these other components on top of it.

Lastly, on privacy. All of the system can be made private, either encrypting parts or giftwrapping entire events such as with the association event, making them only accessible to the child. The immediate trade-off is that each aspect that is private is subsequently not available to outsiders, undermining the trust extension capabilities of the system. This will require the aforementioned private exchange of permission events in closed networks. I see a natural progression in trade-offs made with a child growing older. The need for vast networks is much lower for younger children, while the privacy matter is more precarious; when they get older, their demand for a more expansive experience increases, while their participation in public life itself organically grows as well. TEPP as such is not here to make decisions one way or another.

Trust extension and mutation examples: