{"id":"9af7dc4ad5f2289721a8a7ddf127f6bc830268f9d4e36acf995649decaf0d0a1","pubkey":"bdc21f93b1e2cb75608cecd7a0a00a779779d9367dc9798bd9f213f06c95bc48","created_at":1787819083,"kind":30817,"tags":[["d","edufeed-vocab"],["title","NIP-VOCAB"],["k","39737","ConceptScheme"],["k","39738","Concept"],["k","39739","Collection"],["k","39736","ConceptScheme draft"],["k","39735","Concept draft"],["k","39734","Collection draft"]],"content":"NIP-VOCAB\n=========\n\nVocabularies\n------------\n\n`draft` `optional`\n\nThis NIP defines a system for publishing controlled vocabularies, taxonomies, thesauri, and classification schemes as Nostr events. It is inspired by [SKOS](https://www.w3.org/TR/skos-reference/) (Simple Knowledge Organization System) but designed natively for Nostr.\n\n## Motivation\n\nNostr has labeling infrastructure ([NIP-32](32.md)) and domain-specific classification patterns ([NIP-AMB](AMB.md), [NIP-35](35.md)), but no general-purpose mechanism for publishing, discovering, and using shared controlled vocabularies on the protocol itself. Vocabulary definitions currently live on external web servers. This NIP brings them onto Nostr, making them decentralized, discoverable, and maintainable by anyone.\n\n## Event Kinds\n\nThis NIP uses six addressable event kinds — one per entity type, with a parallel draft kind following NIP-23's pattern:\n\n| Entity         | Published | Draft  |\n|----------------|-----------|--------|\n| ConceptScheme  | `39737`   | `39736` |\n| Concept        | `39738`   | `39735` |\n| Collection     | `39739`   | `39734` |\n\n*Published kinds increment (39737 → 39738 → 39739); draft kinds decrement (39736 → 39735 → 39734) so the `39737` / `39736` pair from an earlier revision of this NIP is preserved.*\n\nDistinct kinds let relays (which only index single-letter tags per NIP-01) return just the entity type a client asked for. The `[\"type\", ...]` tag is retained for human readability and secondary validation but carries no query semantics.\n\nClients displaying *published* vocabularies MUST filter by published kinds and MUST NOT surface draft kinds as published.\n\n## Concept Scheme\n\nA concept scheme represents a vocabulary, taxonomy, or classification system.\n\nThe Nostr event itself provides standard metadata: `created_at` serves as the publication/modification timestamp and `pubkey` identifies the publisher. Publishers MAY add a `version` tag for explicit versioning.\n\n```jsonc\n{\n  \"kind\": 39737,\n  \"tags\": [\n    [\"d\", \"schulfaecher\"],\n    [\"type\", \"ConceptScheme\"],\n    [\"prefLabel\", \"Schulfächerliste\", \"de\"],\n    [\"prefLabel\", \"School Subject List\", \"en\"],\n    [\"description\", \"Classification of subjects taught in German schools\", \"en\"],\n    [\"a\", \"39738:<pubkey>:s10\", \"<relay>\", \"hasTopConcept\"],\n    [\"a\", \"39738:<pubkey>:s20\", \"<relay>\", \"hasTopConcept\"],\n    // optional: bridge to external URI\n    [\"i\", \"http://w3id.org/kim/schulfaecher/\"]\n  ],\n  \"content\": \"\"\n}\n```\n\n### Concept Scheme Tags\n\n| Tag | Value | Required | Description |\n|-----|-------|----------|-------------|\n| `d` | identifier | yes | Stable identifier for the scheme |\n| `type` | `ConceptScheme` | yes | Distinguishes from Concept and Collection events |\n| `prefLabel` | label, language | yes | Preferred display label. Third element is a BCP47 language tag. There MUST be at most one `prefLabel` per language. Repeat for multiple languages |\n| `description` | text, language | no | Description of the scheme. Third element is a BCP47 language tag |\n| `a` | coordinates, relay, `hasTopConcept` | yes* | References to top-level concepts. Required if the scheme has a hierarchy |\n| `i` | external URI | no | Bridge to an external URI identifier for this scheme |\n\n## Concept\n\nA concept represents a single term, category, or idea within a vocabulary.\n\n```jsonc\n{\n  \"kind\": 39738,\n  \"tags\": [\n    [\"d\", \"s1017\"],\n    [\"type\", \"Concept\"],\n    [\"prefLabel\", \"Mathematik\", \"de\"],\n    [\"prefLabel\", \"Mathematics\", \"en\"],\n    [\"altLabel\", \"Mathe\", \"de\"],\n    [\"altLabel\", \"Maths\", \"en\"],\n    [\"notation\", \"s1017\"],\n    // scheme membership\n    [\"a\", \"39737:<pubkey>:schulfaecher\", \"<relay>\", \"inScheme\"],\n    // hierarchical relations (non-top concept — has broader)\n    [\"a\", \"39738:<pubkey>:s10\", \"<relay>\", \"broader\"],\n    [\"a\", \"39738:<pubkey>:s101701\", \"<relay>\", \"narrower\"],\n    // associative relation\n    [\"a\", \"39738:<pubkey>:s1018\", \"<relay>\", \"related\"],\n    // optional: bridge to external URI\n    [\"i\", \"http://w3id.org/kim/schulfaecher/s1017\"]\n  ],\n  \"content\": \"Mathematics as taught in German school curricula\"\n}\n```\n\n### Concept Tags\n\n| Tag | Value | Required | Description |\n|-----|-------|----------|-------------|\n| `d` | identifier | yes | Stable identifier for the concept |\n| `type` | `Concept` | yes | Distinguishes from ConceptScheme and Collection events |\n| `prefLabel` | label, language | yes | Preferred display label. Third element is a BCP47 language tag. There MUST be at most one `prefLabel` per language |\n| `altLabel` | label, language | no | Alternative label (synonym, abbreviation). Third element is a BCP47 language tag |\n| `hiddenLabel` | label, language | no | Hidden label for search indexing (catches misspellings, legacy terms). Not displayed to users |\n| `notation` | code | no | Classification code or notation within the scheme |\n| `a` | coordinates, relay, `inScheme` | yes | Every concept MUST reference its containing ConceptScheme |\n| `a` | coordinates, relay, `broader` | yes* | Required for non-top concepts. Top concepts omit this and are referenced via `hasTopConcept` on the scheme |\n| `a` | coordinates, relay, `topConceptOf` | no | Top concepts SHOULD include this marker pointing back to their scheme |\n| `a` | coordinates, relay, `narrower` | yes* | Required if the concept has children. The child MUST have a corresponding `broader` tag |\n| `a` | coordinates, relay, marker | no | Other relations: `related`, mapping markers (see [Relations](#relations)) |\n| `r` | external URI, marker | no | Mappings to external vocabularies (see [External Mappings](#external-mappings)) |\n| `i` | external URI | no | Bridge to an external URI identifier for this concept |\n| `definition` | text, language | no | Formal definition. Third element is a BCP47 language tag. The `content` field serves as the primary definition; `definition` tags provide additional translations |\n| `scopeNote` | text, language | no | Intended usage scope. Third element is a BCP47 language tag |\n| `example` | text, language | no | Usage example. Third element is a BCP47 language tag |\n| `note` | text, language | no | Generic documentation note. Third element is a BCP47 language tag |\n\nA concept MAY belong to multiple concept schemes by including multiple `inScheme` tags.\n\nThe `content` field SHOULD contain the concept's definition or scope note.\n\n> **Note:** SKOS also defines `historyNote`, `changeNote`, and `editorialNote`. These are intentionally omitted — Nostr's addressable event replacement provides implicit version history.\n\n### Label Integrity\n\nThe following constraints MUST be observed:\n\n- At most one `prefLabel` per language per concept\n- `prefLabel`, `altLabel`, and `hiddenLabel` are pairwise disjoint: the same literal MUST NOT appear as more than one label type on the same event\n\n## Collection\n\nA collection is a meaningful grouping of concepts within a scheme, used for organizational purposes.\n\n```jsonc\n{\n  \"kind\": 39739,\n  \"tags\": [\n    [\"d\", \"bachelor-programs\"],\n    [\"type\", \"Collection\"],\n    [\"prefLabel\", \"Bachelor Programs\", \"en\"],\n    [\"prefLabel\", \"Bachelor-Studiengänge\", \"de\"],\n    [\"a\", \"39737:<pubkey>:schulfaecher\", \"<relay>\", \"inScheme\"],\n    [\"a\", \"39738:<pubkey>:civil-eng\", \"<relay>\", \"member\"],\n    [\"a\", \"39738:<pubkey>:mech-eng\", \"<relay>\", \"member\"]\n  ],\n  \"content\": \"\"\n}\n```\n\nCollections are organizational only. Semantic relations (`broader`, `narrower`, `related`) MUST NOT be used on or target Collection events.\n\n> **Note:** SKOS also defines `OrderedCollection` for collections with meaningful ordering. This is intentionally omitted from this NIP for simplicity and may be specified in a future extension.\n\n## Drafts\n\nEach published kind has a matching draft kind with identical tag structure:\n\n- `kind:39736` — ConceptScheme draft\n- `kind:39735` — Concept draft\n- `kind:39734` — Collection draft\n\nDrafts use the same `[\"d\", ...]` identifier as their eventual published counterpart. Clients SHOULD treat drafts as private-to-the-author by default (e.g., publish only to the author's outbox relays). When publishing a draft as final, clients SHOULD delete the draft via NIP-09 and publish a new event under the corresponding published kind.\n\n`a` tag references between vocabulary events SHOULD use the **published** kind prefix of the target even when the target currently exists only as a draft — i.e., a draft Concept whose `inScheme` points at a still-unpublished ConceptScheme SHOULD reference it as `39737:<pubkey>:<d>`, not `39736:<pubkey>:<d>`. This way references resolve automatically the moment the target is published. A client rendering a reference whose target has not yet been published MAY show it as an unresolved reference.\n\n`published_at` remains OPTIONAL metadata on published events (for preserving first-publish time across edits) and is never a draft gate. Its value, when present, is a stringified unix timestamp in seconds — mirroring NIP-23's use of the same tag.\n\n### Relay policy\n\nRelays MAY accept or reject draft kinds per their policy. Public discovery relays MAY choose to reject drafts; private or author-scoped relays (e.g., a user's outbox) SHOULD accept them to support cross-device editing.\n\n## Relations\n\nAll relations between vocabulary events use `a` tags with a marker (fourth element) indicating the relation type. This reuses the established Nostr pattern for typed references to addressable events (see [NIP-AMB](AMB.md), [NIP-53](53.md)).\n\n### Hierarchical Relations\n\n| Marker | Inverse | Description |\n|--------|---------|-------------|\n| `broader` | `narrower` | Direct parent in the hierarchy |\n| `narrower` | `broader` | Direct child in the hierarchy |\n\nPublishers MUST assert **both directions**: when a concept has a `broader` tag, the broader concept MUST include a corresponding `narrower` tag pointing back. This enables traversal in both directions without requiring additional queries.\n\nOnly assert `broader`/`narrower` for **direct** parent-child relationships. Transitive ancestry is inferred by clients traversing the chain.\n\n### Associative Relations\n\n| Marker | Symmetric | Description |\n|--------|-----------|-------------|\n| `related` | yes | Non-hierarchical association between concepts |\n\nPublishers SHOULD assert both directions: if concept A is `related` to concept B, then B SHOULD include a corresponding `related` tag pointing to A.\n\nA concept MUST NOT be both hierarchically related (directly or transitively) and associatively related to the same concept.\n\n### Scheme and Collection Relations\n\n| Marker | Used on | Description |\n|--------|---------|-------------|\n| `inScheme` | Concept, Collection | Links to the containing ConceptScheme |\n| `hasTopConcept` | ConceptScheme | Links to top-level concepts |\n| `topConceptOf` | Concept | Links a top concept back to its ConceptScheme |\n| `member` | Collection | Links to a concept or nested collection belonging to this collection |\n\n### Mapping Relations (Nostr-to-Nostr)\n\nFor linking concepts **across different concept schemes** published on Nostr:\n\n| Marker | Symmetric | Description |\n|--------|-----------|-------------|\n| `exactMatch` | yes | Concepts are interchangeable in all contexts |\n| `closeMatch` | yes | Concepts are similar but not always interchangeable |\n| `broadMatch` | no | This concept is narrower than the target (cross-scheme) |\n| `narrowMatch` | no | This concept is broader than the target (cross-scheme) |\n| `relatedMatch` | yes | Non-hierarchical association across schemes |\n\n`exactMatch` MUST NOT be combined with `broadMatch` or `relatedMatch` for the same concept pair. `exactMatch` implies `closeMatch` — every exact match is inherently a close match. Clients querying for close matches SHOULD also include exact matches in their results.\n\n`exactMatch` is transitive: if concept A is an exact match of B, and B is an exact match of C, then A is also an exact match of C. Clients resolving mappings SHOULD account for transitive chains.\n\nFor symmetric mapping relations (`exactMatch`, `closeMatch`, `relatedMatch`), publishers SHOULD assert both directions. `narrowMatch` is the inverse of `broadMatch` — publishers SHOULD assert both directions: when a concept has a `broadMatch` tag, the target concept SHOULD include a corresponding `narrowMatch` tag pointing back, and vice versa.\n\n`broadMatch`, `narrowMatch`, and `relatedMatch` are cross-scheme counterparts of `broader`, `narrower`, and `related` respectively. Clients aggregating semantic relations SHOULD include mapping relations in their results.\n\nBy convention, mapping markers link concepts in **different** schemes.\n\nExample — mapping between two Nostr-native vocabularies:\n\n```jsonc\n{\n  \"kind\": 39738,\n  \"tags\": [\n    [\"d\", \"video\"],\n    [\"type\", \"Concept\"],\n    [\"prefLabel\", \"Video\", \"de\"],\n    [\"prefLabel\", \"Video\", \"en\"],\n    [\"a\", \"39737:<pubkey>:hcrt\", \"<relay>\", \"inScheme\"],\n    // mapping to another publisher's vocabulary\n    [\"a\", \"39738:<other-pubkey>:moving-image\", \"<relay>\", \"exactMatch\"]\n  ],\n  \"content\": \"\"\n}\n```\n\n## External Mappings\n\nFor mappings to concepts in external URI-based vocabularies (that are not published on Nostr), use `r` tags with a mapping marker:\n\n```jsonc\n[\"r\", \"https://w3id.org/kim/hcrt/video\", \"exactMatch\"],\n[\"r\", \"http://purl.org/dcx/lrmi-vocabs/mediaType/Video\", \"closeMatch\"],\n[\"r\", \"http://purl.org/dc/dcmitype/MovingImage\", \"broadMatch\"]\n```\n\nThe same mapping markers apply: `exactMatch`, `closeMatch`, `broadMatch`, `narrowMatch`, `relatedMatch`.\n\nThis is distinct from the `i` tag, which asserts identity (\"this concept IS that external URI\"), while `r` tags with mapping markers assert a relationship (\"this concept CORRESPONDS TO that external concept\").\n\n## External Identity Bridge\n\nThe `i` tag (per [NIP-73](73.md)) provides a bridge to external URI-based identifier systems:\n\n```jsonc\n[\"i\", \"https://w3id.org/kim/schulfaecher/s1017\"]\n```\n\nThis declares: \"this Nostr concept is a re-publication of the concept at that external URI.\" Systems that know the concept by its HTTP URI can use this to cross-reference.\n\n## Referencing Vocabulary Concepts from Other Events\n\nOther Nostr events can reference concepts defined by this NIP using standard `a` tags:\n\n```jsonc\n// In a kind:30142 AMB event, a kind:1 note, or any other event:\n[\"a\", \"39738:<pubkey>:s1017\", \"<relay>\"]\n```\n\nThis makes the concept queryable: a relay filter `{\"#a\": [\"39738:<pubkey>:s1017\"]}` returns all events that reference that concept, across all event kinds.\n\n## Authority Model\n\nIn Nostr, there is no domain authority. Instead, **the pubkey is the namespace**. Multiple pubkeys can publish events for the same vocabulary (same `d` tags), resulting in different versions.\n\nClients SHOULD use the user's web of trust to select which publisher's version of a vocabulary to display, similar to how [NIP-54](54.md) (Wiki) handles competing article versions.\n\nA vocabulary publisher MAY signal their identity using a [NIP-05](05.md) identifier or by including provenance metadata in the concept scheme's `content` field.\n\n## Querying\n\n### Fetch a Specific Scheme\n\n```json\n{\"kinds\": [39737], \"authors\": [\"<pubkey>\"], \"#d\": [\"schulfaecher\"]}\n```\n\n### Fetch a Specific Concept\n\n```json\n{\"kinds\": [39738], \"authors\": [\"<pubkey>\"], \"#d\": [\"s1017\"]}\n```\n\n### Fetch all ConceptSchemes from a publisher\n\n```json\n{ \"kinds\": [39737], \"authors\": [\"<hex>\"] }\n```\n\n### Fetch all Concepts belonging to a ConceptScheme\n\n```json\n{ \"kinds\": [39738], \"#a\": [\"39737:<hex>:<d>\"] }\n```\n\n### Fetch all Collections belonging to a ConceptScheme\n\n```json\n{ \"kinds\": [39739], \"#a\": [\"39737:<hex>:<d>\"] }\n```\n\nAll filters use only single-letter tags (`a`) or the `kinds` field, so they work with any NIP-01-compliant relay. No multi-letter tag indexing is required.\n\nClients that also want to show the viewing user's drafts can widen the filter by adding the matching draft kind — for example, schemes plus draft schemes:\n\n```json\n{ \"kinds\": [39737, 39736], \"authors\": [\"<hex>\"] }\n```\n\n### Find All Events Tagged with a Concept\n\n```json\n{\"#a\": [\"39738:<pubkey>:s1017\"]}\n```\n\nThis works across all event kinds — AMB events, notes, labels, etc.\n\n### Traversing Hierarchies\n\nClients can walk `broader`/`narrower` chains to compute transitive ancestry or descendant sets. To collect all narrower concepts under a given concept:\n\n1. Fetch the concept and read its `narrower` tags\n2. For each narrower concept, fetch it and read its `narrower` tags\n3. Repeat recursively until no further `narrower` tags are found\n\nSKOS defines `broaderTransitive` and `narrowerTransitive` as inferred properties. In this model, clients compute transitive closures by traversal rather than storing them as explicit tags.\n\n## Examples\n\n### Example 1: A Complete Small Vocabulary\n\n**Concept Scheme:**\n\n```json\n{\n  \"kind\": 39737,\n  \"pubkey\": \"abc123...\",\n  \"tags\": [\n    [\"d\", \"hcrt\"],\n    [\"type\", \"ConceptScheme\"],\n    [\"prefLabel\", \"Hochschulcampus Ressourcentypen\", \"de\"],\n    [\"prefLabel\", \"Higher Education Resource Types\", \"en\"],\n    [\"a\", \"39738:abc123...:text\", \"wss://relay.example.com\", \"hasTopConcept\"],\n    [\"a\", \"39738:abc123...:audiovisual\", \"wss://relay.example.com\", \"hasTopConcept\"],\n    [\"i\", \"https://w3id.org/kim/hcrt/scheme\"]\n  ],\n  \"content\": \"A controlled vocabulary of resource types for higher education.\"\n}\n```\n\n**Top Concept:**\n\n```json\n{\n  \"kind\": 39738,\n  \"pubkey\": \"abc123...\",\n  \"tags\": [\n    [\"d\", \"audiovisual\"],\n    [\"type\", \"Concept\"],\n    [\"prefLabel\", \"Audiovisuelles Medium\", \"de\"],\n    [\"prefLabel\", \"Audiovisual Medium\", \"en\"],\n    [\"a\", \"39737:abc123...:hcrt\", \"wss://relay.example.com\", \"inScheme\"],\n    [\"a\", \"39737:abc123...:hcrt\", \"wss://relay.example.com\", \"topConceptOf\"],\n    [\"a\", \"39738:abc123...:video\", \"wss://relay.example.com\", \"narrower\"],\n    [\"a\", \"39738:abc123...:audio\", \"wss://relay.example.com\", \"narrower\"],\n    [\"i\", \"https://w3id.org/kim/hcrt/audiovisual\"]\n  ],\n  \"content\": \"\"\n}\n```\n\n**Leaf Concept with External Mappings:**\n\n```json\n{\n  \"kind\": 39738,\n  \"pubkey\": \"abc123...\",\n  \"tags\": [\n    [\"d\", \"video\"],\n    [\"type\", \"Concept\"],\n    [\"prefLabel\", \"Video\", \"de\"],\n    [\"prefLabel\", \"Video\", \"en\"],\n    [\"altLabel\", \"Film\", \"de\"],\n    [\"altLabel\", \"Moving Image\", \"en\"],\n    [\"notation\", \"video\"],\n    [\"a\", \"39737:abc123...:hcrt\", \"wss://relay.example.com\", \"inScheme\"],\n    [\"a\", \"39738:abc123...:audiovisual\", \"wss://relay.example.com\", \"broader\"],\n    [\"r\", \"https://w3id.org/kim/hcrt/video\", \"exactMatch\"],\n    [\"r\", \"http://purl.org/dc/dcmitype/MovingImage\", \"closeMatch\"],\n    [\"i\", \"https://w3id.org/kim/hcrt/video\"]\n  ],\n  \"content\": \"A recording of moving visual images.\"\n}\n```\n\n### Example 2: Cross-Scheme Mapping\n\nA concept in one Nostr-native vocabulary mapped to a concept in another:\n\n```json\n{\n  \"kind\": 39738,\n  \"pubkey\": \"abc123...\",\n  \"tags\": [\n    [\"d\", \"math\"],\n    [\"type\", \"Concept\"],\n    [\"prefLabel\", \"Mathematik\", \"de\"],\n    [\"prefLabel\", \"Mathematics\", \"en\"],\n    [\"a\", \"39737:abc123...:schulfaecher\", \"wss://relay.example.com\", \"inScheme\"],\n    [\"a\", \"39738:def456...:mathematics\", \"wss://relay2.example.com\", \"exactMatch\"]\n  ],\n  \"content\": \"\"\n}\n```\n\n### Example 3: Using a Vocabulary Concept in an AMB Event\n\nAn educational resource referencing a Nostr-native vocabulary concept:\n\n```json\n{\n  \"kind\": 30142,\n  \"tags\": [\n    [\"d\", \"pythagorean-theorem-video\"],\n    [\"name\", \"Pythagorean Theorem Explained\"],\n    [\"a\", \"39738:abc123...:s1017\", \"wss://relay.example.com\"],\n    [\"a\", \"39738:abc123...:video\", \"wss://relay.example.com\"],\n    [\"t\", \"Pythagoras\"],\n    [\"t\", \"Geometrie\"]\n  ],\n  \"content\": \"An introductory video explaining the Pythagorean theorem\"\n}\n```\n\n## Migration from single-kind\n\nEvents published under the pre-split rule (all as `kind:39737`, disambiguated by the `type` tag) are not automatically valid under this revision. Publishers SHOULD republish Concept and Collection events under `kind:39738` / `kind:39739`. Clients MAY continue to read legacy events for backward compatibility but SHOULD treat any `kind:39737` event whose `type` tag is not `ConceptScheme` as legacy-only.\n\n### Impact on existing references\n\nAny event in the wider Nostr ecosystem (for example, NIP-AMB learning-resource events) that references a concept via an `a` tag with the legacy `39737:<pubkey>:<d>` coordinate becomes stale once that concept is republished under `kind:39738`: the reference's kind prefix no longer matches the target's kind. Clients resolving such references SHOULD attempt a fallback lookup using `kind:39738` with the same `pubkey:d` suffix before treating the reference as unresolved.\n\nPublishers migrating their own vocabularies SHOULD:\n\n1. Republish each Concept event under `kind:39738` and each Collection event under `kind:39739`, preserving the original `d` identifier.\n2. NIP-09-delete the legacy `kind:39737` Concept / Collection events so relays can garbage-collect them.\n3. Optionally announce the migration (e.g., via a kind:1 note) so downstream consumers know to update their cached references.\n\nDuring a transition window, clients MAY dual-read both the legacy and the new kinds to minimize broken references.\n\n## References\n\n- [SKOS Reference (W3C)](https://www.w3.org/TR/skos-reference/) — the vocabulary model this NIP is inspired by\n- [SkoHub](https://skohub.io/) — SKOS vocabulary publishing infrastructure\n- [NIP-01](01.md) — Basic protocol, addressable events\n- [NIP-09](09.md) — Event deletion (draft-to-published cleanup)\n- [NIP-23](23.md) — Long-form content (precedent for draft kind and `published_at` tag)\n- [NIP-32](32.md) — Labeling\n- [NIP-73](73.md) — External Content IDs (`i` tag)\n- [NIP-54](54.md) — Wiki (web-of-trust authority model precedent)\n- [NIP-AMB](AMB.md) — AMB metadata events (precedent for `a` tag markers)\n","sig":"9d50250c1dc5c3bfc607793beb3c3d8bcadc329521cb42ff4e7eb9720d3783b31f19c5cd423130e2cf50a165a2973475d7cc30fc6689733da8c425bbb6c2524e"}