The previous article nostr:naddr1qvzqqqr4gupzqh4yvjqytwcl7g3x2hwaxmndemwugdvscfsfp3yxhmecaazsmfdaqq257njwwdt5k5zgwu6z66mwdayysc23daeh56a64dd
gave an outline of the general idea with various mechanisms to achieve the vision. Because the goal of creating a safe and suitable internet for children will have a large number of requirements, we will need every tool and means at our disposal. On the other hand, expecting to build this from scratch in isolation all the way to completion, only to subsequently expect the broader ecosystem to adopt a large set of complex systems, is not realistic.
I propose an iterative gradual approach from multiple directions. In concrete terms this will mean that we are planning to set up a foundation, whose purpose is to be the North Star of these developments. It will engage with the large spectrum of stakeholders involved to identify the requirements and establish specifications; it will facilitate the discussions, resources and nurture the knowledge base. Its main goal is to achieve coherence in the more chaotic process that will be described below. To be clear, we think that there are many for-profit business opportunities here, demand is high and there is a multitude of domains and use cases for the general system we propose.
Within Nostr, control lies in various places at the same time. Relays have complete read/write access control, and can apply whatever arbitrary logic to enforce that: only certain Npubs, only at full moon, can read particular event-kinds, when a threshold of signatures is provided by a quorum consisting of a dynamic group of WoT-score defined people grant permission… if it so happens to be a Saturday and the relay owner feels like it, or something like that. Clients control what relays they connect to, where it sends events to, what queries they make and can subsequently decide to do whatever they feel like with the events that come in or go out; it can bother to fetch things, or not; show them, or not; render them completely or just partially, or upside down, scrambled… A client can even have special requirements before it accepts a particular key-pair. The signing bunker holds the keys, and can therefore decide whether an event gets signed or not. I will spare you another silly convoluted example and trust you get the picture.
Your Nostr experience is determined by the behavior of all three. Many restrictive powers overlap in terms of effect between two or all three of them; others are unique to either the relay, client or bunker. My vision, the ‘North Star’, is that we leverage all of them to their fullest extent. To the extent functionality overlaps, we take the redundancy as extra guarantees against failure. There is no harm in the fact that if you were not supposed to publish something, the client refuses to send it off for signing; the bunker won’t sign it despite the fact it should have never received it in the first place; the relay refuses to store it despite the fact it should have never been signed.
What this means, is that the three components can be developed (at least in large part), independently. A ‘Kidstr’-bunker app can be developed and immediately provide value regardless of what clients and relays are used; the same goes for ‘Kidstr’-relays and ‘Kidstr’-clients respectively. The moment these Kidstrized components are combined, synergies emerge and new use cases become available, because the system can benefit from the unique restrictive capabilities of the respective components.
To illustrate, with what was already mentioned in the previous article: At this point in time, leveraging relays would be the low hanging fruit for two reasons. First because it is really easy to create a client that restricts itself to only use particular relays. Second because many experimental relays, and the tools to construct them already exist. A group of users/parents could start to populate a relay with content they deem fit for children today, and an easy to build bare-bones client could start to be used tomorrow. Subsequently development of a special bunker could start, where its initial feature is to be selective in regards to what relay it will authenticate itself to. When used it opens up the ability to use all sorts of clients out there, with some assurance that the client can’t connect to whatever relay, even if it wanted to. At the same time, a client could pop up, that has not yet implemented any relay restriction controls just yet, but has implemented features that allow parents to determine at what times of the day, what event-kinds are allowed to be interacted with. Despite each component developing at different speeds and different directions, combining them can immediately add value.
This is where the notion of coherence comes in, and what ‘Kidstr’ in concrete specification terms actually is. All these various settings, what is allowed and what is supposed to be restricted, can be defined in a variety of parental-control events that relate to a particular child/Npub. Compliance with ‘Kidstr’, simply means correctly interpreting those events and enforcing them, whether it be a relay, client or bunker; some things only apply to one component in specific, a lot of them will be relevant to all. Ideally each component has implemented all their respective relevant features, but for the system as a whole to function this is not strictly required.
It is also important to point out that the path of development, be that related to clients, relays or bunkers, is not just in service for this one particular ‘Kidstr’ end-goal of a safe and suitable internet for children. The features and functionality developed along the way can be of value all kinds of use cases. In essence the only thing that ‘Kidstr’ is, is tooling for the most high-risk type of user with the largest amount of requirements; professionals that want a Safe-For-Work experience, or conscious users that want to guard themselves from aimless doom-scrolling can benefit just as much from all these developments.
Operation Kidstr is here to establish a protocol, and to be the North Star for the rest of the Nostr ecosystem to get a sense of how the particular thing they develop could fit into a bigger coherent whole.
