{"id":"52fc7d67f2977578ed6896940ffd591d6ae72988bf4b041beab20c499da1359e","pubkey":"da19f1cd34beca44be74da4b306d9d1dd86b6343cef94ce22c49c6f59816e5bd","created_at":1774618387,"kind":30817,"tags":[["title","NIP-MENTORSHIP: Mentorship Pipelines & Training Progression"],["k","composition-guide"],["d","nip-mentorship"]],"content":"NIP-MENTORSHIP\n==============\n\nMentorship Pipelines & Training Progression\n----------------------------------------------\n\n`draft` `optional`\n\nThis NIP defines a set of tags for recording mentorship relationships, training progression, supervision levels, apprenticeship pipelines, and continued professional development (CPD) on Nostr. No new event kinds are required; mentorship is expressed through optional tags on addressable endorsement events.\n\n> **Standalone.** This NIP works independently on any Nostr application.\n\n> **Design principle.** Mentorship is a specialised form of endorsement. Rather than creating a separate kind, this NIP defines optional tags that mentors use to record training relationships. This keeps the protocol minimal whilst enabling rich mentorship networks on any addressable event an application uses for endorsements.\n\n## Motivation\n\nMany professional domains face a **cold-start problem**: new entrants have no reputation, no completed work history, and no reviews. Existing practitioners are reluctant to recommend unknown quantities. The result is a barrier to entry that concentrates work among established providers and discourages new talent.\n\nTraditional solutions (formal qualifications, institutional references) are slow, expensive, and not portable across platforms. Nostr peer endorsements partially address this, but lack the structure needed for **training relationships**:\n\n- **Heritage crafts** -- master craftspeople train apprentices over 3--4 years; the training lineage is professionally significant\n- **Healthcare** -- clinical supervision is a regulatory requirement; supervisors must attest to specific competencies\n- **Legal services** -- pupillage and training contracts require structured progression records\n- **Education** -- newly qualified teachers require mentored induction periods\n- **Construction** -- trade apprenticeships (CITB, DOL Registered Apprenticeships, German Meister system) progress through defined stages\n- **Therapy & counselling** -- clinical supervision networks with modality-specific oversight\n- **Cybersecurity** -- mentor-attested skill progression (e.g. from supervised testing to independent engagements)\n- **Traditional crafts** -- Japanese shokunin apprenticeships, German dual education programmes, and similar master-apprentice systems worldwide\n\nNIP-MENTORSHIP defines optional tags that transform a simple endorsement into a rich training progression record -- portable, verifiable, and discoverable across any Nostr application.\n\n## Cross-Domain Evidence\n\nThis NIP was developed after identifying demand across multiple unrelated domains spanning several categories:\n\n| Category | Examples |\n| -------- | -------- |\n| Built environment | Heritage conservation master-apprentice chains; retrofit coordinator training through defined role progressions |\n| Education | Cascade mentor networks (one qualified instructor training multiple trainees); tutor-student relationships with CPD recording; early years practitioner induction mentoring |\n| Construction | Trade apprenticeships (UK CITB, US DOL Registered Apprenticeships, German Meister/Geselle system) |\n| Healthcare / social services | Clinical supervision networks; veteran peer support; SEND education mentoring across trusts |\n| Creative arts | Craftsperson-to-learner progression tracking (pottery, weaving, metalwork, woodcraft); therapeutic supervision pathways |\n| Open source | Maintainer-to-contributor mentorship; coding bootcamp progression tracking; Google Summer of Code-style mentorship records |\n| Traditional crafts (international) | Japanese shokunin (craftsperson) apprenticeships; German dual education system; French Compagnons du Devoir journeyman programmes |\n\nThese domains span built environment, education, construction, social services, creative arts, healthcare, technology, and traditional crafts -- confirming the pattern is domain-agnostic.\n\n## Kind\n\nThis NIP does not define new event kinds. It defines mentorship-specific tags that MAY be used on:\n\n- [NIP-TRUST](./NIP-TRUST.md) kind 30517 (Provider Endorsement) events -- currently a draft NIP\n- Any addressable event kind that an application uses for endorsements\n\nThe tags are the contribution; they are not bound to a specific kind.\n\n| kind  | description             | defined in  | status |\n| ----- | ----------------------- | ----------- | ------ |\n| 30517 | Provider Endorsement    | NIP-TRUST   | draft  |\n\nApplications that do not use NIP-TRUST MAY apply these tags to their own addressable endorsement events by following the tag definitions below. The `endorsement_type` tag value `\"mentorship\"` signals that the event carries mentorship semantics regardless of the event kind used.\n\n---\n\n## Endorsement Tags\n\nWhen an endorsement event represents a mentorship relationship, the following tags MAY be included. The only tag required to signal mentorship semantics is `endorsement_type` with value `\"mentorship\"`.\n\n### Mentorship Endorsement Example\n\n```json\n{\n    \"kind\": 30517,\n    \"pubkey\": \"<mentor-hex-pubkey>\",\n    \"created_at\": 1698770000,\n    \"tags\": [\n        [\"d\", \"<mentor-pubkey>:<mentee-pubkey>:stonemasonry\"],\n        [\"p\", \"<mentee-hex-pubkey>\"],\n        [\"alt\", \"Mentorship endorsement: stonemasonry apprenticeship, stage 3\"],\n        [\"domain\", \"heritage-skills\"],\n        [\"endorsement_type\", \"mentorship\"],\n        [\"mentorship_type\", \"apprenticeship\"],\n        [\"mentorship_stage\", \"3\"],\n        [\"mentorship_duration_months\", \"36\"],\n        [\"mentorship_start\", \"1630454400\"],\n        [\"supervision_level\", \"partial_supervision\"],\n        [\"supervised_work\", \"true\"],\n        [\"competencies\", \"lime_pointing\", \"demonstrated\"],\n        [\"competencies\", \"stone_carving\", \"developing\"],\n        [\"competencies\", \"arch_repair\", \"introduced\"],\n        [\"cpd_hours\", \"240\"],\n        [\"training_institution\", \"SPAB\"],\n        [\"qualification_ref\", \"NVQ Level 3 Heritage Stonemasonry\"]\n    ],\n    \"content\": \"Sarah has completed 3 years of apprenticeship under my supervision. She demonstrates excellent lime pointing skills and growing competence in stone carving. She is ready for partially supervised site work on Grade II buildings.\",\n    \"id\": \"<32-byte-hex>\",\n    \"sig\": \"<64-byte-hex>\"\n}\n```\n\n### Endorsement Type\n\nNIP-MENTORSHIP defines one `endorsement_type` tag value:\n\n| Type | Meaning |\n| ---- | ------- |\n| `mentorship` | \"I am training or have trained this person\" -- structured training relationship |\n\n### Tag Reference\n\n| Tag | Requirement | Description |\n| --- | ----------- | ----------- |\n| `endorsement_type` | REQUIRED | Must be `\"mentorship\"` to signal mentorship semantics |\n| `p` | REQUIRED | Hex pubkey of the mentee |\n| `d` | REQUIRED | Unique identifier for the mentorship relationship (for addressable replacement) |\n| `mentorship_type` | RECOMMENDED | Nature of the training relationship (see below) |\n| `mentorship_stage` | RECOMMENDED | Current stage or year of the training programme |\n| `supervision_level` | RECOMMENDED | Current level of supervision the mentee requires (see below) |\n| `supervised_work` | RECOMMENDED | Boolean (`\"true\"` / `\"false\"`); whether the mentee may take on supervised work |\n| `competencies` | OPTIONAL | Repeatable. Format: `[\"competencies\", \"<skill_name>\", \"<assessment>\"]` |\n| `mentorship_duration_months` | OPTIONAL | Total duration of the mentorship relationship in months |\n| `mentorship_start` | OPTIONAL | Unix timestamp when the mentorship began |\n| `cpd_hours` | OPTIONAL | Cumulative CPD hours completed under this mentor's supervision |\n| `training_institution` | OPTIONAL | Name of the training institution, guild, or professional body |\n| `qualification_ref` | OPTIONAL | Reference to a formal qualification being pursued or completed |\n| `domain` | OPTIONAL | Application-defined domain identifier for the mentorship context |\n\n### Tag Values\n\n#### `mentorship_type`\n\n- `\"apprenticeship\"` -- formal, structured training programme with defined stages\n- `\"supervised_practice\"` -- ongoing supervised work (e.g. clinical supervision, pupillage)\n- `\"peer_mentoring\"` -- informal knowledge transfer between practitioners\n- `\"cpd_supervision\"` -- continued professional development oversight\n- `\"induction\"` -- time-limited induction period for new practitioners\n\nApplications MAY define additional values. Unknown values SHOULD be treated as informational text.\n\n#### `mentorship_stage`\n\nPlain text. Domains and applications define their own stage semantics. Examples:\n\n- `\"1\"` through `\"4\"` for a 4-year apprenticeship\n- `\"foundation\"` / `\"core\"` / `\"advanced\"` for staged programmes\n- `\"Geselle\"` / `\"Meister\"` for German trade progression\n- `\"year-1\"` / `\"year-2\"` for academic supervision\n\n#### `supervision_level`\n\nRecommended values:\n\n- `\"full_supervision\"` -- mentee works only under direct supervision\n- `\"partial_supervision\"` -- mentee may work independently on routine tasks; complex work requires supervision\n- `\"independent\"` -- mentee is assessed as competent for independent work\n- `\"supervisory\"` -- mentee is now competent to supervise others\n\nApplications MAY define additional or alternative supervision levels appropriate to their domain. Unknown values SHOULD be treated as informational text.\n\n---\n\n## Protocol Flow\n\n\n![Mentorship Progression](https://raw.githubusercontent.com/forgesworn/nip-drafts/main/images/mentorship-1.png)\n\n```mermaid\nsequenceDiagram\n    participant Mentor\n    participant Relay\n    participant Mentee\n\n    Mentor->>Relay: Publish endorsement event<br/>endorsement_type: mentorship\n    Note right of Mentor: competencies, supervision level, stage\n\n    Mentee->>Relay: Publish portfolio / evidence<br/>(application-defined)\n\n    Note over Mentor,Mentee: Progression update\n    Mentor->>Relay: Republish endorsement (same d tag)<br/>updated stage + supervision level\n```\n\n## Mentorship Chain Discovery\n\nMentorship endorsements create discoverable training lineages. A client can reconstruct a practitioner's training history by querying:\n\n```json\n[\n    {\"kinds\": [30517], \"#p\": [\"<practitioner-pubkey>\"], \"#endorsement_type\": [\"mentorship\"]},\n    {\"kinds\": [30517], \"authors\": [\"<mentor-pubkey>\"], \"#endorsement_type\": [\"mentorship\"]}\n]\n```\n\n> **Note:** The `endorsement_type` tag is a multi-letter tag and therefore not relay-indexed per NIP-01. Clients MUST post-filter results client-side.\n\nApplications using a different event kind for endorsements SHOULD substitute their kind number in the filter above.\n\n### Chain Traversal\n\n```\n  Master A\n      |\n      +-- endorses B (mentorship, stage 4, independent)\n      |       |\n      |       +-- endorses D (mentorship, stage 2, partial_supervision)\n      |       +-- endorses E (mentorship, stage 1, full_supervision)\n      |\n      +-- endorses C (mentorship, stage 3, partial_supervision)\n              |\n              +-- endorses F (mentorship, stage 1, full_supervision)\n```\n\nEach node in the chain is an endorsement event with `endorsement_type: \"mentorship\"`. The chain is acyclic; a mentee cannot endorse their own mentor (clients SHOULD reject such endorsements). The chain provides:\n\n- **Lineage verification** -- who trained whom, and for how long\n- **Quality signal** -- a mentee trained by a highly-rated mentor inherits trust weight\n- **Pipeline visibility** -- training bodies can see how many practitioners are in each stage\n\n## Supervised Work\n\nWhen `supervised_work` is `\"true\"`, the mentee is endorsed for supervised participation in work alongside their mentor. Applications MAY use mentorship relationships to gate access to supervised work opportunities. The mechanism for work assignment is application-defined.\n\nAt minimum, applications implementing supervised work SHOULD:\n\n1. **Discovery:** Surface the mentee in search results with a `\"supervised\"` indicator and a reference to their mentor's pubkey.\n2. **Attribution:** Ensure the mentor's pubkey appears alongside the mentee on any resulting work.\n3. **Progression:** Update the mentor's endorsement record to reflect completed supervised work.\n\n## Competency Framework\n\nThe `competencies` tag provides a lightweight, domain-agnostic competency tracking mechanism:\n\n| Assessment | Definition |\n| ---------- | ---------- |\n| `introduced` | The mentee has been exposed to this skill but has not practised it independently. |\n| `developing` | The mentee is practising this skill under supervision and showing improvement. |\n| `demonstrated` | The mentee has demonstrated this skill to the mentor's satisfaction on real tasks. |\n| `mastered` | The mentee is fully competent and can teach this skill to others. |\n\nCompetency names are domain-specific plain text strings. Applications MAY publish recommended competency lists for their domains.\n\n## Progression Lifecycle\n\nA typical mentorship progresses through these stages, each reflected in updated endorsement events:\n\n```\n  Stage 1: full_supervision     -> \"Learning the basics\"\n  Stage 2: full_supervision     -> \"Building core skills\"\n  Stage 3: partial_supervision  -> \"Independent routine work\"\n  Stage 4: independent          -> \"Fully competent practitioner\"\n  ---\n  supervisory                   -> \"Can now mentor others\"\n```\n\nEach stage update is published as a new event with the same `d` tag (addressable replacement). The previous assessment is replaced; clients see only the most current stage. Historical progression is visible via relay event history if available, but the protocol does not require historical tracking.\n\n## Use Cases\n\n### Academic Supervision\n\nPhD supervisors can publish mentorship endorsements for their students, recording competency assessments, publication milestones, and supervision levels. The training chain creates a discoverable academic lineage (who supervised whom), portable across institutions.\n\n### Open Source Mentoring\n\nExperienced maintainers can endorse contributors they have mentored, recording competencies (`\"code_review\"`, `\"release_management\"`, `\"security_audit\"`) and supervision levels. This creates a verifiable mentorship record that follows the contributor's Nostr identity across projects. Programmes like Google Summer of Code, Outreachy, or language-specific mentorship programmes can record structured progression on Nostr.\n\n### Clinical Supervision Networks\n\nHealthcare supervisors can publish structured endorsements recording clinical competencies, supervision hours, and progression stages. The `training_institution` and `qualification_ref` tags link to regulatory requirements (e.g. GMC revalidation, NMC preceptorship, ABMS board certification, JCAHO accreditation).\n\n### Trade Apprenticeships\n\nGuild masters, trade assessors, and mentors can publish progression records for apprentices. The `mentorship_stage` tag maps to qualification levels or apprenticeship framework stages appropriate to the jurisdiction -- NVQ levels (UK), DOL Registered Apprenticeship stages (US), Geselle/Meister progression (Germany), or Compagnons du Devoir stages (France). Employers can verify training status via Nostr queries rather than paper certificates.\n\n### Traditional Craft Apprenticeships\n\nJapanese shokunin apprenticeships, where master craftspeople train successors over decades, can record the long progression from novice to independent master. The same applies to any culture's traditional craft transmission system. The `mentorship_duration_months` and `competencies` tags capture the depth of these relationships.\n\n## Composition with Other NIPs\n\nNIP-MENTORSHIP defines tags that compose well with other Nostr specifications. All compositions below are OPTIONAL -- the core mentorship tags work independently.\n\n| NIP | Composition | Status |\n| --- | ----------- | ------ |\n| [NIP-TRUST](./NIP-TRUST.md) | Mentorship tags on kind 30517 Provider Endorsement events. Clients that do not understand mentorship tags treat them as standard endorsements (graceful degradation). | Draft NIP |\n| [NIP-EVIDENCE](./NIP-EVIDENCE.md) | Mentees may publish evidence events supporting competency claims. Applications MAY cross-reference competency tags with evidence events for stronger validation. | Draft NIP |\n| [NIP-VA](./NIP-VA.md) | Verifiable attestations may corroborate formal qualifications referenced in `qualification_ref` tags. | Draft NIP |\n| [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) | Basic protocol flow, addressable events, REQ filters | Merged |\n| [NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md) | Expiration timestamps for time-bounded endorsements | Merged |\n| [NIP-44](https://github.com/nostr-protocol/nips/blob/master/44.md) | Versioned encrypted payloads for sensitive progression data | Merged |\n\n## Why not NIP-32 (Labelling)?\n\nNIP-32 labels are lightweight metadata tags, useful for categorisation but not for structured relationships. Mentorship requires:\n\n- A **directional relationship** (mentor endorses mentee) that labels cannot express\n- **Progression state** that updates over time via addressable replacement\n- **Competency assessments** with multi-value tags that exceed label semantics\n- **Chain traversal** across mentor-mentee graphs, which requires consistent tag structure\n\nNIP-32 labels could complement mentorship endorsements (e.g. labelling a mentee as `\"heritage-craft-apprentice\"`) but cannot replace the structured tags defined here.\n\n## Why not a new Kind?\n\nA dedicated mentorship kind would fragment the endorsement graph. Mentorship is a specialised form of endorsement -- the same relationship, with richer metadata. Keeping mentorship on the same event kind as general endorsements means:\n\n- Clients that do not understand mentorship tags still see a valid endorsement\n- Reputation systems that aggregate endorsements automatically include mentorship endorsements\n- No new relay support is required\n\n## Why not NIP-58 (Badges)?\n\nNIP-58 badges are awarded artifacts -- \"you have achieved X.\" Mentorship is a living relationship that progresses over time. Key differences:\n\n- Badges are static; mentorship endorsements update via addressable replacement\n- Badges have no directional training relationship\n- Badges cannot express supervision levels, competency progression, or training pipelines\n\nBadges and mentorship endorsements are complementary: a mentee reaching `\"independent\"` supervision level might also receive a badge.\n\n## Security Considerations\n\n* **Endorsement authenticity.** Mentorship endorsements inherit standard Nostr event verification (signature checks, pubkey authentication). Applications SHOULD implement Sybil resistance; zero-history mentors carry zero weight.\n* **Mentor authority.** Applications SHOULD verify that the endorsing pubkey has genuine mentorship authority -- through completed work history, credential attestations, or recognition by a training institution.\n* **Competency inflation.** A mentor could over-rate a mentee's competencies. Applications SHOULD cross-reference competency claims with independent evidence where available. Competencies not supported by evidence carry reduced weight.\n* **Supervised work responsibility.** When `supervised_work` is `\"true\"`, the mentor assumes supervisory responsibility. Applications SHOULD make this explicit and ensure the mentor's pubkey appears on all resulting work events.\n* **Revocation.** A mentor can revoke a mentorship endorsement by publishing a new event with the same `d` tag and empty content. Clients MUST treat empty content as revoked.\n* **Privacy.** Competency assessments and training progression data may be sensitive. When privacy is required, the `content` field SHOULD be NIP-44 encrypted to the mentee and relevant parties. Tag-level data (supervision level, stage) remains discoverable for protocol functionality.\n\n## Validation Rules\n\n| Rule | Description |\n| ---- | ----------- |\n| V-ME-01 | `endorsement_type` tag MUST have value `\"mentorship\"` |\n| V-ME-02 | `p` tag MUST contain a valid 32-byte hex pubkey (the mentee) |\n| V-ME-03 | `d` tag MUST be present (addressable replacement) |\n| V-ME-04 | Event `pubkey` (the mentor) MUST NOT equal the `p` tag value (no self-mentorship) |\n| V-ME-05 | `mentorship_start` value, if present, MUST be a valid Unix timestamp less than or equal to `created_at` |\n| V-ME-06 | `competencies` tags, if present, MUST have exactly 3 values: tag name, skill name, assessment level |\n| V-ME-07 | `competencies` assessment value SHOULD be one of: `introduced`, `developing`, `demonstrated`, `mastered` |\n| V-ME-08 | `supervision_level`, if present, SHOULD be one of: `full_supervision`, `partial_supervision`, `independent`, `supervisory` |\n| V-ME-09 | Empty `content` field indicates endorsement revocation; clients MUST treat as revoked |\n\n## Test Vectors\n\n### Minimal Valid Mentorship Endorsement\n\n```json\n{\n  \"kind\": 30517,\n  \"pubkey\": \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2\",\n  \"created_at\": 1709740800,\n  \"tags\": [\n    [\"d\", \"a1b2...b2c3:stonemasonry\"],\n    [\"p\", \"b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3\"],\n    [\"endorsement_type\", \"mentorship\"]\n  ],\n  \"content\": \"I am mentoring this practitioner.\",\n  \"id\": \"<32-byte-hex>\",\n  \"sig\": \"<64-byte-hex>\"\n}\n```\n\n### Full Mentorship Endorsement\n\n```json\n{\n  \"kind\": 30517,\n  \"pubkey\": \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2\",\n  \"created_at\": 1709740800,\n  \"tags\": [\n    [\"d\", \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2:b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3:stonemasonry\"],\n    [\"p\", \"b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3\"],\n    [\"alt\", \"Mentorship endorsement: stonemasonry apprenticeship, stage 3\"],\n    [\"domain\", \"heritage-skills\"],\n    [\"endorsement_type\", \"mentorship\"],\n    [\"mentorship_type\", \"apprenticeship\"],\n    [\"mentorship_stage\", \"3\"],\n    [\"mentorship_duration_months\", \"36\"],\n    [\"mentorship_start\", \"1630454400\"],\n    [\"supervision_level\", \"partial_supervision\"],\n    [\"supervised_work\", \"true\"],\n    [\"competencies\", \"lime_pointing\", \"demonstrated\"],\n    [\"competencies\", \"stone_carving\", \"developing\"],\n    [\"cpd_hours\", \"240\"],\n    [\"training_institution\", \"SPAB\"],\n    [\"qualification_ref\", \"NVQ Level 3 Heritage Stonemasonry\"]\n  ],\n  \"content\": \"Sarah has completed 3 years of apprenticeship under my supervision. She demonstrates excellent lime pointing skills and growing competence in stone carving.\",\n  \"id\": \"<32-byte-hex>\",\n  \"sig\": \"<64-byte-hex>\"\n}\n```\n\n### Invalid: Self-Mentorship (V-ME-04)\n\n```json\n{\n  \"kind\": 30517,\n  \"pubkey\": \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2\",\n  \"tags\": [\n    [\"d\", \"self-mentorship\"],\n    [\"p\", \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2\"],\n    [\"endorsement_type\", \"mentorship\"]\n  ],\n  \"content\": \"I endorse myself.\"\n}\n```\n\nClients MUST reject this event: `pubkey` equals `p` tag value.\n\n### Revocation (V-ME-09)\n\n```json\n{\n  \"kind\": 30517,\n  \"pubkey\": \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2\",\n  \"created_at\": 1710000000,\n  \"tags\": [\n    [\"d\", \"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2:b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3:stonemasonry\"],\n    [\"p\", \"b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3\"],\n    [\"endorsement_type\", \"mentorship\"]\n  ],\n  \"content\": \"\"\n}\n```\n\nEmpty content with the same `d` tag revokes the previous mentorship endorsement.\n\n## Dependencies\n\nRequired:\n\n* [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md): Basic protocol flow, addressable events\n\nOptional:\n\n* [NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md): Expiration timestamps (time-bounded endorsements)\n* [NIP-44](https://github.com/nostr-protocol/nips/blob/master/44.md): Versioned encrypted payloads (sensitive progression data)\n\nOptional composition (draft NIPs):\n\n* [NIP-TRUST](./NIP-TRUST.md): Provider Endorsement kind 30517 -- one possible carrier event for mentorship tags (currently a draft NIP)\n* [NIP-EVIDENCE](./NIP-EVIDENCE.md): Supporting evidence for competency claims (currently a draft NIP)\n* [NIP-VA](./NIP-VA.md): Verifiable attestations for formal qualification references (currently a draft NIP)\n\n## Reference Implementation\n\nNo public reference implementation exists yet. Implementors SHOULD refer to the tag definitions above.\n\nA minimal implementation requires:\n\n1. A Nostr client that supports publishing and querying addressable events.\n2. Mentorship chain traversal logic: querying endorsements by `endorsement_type: \"mentorship\"` and building the mentor-mentee graph.\n3. Optionally, supervised work discovery: surfacing mentees with `supervised_work: \"true\"` alongside their mentor's profile in search results.","sig":"acfae1bdeb55efbbaabd06e094910838d1331d1c40b4d2ae4b6e8ad3b58a59ca228f861e2d1f009dcdd6adebe335766b8531359469392bc79bd7abd0acb1193a"}