Thread

Continuing onward from nostr:naddr1qvzqqqr4gupzqh4yvjqytwcl7g3x2hwaxmndemwugdvscfsfp3yxhmecaazsmfdaqq2hwjr4vf3xzkr4wyu9zvpcx9n855zfd9rrqchkarh

---

Introduction

In this series of articles I will describe our current view to tackle the various requirements that pop up when designing a suitable and safe internet for children. This particular article will hopefully make it clear what we have in mind. It mainly focuses on the notion of trust levels, and will briefly outline some additional ideas. Subsequent articles will go into more detail, and hopefully allow for an open discussion on these matters in a somewhat structured way in the comments. The language used will be Nostrcized from the get-go and in places overly specific in its implementation. This is done to present the vision in concrete terms, but keep in mind that every implementation (detail) proposed is open for discussion.

Basis of the Approach

At the basis lies the ability for parents to define the digital environment and experience of their children in a manageable and flexible way. This should accommodate the wide variety of demands depending on a parent’s norms and values in relation to raising their child, and the changing situation of the child. This control pertains to all aspects of what we find in Nostr; keys and signing, profiles, clients, events, event kinds, Npubs and relays. This is done by linking the two key-pairs, that of the parent and that of the child via a musig event. This musig event becomes the base reference clients use to find various lists. Lists of trusted Npubs, trusted relays and trusted events. The total of these trusted elements subsequently constitute the digital environment the child is free to navigate and, depending, interact with.

Trust Levels, keeping things intuitive

In order to control all these aspects I think a default three tier system is a good way to provide sufficient levels of control while keeping things simple to understand. For the purposes of writing I will refer to them as level 1, 2 and 3. In a way these are three concentric trust circles. Moving from the outside inwards:

Level 3, Low Trust:

Intended for things that exist in the periphery of the trust circle. Parents trust content not to be directly harmful, but generally have no insight in its context. It implies the ability to view, but not interact. The child is aware of level 3 things existing, but at the same time constitute the edge of their online environment. An example would be a friend of a friend of a friend; a news outlet, or any other environment where the primary content is trusted but the comment section for instance is not.

Level 2, Trust:

Intended for things where the person, business, relay or environment etc. itself is generally trusted. It implies the ability to both view and interact, but this trust is not extended. Level 2 pertains to friends, or friends of good friends and family. It constitutes the bulk of what the child can interact with, and will probably map closely to the child’s physical environment; think of school, sports clubs, i.e. any place where in the analog world you feel comfortable to drop your kid off, to pick it up later.

Level 1, High Trust:

Intended for people, environments etc. that are fully trusted. It implies not just that ability to view and interact with content, but the delegation of trust in terms of what other things are appropriate for your child. This means that if the child’s aunt is in the level 1 circle, everything that aunt has defined as level 1 and 2, becomes accessible to the child on a level 2 basis. Level 1 is the main means by which the web of trust is used to scale the child’s online environment. This is family, close friends, other parents you see eye-to-eye with, or generally anyone or anything you would feel comfortable taking care of your child for an extended period of time.

So in short, level 2 is the domain in which the child can actively interact (reply, like, DM) with the online environment, level 1 is the means by which level 2 is most easily expanded, and level 3 is the edge domain to the level 2 where the child can see it exists, but can’t interact with it until it gets explicit permission to do so. Or in analog terms: Level 1 is inside the house; level 2 is the tennis club where your child can interact with the other members of the tennis club; Level 3 is the movie theater where you trust the movie, but you don’t trust the rest of the audience that also comes to see that movie.

Applying Trust Levels

These trust levels can apply to Npubs, Relays or individual events (except that Level 1 trust towards individual events does not make sense). For example, an individual educator posting content under his Npub could be assigned level 2 trust, which means that the client will use the outbox model to fetch their events. But you could also have an education platform that runs a relay that is assigned a level 2 trust, where the client uses a relay based feed. When a child comments on the trusted educator Npub, that comment is sent to the inbox relay of that educator, but whether it gets to see any other comments, or can interact with those comments, relies on the trust level assigned to the relays where those other comments reside OR on the trust level of the individuals that made those comments. So there could be a situation where the education platform is assigned a level 3, low trust, but one particular educator active on that platform has a level 2 basis. The child will see all the content, and all the comments, from all the educators and all the students, but can only interact with that particular level 2 trusted educator, and the comments from other students that explicitly are level 2.

None of this is actually simple, especially not for applications, but I at least hope that it is clear enough such that parents can build an intuition as to how these things function. See, interact, extend; level 3, 2 and 1 respectively.

To be clear, all this merely defines what is available to the child; the child subsequently is able to create its own follow lists within this pre-defined domain of content.

Client-Control

All of this pertains to content in general, but let’s discuss client-control. Just as parents can define the people, places and individual pieces of content that are trusted to full or lesser extent, parents should also be able to determine what an app can do and when. No activity between 22:00 and 07:00; no kind 21 and 22 video events after 19:00; only audiobooks and long-form after 19:00 etc.

Relay Hygiene

Clients should be very careful as to where they send events made by the child to, and only send them to the appropriate place; anything can be sent to a level 1 relay, an option parents have to ensure they can monitor their child’s activity if they deem that necessary. Under no circumstance should events be send to undefined relays or relays that are level 3. Generally, events should only be send to level 2 relays where the actual interaction takes place, or the inbox relay of a level 2 Npub.

Profile Control via Bunker

When clients enact this type of relay hygiene for outgoing events, we should be able to implement a profile control feature. This feature operates entirely outside of the client, but does rely on the client to function appropriately. When a bunker is used, the bunker could be upgraded to reason about the events it is signing; based on the relay hints and Npubs referenced inside the events, it can infer what profile should be applied in that particular instance. Is the child responding to post made by grandma, or to something that is being said inside the school relay? Then the post can be signed with the child’s real name. Is the child commenting on a game-forum, the bunker can infer this and apply a different key-pair that goes under the name Dr4g0n-D3s7r0yer9001.

Division of Responsibilities

This is a type of bunker functionality could be very useful outside of this ‘Kidstr’ context, and could for instance save people a lot of NSFW trouble, or provide general internet profile hygiene. Ideally the entire system could be constructed from this smarter type of bunker, because this would mean that one type of app could be developed and subsequently the entire Nostr ecosystem of apps is available to the child. That is impossible because bunkers are responsible for signing and as such only cover the output side. Meanwhile it is the clients that query the relays, so controlling the input side is inevitably a client responsibility. This points to a couple of things that are important.

First that we need to leverage every component within the Nostr system to the fullest in order to meet the high requirements. Second that separating the responsibilities allow for easier implementation. A lot of the burden will still be on the client side, but this leads to the third point that not every aspect needs immediate implementation to the fullest extent in order to start gaining benefits. Clients could start with a base-line implementation simply assuming everything is on a level 3 basis, while being observant of the lists of relays, Npubs and events defined by the parent.

Challenges

This means that ‘Kidstr’-enabled clients at the very least will have to check for the existence of a child-parent-association-event, and subsequently fetch the relevant data. The bunker should be able to block use of non-Kidstr-enabled clients, at least with the use of the child’s own keypair. This will probably mean that apps will need a separate Kidstr version, in order to prevent the child from simply creating a new keypair and using the app as a ‘regular’ user. Preventing access to other apps or the ‘wrong’ apps will depend mostly on access to hardware and whatever control the operating system of that hardware allows for. As long as operating systems are not Nostrified, this is outside of the scope of what ‘Kidstr’ can provide, but we can imagine that something like the zapstore fits nicely within this paradigm.

Implementation Path

All of this is a grand vision, and none of it is trivial. But as I mentioned before I don’t think everything is required all at once. For instance the means to collaboratively construct and manage the content on a relay exists today; parents could start using this tech tomorrow to create minimal viable environments of content. Subsequently creating stripped-down and bolted-up bare-bones clients to interact with just those type of relays should not be much of a problem. It would create a starting ground that remains relevant the moment all this other stuff described in this article starts to manifest. There are more ways to skin this cat, and the nice thing about Nostr is that they can compound over time.

Conclusion

My hope is that we have a future where trust networks of parents, institutions and businesses can start to form, and become the basis of a vibrant online environment that is appropriate for our younger generations. Hopefully this sketch provided enough for all of you to consider and think about.