Skip to main content

Protocol Overview

A technical specification for decentralized digital trust and identity using Nostr and Web of Trust principles.

Introduction

The Kidstr protocol is an open framework built on the Nostr ecosystem. Its goal is to enable trust-based online domains, starting with the challenge of providing children safe and suitable acces to the internet — but extending to anyone who wants control over what they see, who they interact with, and how they appear online.

Rather than relying on centralized moderation, AI-systems, or government ID systems, Kidstr establishes risk management through trust. It enables users — parents, educators, communities, or institutions — to assign three levels of trust to enviroments (servers) and relationships (people), while retaining the openness and interoperability of Nostr.

At its core, Kidstr is not a single app but a protocol layer that connects relays, clients, and signing bunkers through Nostr-based moderation events.

The resultis a decentralized, interoperable, and mostr importantly as safe as possible way to express who you trust, how far you trust them, and what a given profile is allowed to see and do.

The Parent–Child Trust Link

At the heart of Kidstr is the multi-signature link between the parent and child keypairs.

This association event instructs the Nostr client and signing bunker to respect the associated moderation events.

Clients use this musig event to construct the child's personalized environment.

A child can then navigate freely within that predefined domain, while still maintaining autonomy:

  • They can follow others within the approved circles.
  • They can interact within Level 2 contexts.
  • They can see but not engage beyond the boundary of Level 3.

The musig link provides the root of delegation and oversight — without central servers, databases, or government Ids.

Three-Level Trust System

The central idea is to model the child's world as three concentric circles of trust, applied to npubs, relays, and sometimes individual events.

Inner circle

  • The child can view and interact with this entity.
  • Additionally, the child's online domain is extended with the trust this person has assigned to other people and places. Level 1 is the main means by which the web of trust is used to scale the child's online environment

Used for: parents, close family, close friends, carefully vetted institutions.

"I trust you and I trust your judgment for my child."

Interact

The child can view and interact.

Used for: school contacts, sports club, known teachers, classmates, known brands.

"I trust you enough for direct interaction, but I don't automatically trust the people you trust."

View-only

The child can only see content from this person of place. This is the edge of the online domain

Used for: news outlets, public information relays, some platforms where comments / replies are not trusted.

"I trust the primary content to be non-harmful, but I'm not comfortable with open interaction."

In analog terms:

  • Inner circle → the people you'd leave your child with for the weekend.
  • Interact → the tennis club or schoolyard: places you feel comfortable to drop your kid off, to pick it up later.
  • View-only → the cinema: you trust the movie, but not everyone in the room.

Trust Levels in Practice

The Kubo demo app demonstrates how parents assign the 3 trust levels to people, groups, and content sources.

Kubo MVP screenshot showing trust domain People tab with Inner circle contacts, Groups, and Other content sources with High/Mid/Low trust level assignments

Click to expand

Kubo MVP screenshot showing trust domain Places tab with Sites and Suggestions for relay services with High/Mid/Low trust level assignments

Click to expand

Kubo MVP screenshot showing Groups overview with group memberships and trust level assignments including Local Kubo group, Soccer team B3, Classmates, and Kindergarten

Click to expand

Three-Tier Architecture

Our protocol separates concerns through a three-tier architecture: Client interfaces, secure Bunker key management, and distributed Relay networks.

Web of Trust Protocol StackArchitecture showing Client, Bunker, and Relay components with bidirectional communicationClientBunkerRelay

Client

User-facing interface for identity management, attestation creation, and content interaction. Clients are lightweight and stateless, delegating security to Bunkers.

Bunker

Secure key storage and signing service. Bunkers hold private keys and sign events on behalf of clients, enabling separation of user interface from sensitive cryptographic operations.

Relay

Distributed message routing and event storage. Relays propagate signed events across the network, providing redundancy and censorship resistance without controlling content.

Development Roadmap

Core Protocol Specification

Initial protocol design and documentation

Reference Implementation

Working Bunker and Relay implementations

Kubo Demo Application

Child-safe video platform showcasing the protocol

Client SDKs & Libraries

Developer tools for building on the protocol

Production Deployment

Public relay network and bunker services