{"id":"9cb6a8587c81fd97ebdb5606a4a7000bcc7de3c71aecd7c2ce3129cc2f7cdff4","pubkey":"43185edecb675892824b1a37a57f3e407fbde2eda7201a3829b8cf4ba7c5b4f0","created_at":1774141308,"kind":30817,"tags":[["d","service-attestations-namecoin"],["a","30817:c4f5e7a75a8ce3683d529cff06368439c529e5243c6b125ba68789198856cac7:attestations","wss://nostr.wine/"],["p","c4f5e7a75a8ce3683d529cff06368439c529e5243c6b125ba68789198856cac7"],["alt","NIP-91: Service Attestations (with optional Namecoin-Anchored Identity Binding)"],["title","NIP-91: Service Attestations"]],"content":"# NIP-91: Service Attestations (with optional Namecoin-Anchored Identity Binding)\n\n`draft` `optional`\n\n## Abstract\n\nThis NIP defines a protocol for **signed attestations of service or task completion** between Nostr identities, forming a portable, queryable reputation layer. It introduces two new event kinds: one for publishing attestation claims and one for aggregating attestation sets. It also specifies an optional **Namecoin identity anchor** mechanism, whereby the Nostr pubkey receiving an attestation MUST have been the active value associated with a Namecoin `id/` name at the time the attested service occurred, providing a blockchain-timestamped binding between human-readable names and reputation history.\n\n## Motivation\n\nExisting NIPs provide building blocks adjacent to reputation but none cover the specific use case of **structured, verifiable attestations for services and tasks performed between parties**:\n\n| Existing NIP | What it covers | Gap this NIP fills |\n|---|---|---|\n| **NIP-58 (Badges)** | Issuer-defined badges awarded to pubkeys | Badges are binary (awarded/not); they lack structured ratings, service context, or temporal proof of identity binding. A badge says \"you earned X\" but not \"you performed service Y for me on date Z and I rate it 4.5/5.\" |\n| **NIP-32 (Labeling)** | Generic labels on events/pubkeys/relays | Labels are categorical metadata for moderation and classification. They have no rating scale, no service/task context, and no concept of a bilateral transaction. |\n| **NIP-56 (Reporting)** | Negative reports on content or users | One-directional negative signaling only. No positive attestation, no rating spectrum, no service context. |\n| **NIP-85 (Trusted Assertions)** | WoT score computation by service providers | Addresses *computed aggregations* by third-party providers, not *first-party attestation events* between transacting parties. Complementary but upstream of this NIP. |\n| **NIP-39 (External Identities)** | Linking external platform accounts | Proves account ownership on other platforms but carries no reputation or attestation data. |\n| **PR #1208 (NIP-77, Trust)** | Expressing trust between pubkeys | Generic trust/distrust expression. Not tied to specific services, transactions, or tasks. No Namecoin anchoring. |\n| **PR #1515 (Reviews)** | Review events with ratings | Closest prior art. Focuses on consumer reviews of locations/products/content. Does not address bilateral service attestation, Namecoin anchoring, or the temporal identity proof mechanism defined here. |\n| **PR #46 (Reputation)** | PoW-weighted reputation assignment | Never merged. Uses proof-of-work as weight signal. No service/task context, no identity anchoring. |\n\n## Specification\n\n### Event Kinds\n\n| Kind | Name | Description |\n|---|---|---|\n| `38383` | Service Attestation | A signed attestation that a pubkey performed a service or task |\n| `38384` | Attestation Set (parameterized replaceable) | A user-maintained list of attestations they currently stand behind |\n\n> Kind numbers are provisional pending number assignment.\n\n### Kind `38383`: Service Attestation\n\nA Service Attestation is a **parameterized replaceable event** published by the **attester** (the party who received or observed the service) about the **attestee** (the party who performed the service). Using a `d` tag makes it replaceable, allowing the attester to update their rating over time.\n\n```json\n{\n \"kind\": 38383,\n \"pubkey\": \"\",\n \"created_at\": ,\n \"tags\": [\n [\"p\", \"\", \"\"],\n [\"d\", \"\"],\n [\"service\", \"\", \"\"],\n [\"rating\", \"\", \"\"],\n [\"completed_at\", \"\"],\n [\"ref\", \"\"],\n [\"nmc\", \"\", \"\"],\n [\"L\", \"nip-XX.service\"],\n [\"l\", \"\", \"nip-XX.service\"]\n ],\n \"content\": \"\",\n \"sig\": \"\"\n}\n```\n\n#### Required Tags\n\n- **`p`** — The pubkey of the attestee (service performer). Relay hint RECOMMENDED per NIP-01.\n- **`d`** — A unique identifier for this attestation, chosen by the attester. This makes the event parameterized-replaceable, allowing the attester to update their rating over time.\n- **`service`** — A short, lowercase, dot-separated service category string. The first value is the primary category; the optional second value is a subcategory. Examples:\n - `[\"service\", \"plumbing.repair\"]`\n - `[\"service\", \"software.frontend\"]`\n - `[\"service\", \"hospitality.hosting\"]`\n - `[\"service\", \"commerce.sale\"]`\n - `[\"service\", \"education.tutoring\"]`\n - `[\"service\", \"transport.delivery\"]`\n- **`rating`** — A two-element value: the score and the maximum. Both MUST be non-negative numbers. Clients SHOULD normalize to a 0–1 scale for aggregation.\n - `[\"rating\", \"4.5\", \"5\"]` → 0.9 normalized\n - `[\"rating\", \"92\", \"100\"]` → 0.92 normalized\n - `[\"rating\", \"1\", \"1\"]` → binary positive attestation\n\n#### Optional Tags\n\n- **`completed_at`** — Unix timestamp of when the service or task was completed. If omitted, `created_at` is used. This is important when an attestation is published some time after the service.\n- **`ref`** — A reference to the underlying transaction. Can be:\n - An `e` tag (Nostr event ID) for services negotiated on-Nostr\n - A URL for an external reference\n - An `i` tag per NIP-39 conventions for external content IDs\n- **`nmc`** — Namecoin anchor (see Namecoin Identity Anchoring below).\n- **`L` and `l`** — NIP-32 namespace labels. RECOMMENDED for discoverability via relay label queries.\n\n#### Content\n\nThe `content` field is an optional free-text review. It MAY be empty. Clients SHOULD render it as a comment alongside the structured rating data.\n\n### Kind `38384`: Attestation Set\n\nAn Attestation Set is a **parameterized replaceable event** (per NIP-01) that allows a user to maintain a curated list of attestations they currently endorse. This addresses the reality that opinions change — a service that was once five stars may degrade, or vice versa.\n\n```json\n{\n \"kind\": 38384,\n \"pubkey\": \"\",\n \"created_at\": ,\n \"tags\": [\n [\"d\", \"active_attestations\"],\n [\"a\", \"38383::\", \"\"],\n [\"a\", \"38383::\", \"\"],\n ...\n ],\n \"content\": \"\",\n \"sig\": \"\"\n}\n```\n\nThe `a` tags reference the attester's own Service Attestation events. Clients MAY treat only attestations present in the most recent Attestation Set as the attester's current active endorsements. Attestation events that exist but are absent from the set SHOULD be treated as withdrawn (no longer reflecting the attester's current opinion).\n\nIf an attester has never published an Attestation Set, all of their Service Attestation events SHOULD be treated as active.\n\n---\n\n## Optional Namecoin Identity Anchoring\n\n### Overview\n\nThis section defines an optional mechanism for binding Nostr attestation history to a Namecoin `id/` name with temporal proof. It uses Namecoin's existing identity namespace and blockchain timestamps to establish that a pubkey was the declared identity key for a human-readable name at the time a service was performed.\n\n### Namecoin `id/` Value Format Extension\n\nTo participate in this system, a Namecoin `id/` name SHOULD include a `nostr` field in its JSON value:\n\n```json\n{\n \"nostr\": \"\",\n \"email\": \"alice@example.com\",\n \"bitcoin\": \"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa\"\n}\n```\n\nOr, for multiple pubkeys (e.g., primary and delegation):\n\n```json\n{\n \"nostr\": {\n \"default\": \"\",\n \"signing\": \"\"\n }\n}\n```\n\n> **Note on value size:** Namecoin values are limited to 520 bytes. A Nostr pubkey in hex is 64 characters. A minimal value of `{\"nostr\":\"<64 hex chars>\"}` is approximately 76 bytes, well within limits.\n\n### The `nmc` Tag\n\nWhen a Service Attestation includes an `nmc` tag, the attester is claiming that the attestee's pubkey was associated with the specified Namecoin name at the time of service completion:\n\n```\n[\"nmc\", \"id/alice\", \"850000\"]\n```\n\n- **First value:** The full Namecoin name including namespace prefix (e.g., `id/alice`).\n- **Second value:** The Namecoin block height at (or nearest before) the `completed_at` timestamp. This serves as a checkpoint for verification.\n\n### Verification Procedure\n\nA client or verifier performing Namecoin-anchored attestation verification MUST follow these steps:\n\n1. **Retrieve the attestee's pubkey** from the `p` tag of the Service Attestation event.\n\n2. **Retrieve the `completed_at` timestamp** (or `created_at` if `completed_at` is absent).\n\n3. **Parse the `nmc` tag** to obtain the Namecoin name and reference block height.\n\n4. **Query Namecoin history** for the specified name at the specified block height. This requires access to a Namecoin full node or a trusted API that can return historical name values:\n ```\n namecoind name_history \"id/alice\"\n ```\n The verifier must find the `name_update` transaction that was active (i.e., most recently confirmed before) the reference block height.\n\n5. **Extract the `nostr` field** from the Namecoin name value that was active at that block height.\n\n6. **Compare pubkeys.** The Nostr pubkey in the `p` tag of the attestation MUST match the `nostr` pubkey value in the Namecoin name record at the reference block height.\n\n7. **Validate temporal bounds:**\n - The reference block height MUST correspond to a block whose timestamp is ≤ the `completed_at` timestamp of the attestation.\n - The name MUST NOT have been expired at the reference block height (Namecoin names expire after 35,999 blocks without renewal).\n\n8. **Result:** If all checks pass, the attestation is **Namecoin-verified**. Clients MAY display a distinct visual indicator (e.g., a chain-link icon, a colored badge) to distinguish Namecoin-verified attestations from unanchored ones.\n\n### Temporal Gap Tolerance\n\nBecause Namecoin blocks occur approximately every 10 minutes and name updates require 12-block confirmation, there is inherent latency between a pubkey change and its on-chain finality. Clients SHOULD allow a tolerance window of **±12 blocks** (~2 hours) around the reference block height when matching timestamps.\n\n### Key Rotation Handling\n\nWhen a Namecoin `id/` name updates its `nostr` value to a new pubkey (key rotation), attestations signed during the previous key's validity period remain valid if and only if they reference a block height during which the previous key was active. This is by design: the Namecoin chain preserves the full history of name values, so historical attestations are always verifiable against the key that was active at their timestamp.\n\nClients SHOULD indicate when an attestation references a pubkey that is no longer the *current* value for a Namecoin name, e.g., \"Verified at time of service (key since rotated).\"\n\n---\n\n### Why Namecoin anchoring matters\n\nNostr pubkeys are pseudonymous and can be generated freely. When reputation has economic value — for example, a contractor's track record of completed jobs — there is an incentive to fabricate attestation histories for freshly generated keys and then associate those keys with a human-readable identity after the fact. \n\nNamecoin's `d/` and `id/` namespace provides a **tamper-evident, temporally ordered binding** between human-readable names and pubkeys. Because Namecoin name updates are recorded on a merge-mined blockchain with Bitcoin-class security, a verifier can confirm that a given pubkey was *actually* the declared identity of a Namecoin name at the time a service attestation was issued. This prevents backdating reputation to a name that didn't hold that key at the relevant time.\n\nThis is opt-in. Attestations without Namecoin anchoring are fully valid and useful. The Namecoin layer adds a higher tier of assurance for use cases where temporal identity provenance matters (marketplaces, professional services, credentialing).\n\n---\n\n## Querying and Aggregation\n\n### Relay Filters\n\nClients can query for attestations using standard NIP-01 filters:\n\n```json\n// All attestations about a specific pubkey\n{\"kinds\": [38383], \"#p\": [\"\"]}\n\n// All attestations in a specific service category\n{\"kinds\": [38383], \"#l\": [\"plumbing.repair\"]}\n\n// All attestations by a specific attester\n{\"kinds\": [38383], \"authors\": [\"\"]}\n\n// All Namecoin-anchored attestations about a pubkey\n{\"kinds\": [38383], \"#p\": [\"\"], \"#nmc\": [\"id/alice\"]}\n```\n\n### Client-Side Aggregation\n\nReputation computation is explicitly **left to clients**, consistent with Nostr's philosophy that interpretation is a client concern. However, this NIP RECOMMENDS the following approach:\n\n1. **Web-of-Trust weighting.** Attestations from pubkeys closer in the client user's social graph (per follow lists, NIP-02) SHOULD carry more weight than attestations from distant or unknown pubkeys. See the discussion in PR #46 for the rationale: social distance matters more than proof-of-work or payment for anti-sybil purposes.\n\n2. **Namecoin-verified premium.** Clients MAY give higher weight to attestations with valid Namecoin anchoring, as they provide stronger identity assurance.\n\n3. **Temporal decay.** More recent attestations SHOULD be weighted more heavily than old ones, as service quality can change.\n\n4. **Attestation Set filtering.** If the attester maintains an Attestation Set (kind `38384`), only attestations referenced in the latest set SHOULD be considered active.\n\n### NIP-85 Integration\n\nThis NIP is designed to be upstream of NIP-85 (Trusted Assertions). A NIP-85 service provider can:\n\n1. Ingest Service Attestation events (kind `38383`)\n2. Perform Namecoin verification on `nmc`-tagged events\n3. Compute aggregate reputation scores using WoT, PageRank, or other algorithms\n4. Publish results as NIP-85 Trusted Assertion events (kind `30382`)\n\nThis keeps the first-party attestation data (this NIP) cleanly separated from computed reputation scores (NIP-85).\n\n---\n\n## Security Considerations\n\n### Sybil Attacks\n\nAn attacker can generate many keypairs and have them attest to each other. Defenses:\n\n- **WoT filtering** is the primary defense. Attestations from unknown pubkeys carry no weight by default.\n- **Namecoin anchoring** raises the cost of sybil identities (each name requires NMC and ongoing renewal fees).\n- **NIP-13 proof-of-work** MAY optionally be required by relays or weighted by clients.\n\n### Collusion\n\nTwo parties can exchange fake positive attestations. Defenses:\n\n- **Graph analysis** by NIP-85 providers can detect cliques of mutual attestation with no outside connections.\n- **Zap receipts** (NIP-57) referenced via the `ref` tag provide evidence of actual economic transactions underlying attestations.\n\n### Namecoin Reorg Risk\n\nDeep Namecoin chain reorganizations could invalidate historical name-to-pubkey bindings. In practice, Namecoin is merge-mined with Bitcoin and has not experienced a significant reorg in years. Clients SHOULD treat attestations referencing block heights older than 100 blocks as having negligible reorg risk.\n\n### Stale Namecoin Names\n\nA Namecoin name that has expired (not renewed within 35,999 blocks) loses its binding. Clients MUST check expiry status and SHOULD flag attestations whose `nmc` reference points to an expired name period.\n\n---\n\n## Examples\n\n### Example 1: Simple Service Attestation (No Namecoin)\n\nAlice attests that Bob did a good job fixing her plumbing:\n\n```json\n{\n \"kind\": 38383,\n \"pubkey\": \"aaa111...\",\n \"created_at\": 1711000000,\n \"tags\": [\n [\"p\", \"bbb222...\", \"wss://relay.example.com\"],\n [\"d\", \"alice-bob-plumbing-2026-03\"],\n [\"service\", \"plumbing.repair\"],\n [\"rating\", \"5\", \"5\"],\n [\"completed_at\", \"1710900000\"],\n [\"L\", \"nip-XX.service\"],\n [\"l\", \"plumbing.repair\", \"nip-XX.service\"]\n ],\n \"content\": \"Fixed the kitchen sink leak quickly and cleanly. Would hire again.\",\n \"sig\": \"...\"\n}\n```\n\n### Example 2: Namecoin-Anchored Attestation\n\nCharlie attests that `id/dana` (Namecoin name) performed excellent frontend development. At the time of the work, the `id/dana` name pointed to pubkey `ddd444...`:\n\n```json\n{\n \"kind\": 38383,\n \"pubkey\": \"ccc333...\",\n \"created_at\": 1711000000,\n \"tags\": [\n [\"p\", \"ddd444...\", \"wss://relay.example.com\"],\n [\"d\", \"charlie-dana-frontend-2026-q1\"],\n [\"service\", \"software.frontend\"],\n [\"rating\", \"95\", \"100\"],\n [\"completed_at\", \"1710500000\"],\n [\"ref\", \"https://github.com/project/pull/42\"],\n [\"nmc\", \"id/dana\", \"849500\"],\n [\"L\", \"nip-XX.service\"],\n [\"l\", \"software.frontend\", \"nip-XX.service\"]\n ],\n \"content\": \"Delivered the React dashboard ahead of schedule. Clean code, great communication.\",\n \"sig\": \"...\"\n}\n```\n\nVerification: A client queries Namecoin for `name_history \"id/dana\"`, finds that at block 849500 the value was `{\"nostr\":\"ddd444...\"}`, confirms this matches the `p` tag, and marks the attestation as Namecoin-verified.\n\n### Example 3: Attestation Set\n\nAlice maintains her active endorsements:\n\n```json\n{\n \"kind\": 38384,\n \"pubkey\": \"aaa111...\",\n \"created_at\": 1711100000,\n \"tags\": [\n [\"d\", \"active_attestations\"],\n [\"a\", \"38383:bbb222...:alice-bob-plumbing-2026-03\", \"wss://relay.example.com\"],\n [\"a\", \"38383:eee555...:alice-eve-tutoring-2025\", \"wss://relay.example.com\"]\n ],\n \"content\": \"\",\n \"sig\": \"...\"\n}\n```\n\nAlice had previously attested to a third party, but has removed that `a` tag — indicating she no longer stands behind that attestation.\n\n---\n\n## Service Category Registry\n\nTo promote interoperability, clients SHOULD use categories from this initial registry. New categories MAY be added by convention; clients SHOULD attempt to match existing categories before creating new ones.\n\n| Category | Subcategories (examples) |\n|---|---|\n| `commerce` | `sale`, `trade`, `rental` |\n| `software` | `frontend`, `backend`, `mobile`, `devops`, `security` |\n| `plumbing` | `repair`, `installation`, `inspection` |\n| `electrical` | `repair`, `installation`, `inspection` |\n| `hospitality` | `hosting`, `lodging`, `dining` |\n| `transport` | `delivery`, `rideshare`, `freight` |\n| `education` | `tutoring`, `mentoring`, `course` |\n| `creative` | `design`, `writing`, `music`, `video` |\n| `legal` | `consultation`, `representation`, `review` |\n| `finance` | `consultation`, `accounting`, `audit` |\n| `health` | `consultation`, `therapy`, `fitness` |\n| `general` | `task`, `errand`, `consultation` |\n\nClients MAY use NIP-32 labeling conventions to propose and discover new categories in the wild.\n\n---\n\n## Backward Compatibility\n\nThis NIP introduces new event kinds and does not modify any existing kinds or behavior. Clients and relays that do not implement this NIP will simply ignore these event kinds, per standard NIP-01 behavior.\n\nThe `nmc` tag is a new tag and will be ignored by clients that do not support Namecoin anchoring. The attestation remains fully valid and useful without it.\n\nNIP-32 `L`/`l` tags are included for compatibility with existing label-based discovery. NIP-85 integration is purely additive.\n\n---\n\n## References\n\n- [NIP-01: Basic Protocol](https://github.com/nostr-protocol/nips/blob/master/01.md)\n- [NIP-02: Follow List](https://github.com/nostr-protocol/nips/blob/master/02.md)\n- [NIP-13: Proof of Work](https://github.com/nostr-protocol/nips/blob/master/13.md)\n- [NIP-32: Labeling](https://github.com/nostr-protocol/nips/blob/master/32.md)\n- [NIP-39: External Identities](https://github.com/nostr-protocol/nips/blob/master/39.md)\n- [NIP-57: Lightning Zaps](https://github.com/nostr-protocol/nips/blob/master/57.md)\n- [NIP-58: Badges](https://github.com/nostr-protocol/nips/blob/master/58.md)\n- [NIP-85: Trusted Assertions](https://github.com/nostr-protocol/nips/pull/1534)\n- [Namecoin Identity Namespace](https://wiki.namecoin.info/?title=Identity)\n- [Namecoin FAQ](https://www.namecoin.org/docs/faq/)\n\n\n---\n\n## Comparison with Wiki-Attestations (NostrHub NIP)\n\nThis is a comparison between the [Wiki-Attestations NIP](https://nostrhub.io/naddr1qvzqqqrcvypzp384u7n44r8rdq74988lqcmggww998jjg0rtzfd6dpufrxy9djk8qyghwumn8ghj7mn0wd68ytnhd9hx2tcqp3shgar9wd6xzarfdah8xhfuyua) and the Service-Attestations NIP above.\n\nThe two proposals solve different problems with different architectures. The NostrHub wiki article (\"Wiki-Attestations\") is a general-purpose truth-claim framework for any Nostr event. Our draft (\"Service-Attestations\") is a domain-specific reputation protocol for service/task interactions with a blockchain identity anchoring layer. They overlap in the middle but diverge at both ends.\n\nHere's the breakdown across every major dimension:\n\n### 1. Scope and Philosophy\n\nWiki-Attestations is deliberately abstract — it answers \"is this Nostr event true?\" for any event kind. Someone publishes a claim (the \"Assertion Event\"), and a third-party attestor verifies it. It's a generic truthfulness layer.\n\nService-Attestations is narrowly scoped — it answers \"how did this person perform in a transaction?\" It's a reputation/review primitive for commerce and services.\n\nWiki-Attestations could theoretically be used to build Service-Attestations on top of it, but it doesn't provide the domain-specific vocabulary (ratings, roles, bilateral structure) needed to do so without additional specification.\n\n### 2. Event Kinds and Architecture\n\nThis is a major structural difference.\n\n**Wiki-Attestations** defines four event kinds across a full lifecycle:\n\n- Kind `31871` — the attestation itself (addressable/replaceable)\n- Kind `31872` — attestation request\n- Kind `31873` — attestor recommendation\n- Kind `11871` — attestor proficiency declaration\n\nThis is a rich system with a request-response flow — you can ask someone to verify your claim, they can declare what they're good at verifying, and third parties can recommend attestors.\n\n**Service-Attestations** defines two kinds:\n\n- Kind `38383` — Service Attestation (parameterized replaceable)\n- Kind `38384` — Attestation Set (parameterized replaceable)\n\nIt relies on NIP-32's existing label vocabulary convention for semantic structure. There's no request-response flow, no attestor discovery mechanism, and no proficiency declarations. It's deliberately minimal.\n\nThe replaceability difference is architecturally significant. Wiki-Attestations uses addressable events (the `d` tag makes them replaceable), which means an attestation can be updated or revoked by publishing a new event with the same `d` tag. Service-Attestations also uses parameterized replaceable events, allowing the attester to update their rating over time, and introduces Attestation Sets for managing which attestations are currently active.\n\n### 3. What Gets Attested\n\n**Wiki-Attestations** attests to *events* — the `e`, `a`, or `p` tag points to an existing Nostr event or pubkey, and the attestor is saying \"this event/claim is valid or invalid.\" It has a formal validity model with `valid`/`invalid` values and temporal bounds (`valid_from`, `valid_to`). This is essentially a certificate model.\n\n**Service-Attestations** attests to *people's behavior in transactions* — the `p` tag points to a counterparty, and the labels describe what happened (`completed`, `failed`, `disputed`) and the subject's role (`provider`, `client`, `mediator`). The `e`/`a` tags optionally link to the service event but aren't the focus — the person is.\n\n### 4. Lifecycle and State Management\n\n**Wiki-Attestations** has a full state machine: `accepted → verifying → verified → revoked` (or `rejected`). This is powerful for use cases like certificate verification, safety inspections, or credential validation where an attestation goes through a workflow. The revocation model is clean — publish a new event with the same `d` tag and `[\"s\", \"revoked\"]`.\n\n**Service-Attestations** has no lifecycle. An attestation is published once and stands as a permanent record (though it can be updated via replaceability). This is appropriate for reviews (you don't \"verify\" a review, you just read it) but would be inadequate for the safety-inspection-style use cases Wiki-Attestations targets.\n\n### 5. Bilateral vs. Third-Party Model\n\nThis is the sharpest divergence.\n\n**Wiki-Attestations** is fundamentally a *third-party verification model*: an attestor (distinct from the assertor) verifies someone else's claim. The attestor and assertor are different entities by design. This maps well to certificate authorities, auditors, inspectors, and credential issuers.\n\n**Service-Attestations** is fundamentally a *bilateral peer review model*: both parties to a transaction attest to each other, linked by a shared `d` tag. Alice reviews Bob as a provider, Bob reviews Alice as a client. The mutual attestation pattern, where both parties reference the same engagement ID, is the primary trust signal. There's no concept of a third-party verifier in the base spec.\n\n### 6. Sybil Resistance and Identity Anchoring\n\n**Wiki-Attestations** doesn't address Sybil resistance directly. It mentions NIP-03 (OpenTimestamps) for timestamping and NIP-58 (Badges) as complementary, but there's no mechanism to make attestations expensive to forge or to bind identities to external systems. The implicit assumption is that the attestor's reputation in the viewer's WoT is sufficient.\n\n**Service-Attestations** has a detailed Namecoin anchoring extension with a full verification algorithm, temporal binding requirements, failure modes, and a NIP-39 extension for profile linking. It also suggests Lightning payment proof (`bolt11` tag) and NIP-57 zap linkage as economic Sybil resistance. This is the most novel part of the spec and has no equivalent in Wiki-Attestations.\n\n### 7. Attestor Discovery\n\n**Wiki-Attestations** has a sophisticated attestor discovery mechanism through kind `31873` (recommendations) and kind `11871` (proficiency declarations). An attestor can say \"I'm good at verifying safety claims\" and others can recommend them. This creates a marketplace of verification services.\n\n**Service-Attestations** has no attestor discovery. It doesn't need one — there's no concept of a professional verifier. Everyone is both a potential attestor and subject.\n\n### 8. Payment Integration\n\n**Wiki-Attestations** includes a `cashu_token` tag on attestation requests, enabling payment-for-verification flows. You could lock a Cashu token to the condition that the attestor publishes a valid attestation. This is a compelling primitive for paid verification services.\n\n**Service-Attestations** includes `bolt11` as a payment proof tag (evidence the transaction happened) but not as a payment-for-attestation mechanism. The economic signal is backward-looking (\"we transacted\") not forward-looking (\"pay me to verify\").\n\n### 9. Relationship to Existing NIPs\n\nBoth reference NIP-40 (expiration) and NIP-58 (badges).\n\n**Wiki-Attestations** additionally leans on NIP-03 (OpenTimestamps) for blockchain anchoring — a lighter touch than the full Namecoin verification algorithm in Service-Attestations.\n\n**Service-Attestations** leans heavily on NIP-32 (labeling) for its vocabulary convention, NIP-39 for identity linking, NIP-85 as a consumer of attestation data, and NIP-99 (classified listings) as a source of service events.\n\n### 10. What Each Is Missing\n\n**Wiki-Attestations** lacks:\n- Domain-specific vocabulary for commerce/services\n- Bilateral attestation patterns\n- Numeric ratings\n- Role semantics\n- Sybil resistance mechanisms\n- Reputation aggregation guidance\n\nIf you tried to build a marketplace reputation system on it, you'd need to define all of these yourself.\n\n**Service-Attestations** lacks:\n- A request-response workflow\n- Attestor discovery and proficiency declarations\n- Revocation (it relies on replaceability + Attestation Sets rather than state changes)\n- The general ability to attest to arbitrary event truthfulness\n- The paid-verification primitive\n\n### Bottom Line\n\nThese two proposals are more complementary than competing. Wiki-Attestations is *infrastructure* — a general-purpose truth-claim layer that could underpin many applications. Service-Attestations is an *application* — a specific reputation protocol for a specific use case (commerce), with a specific anchoring mechanism (Namecoin).\n\nThe strongest version of both would be to build Service-Attestations' domain vocabulary and Namecoin anchoring as an application profile on top of Wiki-Attestations' base event structure. You'd use kind `31871` as the attestation container, add the `L`/`l` label vocabulary for service semantics, add the `rating` and `nmc` tags as extensions, and define a convention where bilateral attestations share a `d` tag. This would give you the lifecycle management and attestor discovery of Wiki-Attestations plus the domain specificity and Sybil resistance of Service-Attestations.\n\n---\n\n## Links\n\nThe full Service Attestation NIP draft can also be found here: https://gist.github.com/mstrofnone/5b40542c902069ed7e87ed96f93c1482\n","sig":"a6d96efe67991ce1bbbfc356ccac184b60bebe205aad2bae237f1a8ecd3e3d7e21b98c7cf039ce2addf9c2d67ed13d37a4f30bccffe262368ae1561370540737"}