tl;dr *source kimi k3* Yes, that's essentially correct — your reconciliation captures the architecture accurately. Let me just polish three small points so your understanding is airtight. ## What's exactly right - **"Foundational use of NIP-94"** — correct. NIP-94 provides the existing vocabulary (`url`, `x` hash, `m` MIME type, `size`, `fallback`). Your new NIP doesn't reinvent any of that; it inherits it. - **"Adapted to ZIP"** — correct. The payload becomes `application/zip` instead of loose files, which is what gives you single-hash verification of text + media together. - **"Published on an HTML webpage"** — correct in spirit: the ZIP contains a self-contained web page (`index.html` + assets) rather than a markdown fragment. ## Three refinements **1. It's not "rendered by" the client so much as "extracted and sandboxed by" the client.** The distinction matters for security. The client doesn't just navigate to the page — it downloads the ZIP, verifies the SHA-256 against the signed tag `x`, unpacks it in memory, sanitizes the HTML, and renders it inside a sandboxed iframe with no script execution. If you phrase it as "rendered," someone will build a version that iframes the remote URL directly, which defeats the entire hash-verification model and opens a phishing vector. The page is *fetched as bytes, verified, then rendered locally*. **2. "Agnostic" needs a caveat.** Any client can implement it (it's platform-agnostic, works on web/mobile/desktop), but no client is *automatically* agnostic — each one must explicitly support the new kind. The graceful degradation is what makes this palatable: clients that don't support it still show the plain-text excerpt from `content`, so the note never appears broken. **3. The event kind matters.** It's not literally a `1063` (NIP-94's kind, which is *not* replaceable). For your edit/delete requirement you want a **parameterized replaceable kind** (e.g. `30163`) that *reuses NIP-94's tag conventions* — that's the precise sense in which the new NIP is "founded on" NIP-94. Same tags, different envelope, replaceable so edits work cleanly. ## Your reconciliation, restated precisely > A new NIP that reuses NIP-94's tag vocabulary (`url`, `x`, `m`, `fallback`) on a parameterized replaceable kind, where the payload is a ZIP containing a self-contained HTML page; supporting clients download the ZIP, verify it against the signed hash, and render it sandboxed — while non-supporting clients gracefully fall back to the plain-text excerpt in `content`. That's it. That's the whole idea, and it's sound. The only remaining work is writing the spec (ZIP structure, sanitization rules, size limits) and getting one client to implement it.