NIP-DA: Permissioned Private Data Sharing (Scoped Data Grants)

[JAFairweather]

This NIP defines permission-based sharing of private, live-updating personal
data (e.g. contact cards) between keyholders. Each user maintains one
encrypted, authoritative record per scope on relays; access is granted by
privately delivering the scope's symmetric key inside a NIP-59 gift wrap.
Relays store only ciphertext and never learn who granted access to whom.
The result: contact data with N self-maintained records instead of N²
rotting copies — updates are free, revocation is a key rotation, and the
address book becomes an emergent view.

Against the submission criteria:

• Two clients: two independent implementations sharing nothing but this
  spec — a JavaScript reference library (isomorphic Node/browser, powering a
  working contact-manager client) and a Go CLI built on go-nostr. A
  cross-implementation test runs both against public relays: each decrypts
  the other's scopes via the other's grants, detects the other's key
  rotations as staleness, and recovers the address book from the other's
  Grant Index.
• One relay, when applicable: not applicable, by design — this NIP
  requires nothing beyond NIP-01 addressable-event semantics and is verified
  working today against relay.damus.io, nos.lol, and relay.primal.net with
  zero relay changes.
• Optional and backwards-compatible: clients and relays that ignore
  these kinds are unaffected.
• No duplicate mechanism: NIP-17 DMs can carry a vCard but provide no
  liveness, no O(1) updates, and no revocation; NIP-51 private lists carry
  no key material. This fills the gap between "public kind-0 profile" and
  "DM someone a snapshot that rots."
• License: CC0.

Related proposals (surveyed before submitting; none covers this):

• NIP-EE / Marmot (MLS) solves E2EE group messaging — evolving
  conversation streams with forward secrecy. This NIP solves authoritative,
  addressable data records with live dereference; the problems are
  orthogonal and the mechanisms don't substitute for each other.
• NIP-112: Encrypted Group Events #580 (NIP-112 Encrypted Group Events) distributes a shared secret for
  group chat channels — the closest mechanical cousin, but aimed at
  messaging; no addressable data sets, no generation counter, no
  rotation-revocation semantics for a personal record.
• NIP-XX: Dual Encryption and ECDH Delegated Access #2258 (Dual Encryption / ECDH Delegated Access) makes
  organization-published records dual-decryptable by org and individual,
  with member key delegation. Different topology: org→individual documents
  vs. a self-maintained personal record granted to N parties.
• Storage of encrypted contacts #621 (Storage of encrypted contacts) asks for standardized
  self-encrypted contact storage — that's this NIP's Grant Index received
  side, and evidence of the demand — but proposes no sharing mechanism at
  all.

Reference implementations, tests, and a working client:
https://github.com/JAFairweather/nostr-scoped-data-grants

Kinds requested: 30440 (Scoped Data Set), 440 (Data Grant), 441 (Revocation
notice), 10440 (Grant Index) — unassigned at the time of this PR; happy to
renumber if there are conflicts or conventions I've missed.