Add NIP-XXX: Encrypted Binary Attachments for Notes and DMs

[jab-r]

Summary:
This proposal standardizes how Nostr events reference binary attachments (images, audio, video, documents), supporting both unencrypted and encrypted forms. It introduces two new tag types (attach, eattach) for public events and a normalized JSON schema for private DMs. Attachments are integrity-verified via SHA-256, with optional AES-256-GCM encryption for privacy-preserving sharing.

Motivation:
Currently, clients handle attachments inconsistently (inline URLs, bespoke JSON). This NIP provides a consistent, interoperable, and secure mechanism for referencing files across clients and relays, aligning with NIP-17 (DMs) and NIP-EE (MLS) with optional NIP-94 (File Metadata), NIP-96 (HTTP File Storage), and NIP-98 (HTTP Auth).

Highlights:
• attach tags for unencrypted files in public notes
• eattach tags for encrypted files (with ekref key-delivery conventions)
• JSON schema for encrypted attachments in DMs
• Per-attachment AES-256-GCM with normative key/iv/tag sizes
• Metadata for MIME, size, filename, alt text, blurhash, etc.
• Clear integrity and security requirements

Implementation:
A reference implementation is available in loxation-sw (per-attachment AES-256-GCM, presigned upload/finalize).

[vitorpamplona]

This NIP provides a consistent, interoperable, and secure mechanism for referencing files across clients and relays, aligning with NIP-17 (DMs), NIP-94 (File Metadata), NIP-96 (HTTP File Storage), and NIP-98 (HTTP Auth).

I don't think this is desirable. All these NIPs need different things out of their "attachments," and all must evolve independently from each other if they ever need more than what they have today.

NIP-94, for instance, doesn't want encrypted files.
NIP-96 doesn't care if it is encrypted or not; none of this matters for that NIP.
NIP-17 requires a specific file encryption algorithm to be used, and nothing else is supported on purpose.
NIP-98 doesn't have attachments and doesn't need to have.

[jab-r]

Not redundant; complementary.

NIP-17 defines the transport and envelope for direct messages (how DMs are published, authenticated, and encrypted end-to-end), but it does not standardize:

• Attachment data model across public events and DMs
• Tag formats for public notes (attach/eattach) with normative field names and sizes
• Integrity semantics (sha256 over ciphertext) and mapping to NIP-92/NIP-94
• A transport-agnostic JSON shape for attachments inside DMs
• MLS-specific guidance (exporter-derived key/nonce, epoch scoping)
• A safe, reusable DM attachment envelope (ek/epk/wrap) that avoids embedding a raw symmetric key in plaintext DM content

docs/nip-xxx-binary-attachments.md fills those gaps by:

• Unifying attachments for both public notes and DMs with a single, consistent schema
• Defining normative AES-GCM sizes (key=32, iv=12, tag=16) and integrity hashing over ciphertext
• Aligning with other NIPs (NIP‑92/NIP‑94/NIP‑96/NIP‑98) for interop
• Specifying a safe DM attachment envelope (X25519‑HKDF‑AESGCM) and an MLS path (exporter-derived AEAD) that are transport‑agnostic

How to keep the boundary clean

• Keep NIP‑XXX authoritative for attachment metadata, tags, integrity, and the DM/MLS attachment keying models.
• Have NIP‑XXX normatively reference NIP‑17 for the DM transport (outer DM encryption, auth, relay behavior) instead of restating DM mechanics.
• Keep the DM JSON schema in NIP‑XXX minimal and focused on attachments; do not duplicate NIP‑17’s event structure or encryption choices beyond what’s needed.
• Make clear that the DM envelope (ek/epk/wrap) is optional in the sense that the outer DM is still NIP‑17 compliant, but recommended because it removes plaintext key exposure and enables multi‑transport reuse and fan‑out.

Bottom line: NIP‑XXX is the media/attachment standard that DMs (NIP‑17) and public notes can both use. It references NIP‑17 rather than duplicating it, so it is not redundant; it scopes a different, missing concern (attachment normalization, integrity, and safe key conveyance) across transports.

[vitorpamplona]

I didn't say it was redundant... What I said is that standardizing the same format for multiple NIPs is not ideal because each NIP evolves in different ways and will need this format to evolve too in diverging ways, breaking the other NIPs that are using the old format because they will not be expecting new behaviours.

Every time we tried to standardize tags across NIPs, we created a bigger mess. Currently, there is no tag, not even the ubiquitous p tag, that has the same syntactic format and semantic meaning in all event kinds/NIPs. Each NIP redefines every tag.

[jab-r]

the NIPs aren't authoritative to other NIPs though, so e.g. NIP-17 can evolve, and other's can have bespoke attachment formats. The standardization is for people that don't want to roll their own, right?

I am trying to roll AES-GCM and MLS for attachments

[vitorpamplona]

Correct, but NIP-17 can evolve in a way that would break this format here. It works now, but it will likely not be the case in the future. So, if the goal is to standarize, I think that will fall short.

If the goal here is to just describe the format you will be using in MLS regardless of what other NIPs do, then it's fine. It should probably be part of the MLS NIP, though... if that is what you are trying to do.

[jab-r]

I am trying to integrate 1:1 encrypted messaging with MLS, if NIP-17 evolves and say I've implemented this then the evolution will break it regardless of NIP or not ... or maybe the implementation never gets updated so implementation won't be compatible, at least we would have a single place to update?

[vitorpamplona]

All I am saying is that your motivation of "Currently, clients handle attachments inconsistently (inline URLs, bespoke JSON). This NIP provides a consistent, interoperable, and secure mechanism for referencing files across clients and relays, aligning with NIP-17 (DMs), NIP-94 (File Metadata), NIP-96 (HTTP File Storage), and NIP-98 (HTTP Auth)" is not a good goal. If that is why you are developing this, then it will fail to reach its goal.

But if the goal is just to make a new format that you can use in MLS only, sure. That makes way more sense.

Nostr will always be inconsistent between NIPs because they solve for different needs. Trying to bring consistency between NIPs is a futile effort.

[jab-r]

Ok, yeah I was being too broad, I want a format that I can use with encrypted binary data both 1:1 and MLS (group)