Stacks + Nostr
  • Introduction: Stacks + Nostr
  • SIP and NIP Summaries
    • SIP Summaries
      • SIP-000: The Stacks Improvement Proposal Process
      • SIP-001: Burn Election
      • SIP-002: The Clarity Smart Contract Language
      • SIP-003: Stacks P2P Network
      • SIP-004: Cryptographic Commitment to Materialized Views
      • SIP-005: Blocks, Transactions, and Accounts 👀
      • SIP-006: Clarity Cost Execution Assessment
      • SIP-007: Stacking Consensus
      • SIP-008: Clarity Parsing and Analysis Cost Assessment
      • SIP-009: Standard Trait Definition for Non-Fungible Tokens
      • SIP-010: Standard Trait Definition for Fungible Tokens
      • SIP-012: Burn Height Selection for a Network Upgrade to Introduce New Cost-Limits
      • SIP-013: Standard Trait Definition for Semi-Fungible Tokens
      • SIP-015: Stacks Upgrade of Proof-of-Transfer and Clarity
      • SIP-016: Metadata for Tokens
      • SIP-018: Signed Structured Data
      • SIP-020: Bitwise Operations in Clarity
    • NIP Summaries
      • NIP-1
      • NIP-2
      • NIP-3
      • NIP-4 👀
      • NIP-5 👀
      • NIP-6 👀
      • NIP-7
      • NIP-8
      • NIP-9
      • NIP-10
      • NIP-11
  • Feature Unlocks
    • Decentralized Identity Verification
    • Censorship-Resistant Social Networking
    • Secure Asset Management
    • Private Voting and Governance
    • Decentralized Notifications
    • Trustless Collaboration
  • Related Tech 👀
    • BNS
    • sBTC
  • Experimental Design and Methodology
  • Results and Discussion
  • Conclusion
  • Additional Research
    • ZKP
    • Indistinguishability Obfuscation from Well-Founded Assumptions
  • SIP-xx Draft
  • Disclaimer:
Powered by GitBook
On this page
  1. SIP and NIP Summaries
  2. NIP Summaries

NIP-10

NIP-10 provides guidelines on using "e" and "p" tags in text events for better thread organization and reply handling. It deprecates the use of positional "e" tags and suggests using marked "e" tags

NIP-10 discusses the use of "e" and "p" tags in text events (kind 1), specifically in replies to other text events. It aims to help clients thread replies into a tree rooted at the original event.

Positional "e" tags (DEPRECATED): The positional "e" tags are now considered deprecated, but they were commonly used in the following ways:

  • No "e" tag: The event is not a reply or reference to any other event.

  • One "e" tag: The event is a reply to another event.

  • Two "e" tags: The event is a reply to another event, with a root event id and a reply event id.

  • Many "e" tags: The event contains a root event id, multiple mention event ids, and a reply event id.

Marked "e" tags (PREFERRED): The marked "e" tags are preferred because they allow events to mention others without confusing them with reply or root ids. Marked "e" tags have the following structure:

  • ["e", <event-id>, <relay-url>, <marker>]

  • <marker> can be "reply," "root," or "mention."

The "p" tag: The "p" tag is used in text events to record who is involved in a reply thread. When replying to a text event, the reply event's "p" tags should contain all the original event's "p" tags and the pubkey of the event being replied to.

Example: Given a text event authored by a1 with "p" tags [p1, p2, p3], the reply should have "p" tags [a1, p1, p2, p3] in no particular order.

PreviousNIP-9NextNIP-11

Last updated 2 years ago