Connect

30817:clestr-01

Clestr-01 (Curated Layer of Educational Stuff Transmitted by Relays)

covers30040Publication Index30041Publication Content30818Wiki Content

Kristian with a K

signed by
npub18yucy...9hk23j
published
2026-08-21
event
82e9da3b26...9811

What this tries to solve

Free educational content exists everywhere on the internet, but is not well organized. Dedicated websites like Khan Academy, edX, Coursera, and MIT OpenCourseWare host and organize their own centralized free content, but each remains disparate from one-another. Platforms like YouTube, Medium, and Substack contain a mix of educational content and entertainment (which can be distracting). Search engines help users find individual pieces of content, and people and corporations can organize and curate that content via existing platforms, but those lack harmony. Clestr is a protocol built on Nostr to address these pain points and create an open method for organizing, curating, and collaborating on new and existing educational content on the internet.

Vision

  • Anyone can curate their own learning pathways and share with others
  • The "best" individual content from different sources can be combined to provide a complete curriculum.
  • Content on the same topic by different creators can be organized as alternatives that may be better fit for people with different needs or learning styles
  • Users maintain control over their experience (no unwanted vying for attention)
  • WoT (Web of Trust) allows users to build reliable decentralized networks of skills, endorsements, and content
  • The protocol can act as a layer on top of a user's browser experience, giving them access to curation tools wherever they are

Protocol Notice

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.

Nostr Relay

MUST serve a NIP-01 compliant nostr relay at /.

MAY reject or delete events for generic SPAM prevention reasons or curation eg. WoT, whitelist, user bans and banned topics up to the relay's discretion.

It is RECOMMENDED that the relay implement NIP-50 (Search)

Client Behavior

The client MAY operate as a web browser plugin, a standalone app, or a website with embedded & linked content.

SHOULD implement the following for complete feature set:

MAY implement:

Many of these protocols are broadly supported by other clients which makes clestr adaptable to support and render content produced by other clients without modification.

Client UX Example Implementation Ideas

Client A - Browser Plugin

Users interact with their browser as usual. When visiting videos and webpages across the internet the plugin MAY search relays to see if the current page has been referenced in any courses/curricula and render or inform the user of this. As users interact with the page they may decide to mark the content as completed, or view it in the context of the surrounding course/ curricula. They could open it up to see other user's comments on the external link or the curated learning paths.

Client B - Webapp or Desktop app

Rather than overlaying the live web like the browser plugin, this client pulls referenced content into a Clestr-controlled surface. When a learning path references an external URL (a video, article, or interactive page), the client renders it in a sandboxed iframe with Clestr controls layered around it — mark-complete, highlight, and comment affordances drawn from the surrounding course or curriculum. Because many sites refuse embedding via X-Frame-Options or a CSP frame-ancestors directive, the client MUST detect a blocked frame and fall back to opening the resource in a new tab while still displaying the Clestr context (position in the path, prerequisites, peer comments) alongside the link. Untrusted embeds SHOULD carry a restrictive sandbox attribute. Where Client A annotates the open web in place, Client B brings the web into a curated reading environment — the same events and trust graph drive both.

Curation Layer

Clients SHOULD author new 30041/30818 content in Djot (See NIP-54's choice for reasoning).

Clients SHOULD also parse AsciiDoc because NKBIP-01 30041 in the wild uses it.

Clients MUST resolve both wikilink conventions — NIP-54 Djot reference-style [term][] and NKBIP-01 double-bracket [[term]] — to kind 30040/30041/30818 by normalized d tag.

Users SHOULD curate or create organized educational content in the form of curricula/courses and in a combination of kind 30040/30041.

Clients MUST implement creation and rendering of the course and curriculum publication indices & content.

URL Normalization for External Content

When matching the user's current location against externally addressed content (NIP-73) and when authoring r/i references, clients SHOULD apply best-effort normalization so the same resource resolves to the same address regardless of how the user arrived at it. The same normalization routine SHOULD be used for both matching and authoring, so that a reader and an author independently arrive at the same identifier.

Clients SHOULD:

  • Lowercase the scheme and host, prefer https, drop default ports (:80/:443), and strip a trailing dot on the host.
  • Strip known tracking and session parameters (e.g. utm_*, fbclid, gclid, mc_eid, igshid, ref, ref_src).
  • Remove the URL fragment unless it is known to be content-identifying.
  • Apply platform-specific canonicalization for well-known hosts, collapsing equivalent forms to a single identifier — e.g. resolving youtube.com/watch?v=ID, youtu.be/ID, youtube.com/shorts/ID, and youtube.com/embed/ID to the same video, and where NIP-73 defines a dedicated identifier kind for that platform, addressing by that ID (i) rather than the raw URL (r).

Clients SHOULD preserve query parameters that are content-identifying (e.g. v= on YouTube) and SHOULD NOT reorder or alter parameters whose semantics they do not recognize. Clients MAY retain the original, pre-normalized URL alongside the normalized identifier for display and linking.

Because normalization is necessarily incomplete, clients SHOULD treat a missing match as "no curation found" rather than authoritative, and MAY fall back to host-level or fuzzy lookups to surface related content.

Kind 1985 Labels NIP-32

Use is up to the discretion of the client and the user, but they MAY for example use them to categorize content according to an ontology or classification like the Dewey Decimal Classification, Universal Decimal Classification, Wikipedia-style category tree taxonomy, Thema Subject Categories

Labels MAY also be used to classify content by educational goals like Blooms Taxonomy.

e.g.

["L", "blooms_taxonomy"],
["l", "understand", "blooms_taxonomy"],

Kind 30004, 30005, 30006 Curation Sets NIP-51

SHOULD avoid these kinds in preference of kinds 30040 and 30041 for curation.

Clients MAY still choose to provide these, but they SHOULD note the intended uses and differences.

Kind 30009 Badge Definition NIP-58

SHOULD be used to define skill competency badges that users can issue to eachother

SHOULD be used to define milestone or course completion badges that users can self-assign and assign to eachother. Milestones may include things like capstone projects, diplomas, degrees, and certifications to name a few.

Kind 30023 Long-form NIP-23 (Blogs / Articles)

Clients MAY implement authoring events of this kind.

Users MAY create educational content from events of this kind.

Kind 30040 Publication Index NKBIP-01

  • MUST allow the following list of referenced event kinds:

    • 30023 (long-form content)
    • 30040 (nested hierarchical Publication Index)
    • 30041 (publication content)
    • 30818 (Wiki content)

  • SHOULD use the type tags:

    • course for collection of content that represents a full course (e.g. Plumbing 101 - Intro to plumbing)
    • curriculum for a nested curriculum of courses and content (e.g. Computer Science - Video Game Development Track)

  • Within kind 30040, q denotes a prerequisite reference.

  • MAY contain one or more q tags to specify required/prerequisite content by their normalized d tag according to NIP-54 and optionally the level of proficiency required (short note like "basic proficiency" or blooms taxonomy level)

  • SHOULD allow defer markers like wiki-events in NIP-54

Example event:

{
  "id": "<event_id>",
  "pubkey": "<curator_pubkey>",
  "created_at": 1730000000,
  "kind": 30040,
  "tags": [
    ["d", "mig-welding-101-by-acme-trades"],
    ["title", "MIG Welding 101"],
    ["type", "course"],
    ["summary", "An introductory course on MIG welding, from machine setup to your first structural welds."],
    ["auto-update", "ask"],

    ["q", "shop-safety"],
    ["q", "using-a-wrench", "basic proficiency"],

    ["a", "30041:<author_pubkey>:mig-welding-101-intro", "wss://relay.example.com", "<event_id_1>"],
    ["a", "30041:<author_pubkey>:mig-welding-101-machine-setup", "wss://relay.example.com", "<event_id_2>"],
    ["a", "30040:<author_pubkey>:mig-welding-101-first-welds", "wss://relay.example.com", "<event_id_3>"],

    ["p", "<original_author_pubkey>"],
    ["E", "<original_event_id>", "wss://relay.example.com", "<original_author_pubkey>"],
    ["source", "https://acmetrades.example.com/courses/mig-101"],
    ["version", "2nd edition"]
  ],
  "content": "",
  "sig": "<event_signature>"
}

A client builds the prerequisite graph by walking q edges: for each tag, resolve the d tag to a publication (via WoT among the alternatives), then recurse into that publication's own q tags. Each node is keyed by normalized d tag, so a skill reached by several paths (e.g. "shop-safety" required by many courses) is deduped to one node. The client MUST guard against cycles — a malformed q loop must break, not hang — and MAY topologically sort the result to suggest a learning order. Crucially, prereqs render in a different place from a content: the a list is the reader/chapter view, while q edges render as a prerequisite panel or as upstream nodes in a graph view. An index with only references and empty content (a bare map) SHOULD default to the graph view; a content-bearing index defaults to the reader view.

As defined in NKBIP-01 the p/E/source/version tags credit and link the original work this course was forked from; omit them for an original.

Kind 30041 Publication Content NKBIP-01

  • SHOULD use NIP-73 tags for externally addressed content in which case the content field is optional, which if specified, acts as summary or description of the addressed content.

NOTE: Wrapping externally addressed content via NIP-73 in a kind 30041, allows it to be queryable by its NIP-54 formatted d tag and be compared to other similar content

Kind 30818 Wiki Content NIP-54 (Descriptions, Encyclopedia, WikiHow)

Clients MUST implement creation and rendering of wiki content. Including rendering wikilinks to kind 30040 and 30041 content.

Users MAY create educational content found in events of this kind.

Clients MUST be able to render wikilinks (as described in NIP-54) that can reference the following kind 30040, 30041, and 30818 by d-tag.

Client SHOULD show alternatives when different users have created entries for the same d-tag. See NIP-54 "How to decide what article to display"

Web of Trust

If available, Grapevine WoT APIs MAY be used to filter content by trustworthiness.

It is RECOMMENDED to implement trust in the following order or precedence:

Raw NIP-25 reaction counts can be gamed, and thus SHOULD only count when reachable through the user's trust graph, not globally.

Learner Experience

Kind 1985 Labels NIP-32

Learners SHOULD be able to mark learning path items as complete by assigning labels namespaced under clestr, e.g. in-progress, complete

Client SHOULD allow users the option to store progress as a NIP-59 Gift Wrap event for keeping kind 1985 private

Kind 9802 Highlights NIP-84

(of nostr content and external URLs, with optional context and comments)

Learners SHOULD be able to highlight content on the internet and content hosted by nostr for later referencing.

Kind 10003 Bookmarks & 30003 Bookmark Sets NIP-51

Learners SHOULD be able to mark their enrolled courses and learning paths by bookmarking them (either their global bookmark, or a defined set)

Kind 10008 Profile Badge NIP-58

Learners SHOULD be able to don their achievements

Kind 10015 Interests NIP-51

Learners SHOULD be able to share their interests

Kind 10101 Good Wiki Authors & Kind 10102 Good Wiki Relays NIP-51

Learners SHOULD be able to mark authors and relays as good for wiki content. The same lists MAY be used to mark curated content (not just Wikis, but also the Publication Indexes used for curricula and courses)

Cited links

Discussion

Connect a key to comment.