{"id":"82e9da3b26a612451a93603e4aebcb156b653c7d50720e62b5a640447d6e9811","pubkey":"39398278659e2447a0e46ccb0d76dc00dc5e762e1c7d38db8fccb17743b1a29d","created_at":1787318164,"kind":30817,"tags":[["d","clestr-01"],["title","Clestr-01 (Curated Layer of Educational Stuff Transmitted by Relays)"],["alt","Nostr Implementation Possibility: Clestr-01 (Curated Layer of Educational Stuff Transmitted by Relays)"],["k","30040","Publication Index"],["k","30041","Publication Content"],["k","30818","Wiki Content"],["client","NostrHub"]],"content":"# Clestr-01 (Curated Layer of Educational Stuff Transmitted by Relays)\n\n## What this tries to solve\n\nFree educational content exists everywhere on the internet, but is not well\norganized. Dedicated websites like Khan Academy, edX, Coursera, and MIT\nOpenCourseWare host and organize their own centralized free content, but each\nremains disparate from one-another. Platforms like YouTube, Medium, and\nSubstack contain a mix of educational content and entertainment (which can be\ndistracting). Search engines help users find individual pieces of content, and\npeople and corporations can organize and curate that content via existing\nplatforms, but those lack harmony. Clestr is a protocol built on Nostr to\naddress these pain points and create an open method for organizing, curating,\nand collaborating on new and existing educational content on the internet.\n\n## Vision\n\n- Anyone can curate their own learning pathways and share with others\n- The \"best\" individual content from different sources can be combined to\n  provide a complete curriculum.\n- Content on the same topic by different creators can be organized as\n  alternatives that may be better fit for people with different needs or\n  learning styles\n- Users maintain control over their experience (no unwanted vying for attention)\n- WoT (Web of Trust) allows users to build reliable decentralized networks of\n  skills, endorsements, and content\n- The protocol can act as a layer on top of a user's browser experience, giving\n  them access to curation tools wherever they are\n\n## Protocol Notice\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\nNOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\",\n\"MAY\", and \"OPTIONAL\" in this document are to be interpreted as\ndescribed in [BCP 14 RFC2119 RFC8174][] when, and only when, they\nappear in all capitals, as shown here.\n\n## Nostr Relay\n\nMUST serve a [NIP-01][] compliant nostr relay at `/`.\n\nMAY reject or delete events for generic SPAM prevention reasons or curation eg.\nWoT, whitelist, user bans and banned topics up to the relay's discretion.\n\nIt is RECOMMENDED that the relay implement [NIP-50][] (Search)\n\n## Client Behavior\n\nThe client MAY operate as a web browser plugin, a standalone app, or a website\nwith embedded & linked content.\n\nSHOULD implement the following for complete feature set:\n\n- [NIP-02][] (Follow List)\n- [NIP-19][] (bech32-encoded entities)\n- [NIP-22][] (Commenting)\n- [NIP-23][] (Long Form Content)\n- [NIP-25][] (Reactions)\n- [NIP-50][] (Search Capability)\n- [NIP-51][] (Lists)\n- [NIP-54][] (Wiki)\n- [NIP-58][] (Badges)\n- [NIP-71][] (Video Events)\n- [NIP-73][] (External Content IDs)\n- [NIP-84][] (Highlights)\n- [NKBIP-01][] (Curated Publications)\n\nMAY implement:\n\n- [NIP-37][] (Drafts)\n- [NIP-GRAPEVINE-API][] (Grapevine WoT)\n\nMany of these protocols are broadly supported by other clients which makes\nclestr adaptable to support and render content produced by other clients\nwithout modification.\n\n### Client UX Example Implementation Ideas\n\n#### Client A - Browser Plugin\n\nUsers interact with their browser as usual. When visiting videos and webpages\nacross the internet the plugin MAY search relays to see if the current page has\nbeen referenced in any courses/curricula and render or inform the\nuser of this. As users interact with the page they may decide to mark the\ncontent as completed, or view it in the context of the surrounding course/\ncurricula. They could open it up to see other user's\ncomments on the external link or the curated learning paths.\n\n#### Client B - Webapp or Desktop app\n\nRather than overlaying the live web like the browser plugin, this client pulls\nreferenced content into a Clestr-controlled surface. When a learning path\nreferences an external URL (a video, article, or interactive page), the client\nrenders it in a sandboxed iframe with Clestr controls layered around it —\nmark-complete, highlight, and comment affordances drawn from the surrounding\ncourse or curriculum. Because many sites refuse embedding via X-Frame-Options\nor a CSP frame-ancestors directive, the client MUST detect a blocked frame and\nfall back to opening the resource in a new tab while still displaying the\nClestr context (position in the path, prerequisites, peer comments) alongside\nthe link. Untrusted embeds SHOULD carry a restrictive sandbox attribute. Where\nClient A annotates the open web in place, Client B brings the web into a\ncurated reading environment — the same events and trust graph drive both.\n\n### Curation Layer\n\nClients SHOULD author new 30041/30818 content in Djot (See [NIP-54][]'s choice\nfor reasoning).\n\nClients SHOULD also parse AsciiDoc because [NKBIP-01][] 30041 in the wild uses it.\n\nClients MUST resolve both wikilink conventions — [NIP-54][] Djot\nreference-style `[term][]` and [NKBIP-01][] double-bracket `[[term]]` — to kind\n30040/30041/30818 by normalized `d` tag.\n\nUsers SHOULD curate or create organized educational content in the form of\ncurricula/courses and in a combination of kind 30040/30041.\n\nClients MUST implement creation and rendering of the `course` and `curriculum`\npublication indices & content.\n\n#### URL Normalization for External Content\n\nWhen matching the user's current location against externally addressed content\n([NIP-73][]) and when authoring `r`/`i` references, clients SHOULD apply\nbest-effort normalization so the same resource resolves to the same address\nregardless of how the user arrived at it. The same normalization routine SHOULD\nbe used for both matching and authoring, so that a reader and an author\nindependently arrive at the same identifier.\n\nClients SHOULD:\n\n- Lowercase the scheme and host, prefer `https`, drop default ports\n  (`:80`/`:443`), and strip a trailing dot on the host.\n- Strip known tracking and session parameters (e.g. `utm_*`, `fbclid`,\n  `gclid`, `mc_eid`, `igshid`, `ref`, `ref_src`).\n- Remove the URL fragment unless it is known to be content-identifying.\n- Apply platform-specific canonicalization for well-known hosts, collapsing\n  equivalent forms to a single identifier — e.g. resolving\n  `youtube.com/watch?v=ID`, `youtu.be/ID`, `youtube.com/shorts/ID`, and\n  `youtube.com/embed/ID` to the same video, and where [NIP-73][] defines a\n  dedicated identifier kind for that platform, addressing by that ID (`i`)\n  rather than the raw URL (`r`).\n\nClients SHOULD preserve query parameters that are content-identifying (e.g.\n`v=` on YouTube) and SHOULD NOT reorder or alter parameters whose semantics\nthey do not recognize. Clients MAY retain the original, pre-normalized URL\nalongside the normalized identifier for display and linking.\n\nBecause normalization is necessarily incomplete, clients SHOULD treat a missing\nmatch as \"no curation found\" rather than authoritative, and MAY fall back to\nhost-level or fuzzy lookups to surface related content.\n\n#### Kind 1985 Labels [NIP-32][]\n\nUse is up to the discretion of the client and the user, but they MAY for\nexample use them to categorize content according to an ontology or\nclassification like the Dewey Decimal Classification, [Universal Decimal\nClassification][UDC], [Wikipedia-style category tree\ntaxonomy][wiki-categorization], [Thema Subject Categories][thema]\n\nLabels MAY also be used to classify content by educational goals like [Blooms\nTaxonomy][].\n\ne.g.\n\n```json\n[\"L\", \"blooms_taxonomy\"],\n[\"l\", \"understand\", \"blooms_taxonomy\"],\n```\n\n#### Kind 30004, 30005, 30006 Curation Sets [NIP-51][]\n\nSHOULD avoid these kinds in preference of kinds 30040 and 30041 for curation.\n\nClients MAY still choose to provide these, but they SHOULD note the intended\nuses and differences.\n\n#### Kind 30009 Badge Definition [NIP-58][]\n\nSHOULD be used to define skill competency badges that users can issue to\neachother\n\nSHOULD be used to define milestone or course completion badges that users can\nself-assign and assign to eachother. Milestones may include things like\ncapstone projects, diplomas, degrees, and certifications to name a few.\n\n#### Kind 30023 Long-form [NIP-23][] (Blogs / Articles)\n\nClients MAY implement authoring events of this kind.\n\nUsers MAY create educational content from events of this kind.\n\n#### Kind 30040 Publication Index [NKBIP-01][]\n\n- MUST allow the following list of referenced event kinds:\n\n  - 30023 (long-form content)\n  - 30040 (nested hierarchical Publication Index)\n  - 30041 (publication content)\n  - 30818 (Wiki content)\n\n- SHOULD use the `type` tags:\n\n  - `course` for collection of content that represents a full course (e.g.\n    Plumbing 101 - Intro to plumbing)\n  - `curriculum` for a nested curriculum of courses and content (e.g. Computer\n    Science - Video Game Development Track)\n\n- Within kind 30040, `q` denotes a prerequisite reference.\n\n- MAY contain one or more `q` tags to specify required/prerequisite content by\n  their normalized `d` tag according to [NIP-54][] and optionally the level of\n  proficiency required (short note like \"basic proficiency\" or blooms taxonomy\n  level)\n\n- SHOULD allow `defer` markers like wiki-events in [NIP-54][]\n\nExample event:\n\n```json\n{\n  \"id\": \"<event_id>\",\n  \"pubkey\": \"<curator_pubkey>\",\n  \"created_at\": 1730000000,\n  \"kind\": 30040,\n  \"tags\": [\n    [\"d\", \"mig-welding-101-by-acme-trades\"],\n    [\"title\", \"MIG Welding 101\"],\n    [\"type\", \"course\"],\n    [\"summary\", \"An introductory course on MIG welding, from machine setup to your first structural welds.\"],\n    [\"auto-update\", \"ask\"],\n\n    [\"q\", \"shop-safety\"],\n    [\"q\", \"using-a-wrench\", \"basic proficiency\"],\n\n    [\"a\", \"30041:<author_pubkey>:mig-welding-101-intro\", \"wss://relay.example.com\", \"<event_id_1>\"],\n    [\"a\", \"30041:<author_pubkey>:mig-welding-101-machine-setup\", \"wss://relay.example.com\", \"<event_id_2>\"],\n    [\"a\", \"30040:<author_pubkey>:mig-welding-101-first-welds\", \"wss://relay.example.com\", \"<event_id_3>\"],\n\n    [\"p\", \"<original_author_pubkey>\"],\n    [\"E\", \"<original_event_id>\", \"wss://relay.example.com\", \"<original_author_pubkey>\"],\n    [\"source\", \"https://acmetrades.example.com/courses/mig-101\"],\n    [\"version\", \"2nd edition\"]\n  ],\n  \"content\": \"\",\n  \"sig\": \"<event_signature>\"\n}\n```\n\nA client builds the prerequisite graph by walking `q` edges: for each tag,\nresolve the `d` tag to a publication (via WoT among the alternatives), then\nrecurse into that publication's own `q` tags. Each node is keyed by normalized\n`d` tag, so a skill reached by several paths (e.g. \"shop-safety\" required by\nmany courses) is **deduped** to one node. The client MUST guard against\n**cycles** — a malformed `q` loop must break, not hang — and MAY topologically\nsort the result to suggest a learning order. Crucially, prereqs render in a\n_different_ place from `a` content: the `a` list is the reader/chapter view,\nwhile `q` edges render as a prerequisite panel or as upstream nodes in a graph\nview. An index with only references and empty `content` (a bare map) SHOULD\ndefault to the graph view; a content-bearing index defaults to the reader view.\n\nAs defined in [NKBIP-01][] the `p`/`E`/`source`/`version` tags credit and link\nthe original work this course was forked from; omit them for an original.\n\n#### Kind 30041 Publication Content [NKBIP-01][]\n\n- SHOULD use [NIP-73][] tags for externally addressed content in which case the\n  `content` field is optional, which if specified, acts as summary or description\n  of the addressed content.\n\nNOTE: Wrapping externally addressed content via [NIP-73][] in a kind 30041,\nallows it to be queryable by its [NIP-54][] formatted `d` tag and be compared to\nother similar content\n\n#### Kind 30818 Wiki Content [NIP-54][] (Descriptions, Encyclopedia, WikiHow)\n\nClients MUST implement creation and rendering of wiki content. Including\nrendering wikilinks to kind 30040 and 30041 content.\n\nUsers MAY create educational content found in events of this kind.\n\n#### Clestr Wikilinks\n\nClients MUST be able to render wikilinks (as described in [NIP-54][]) that can\nreference the following kind 30040, 30041, and 30818 by d-tag.\n\nClient SHOULD show alternatives when different users have created entries for\nthe same d-tag. See [NIP-54][] \"How to decide what article to display\"\n\n### Web of Trust\n\nIf available, [Grapevine WoT APIs][NIP-GRAPEVINE-API] MAY be used to filter\ncontent by trustworthiness.\n\nIt is RECOMMENDED to implement trust in the following order or precedence:\n\n- [NIP-54][] `defer` tag (for kind 30818/30040)\n- [Grapevine WoT score][NIP-GRAPEVINE-API] if available\n- [NIP-58][] kind 8 badge awards from trusted issuers\n- [NIP-51][] kind 10101 /10102 Good wiki authors and relays\n- [NIP-51][] kind 30000 follow sets\n- [NIP-02][] kind 3 follow lists\n- [NIP-25][] kind 7 `+` reactions\n- [NIP-25][] + [NIP-73][] kind 17 external content reactions\n\nRaw [NIP-25][] reaction counts can be gamed, and thus SHOULD only count when\nreachable through the user's trust graph, not globally.\n\n### Learner Experience\n\n#### Kind 1985 Labels [NIP-32][]\n\nLearners SHOULD be able to mark learning path items as complete by assigning\nlabels namespaced under `clestr`, e.g. `in-progress`, `complete`\n\nClient SHOULD allow users the option to store progress as a [NIP-59][] Gift Wrap\nevent for keeping kind 1985 private\n\n#### Kind 9802 Highlights [NIP-84][]\n\n(of nostr content and external URLs, with optional context and comments)\n\nLearners SHOULD be able to highlight content on the internet and content hosted\nby nostr for later referencing.\n\n#### Kind 10003 Bookmarks & 30003 Bookmark Sets [NIP-51][]\n\nLearners SHOULD be able to mark their enrolled courses and learning paths\nby bookmarking them (either their global bookmark, or a defined set)\n\n#### Kind 10008 Profile Badge [NIP-58][]\n\nLearners SHOULD be able to don their achievements\n\n#### Kind 10015 Interests [NIP-51][]\n\nLearners SHOULD be able to share their interests\n\n#### Kind 10101 Good Wiki Authors & Kind 10102 Good Wiki Relays [NIP-51][]\n\nLearners SHOULD be able to mark authors and relays as good for wiki content.\nThe same lists MAY be used to mark curated content (not just Wikis, but also\nthe Publication Indexes used for curricula and courses)\n\n---\n\n[NIP-01]: https://nostrhub.io/nip/01\n[NIP-02]: https://nostrhub.io/nip/02\n[NIP-19]: https://nostrhub.io/nip/19\n[NIP-22]: https://nostrhub.io/nip/22\n[NIP-23]: https://nostrhub.io/nip/23\n[NIP-25]: https://nostrhub.io/nip/25\n[NIP-32]: https://nostrhub.io/nip/32\n[NIP-37]: https://nostrhub.io/nip/37\n[NIP-50]: https://nostrhub.io/nip/50\n[NIP-51]: https://nostrhub.io/nip/51\n[NIP-54]: https://nostrhub.io/nip/54\n[NIP-58]: https://nostrhub.io/nip/58\n[NIP-59]: https://nostrhub.io/nip/59\n[NIP-71]: https://nostrhub.io/nip/71\n[NIP-73]: https://nostrhub.io/nip/73\n[NIP-84]: https://nostrhub.io/nip/84\n\n[NKBIP-01]: https://nostrhub.io/naddr1qvzqqqrcvypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqqyxu6mzd9cz6vp3tn64lg\n[NIP-GRAPEVINE-API]: https://nostrhub.io/naddr1qvzqqqrcvypzqlxr9zsgmke2lhuln0nhhml5eq6gnluhjuscyltz3f2z7v4zglqwqqgku6ts94nhyctsv4mxjmn994shq6g774x0d\n\n[wiki-categorization]: https://en.wikipedia.org/wiki/Wikipedia:Categorization\n[UDC]: https://en.wikipedia.org/wiki/Universal_Decimal_Classification\n[thema]: https://ns.editeur.org/thema/en\n[Blooms Taxonomy]: https://en.wikipedia.org/wiki/Bloom%27s_taxonomy\n\n[BCP 14 RFC2119 RFC8174]: https://www.rfc-editor.org/info/bcp14/","sig":"6da07702ea527e496729be6208df5dc2bcaf099a96ad6989ca412d8b15695f9df14116a6eb6b937097b8efa0a3a0b81ed74fc213a3cfa9fb38b4ff86caca7176"}