NIP-33 Personal notes by dtonon · Pull Request #2271 · nostr-protocol/nips

dtonon · 2026-03-17T22:23:24Z

I took the number 33 since it was no longer in use.

dtonon · 2026-03-17T22:35:21Z

I’m leaning toward using a stripped-down version of Markdown (bold, italics, bulleted lists, and little else). It should be readable and easy to understand even if the client doesn’t explicitly support rendering. Any thoughts on this?

staab

For encryption, I would suggest following nip 17 and/or 94 conventions. For the lightweight markdown format you might follow #1800

staab · 2026-03-17T22:55:31Z

33.md

+| 33301 | Plain text note   |
+| 33302 | File attachment   |
+
+Kinds 33303–33309 are reserved for future use under this NIP. All kinds are **addressable events** (30000–39999 range per [NIP-01](01.md)), identified by a `d` tag set to a client-generated note ID. This enables in-place replacement (edits) and deduplication across relays.


We shouldn't have placeholders, it's ok if kinds are non-consecutive.

fiatjaf · 2026-03-17T23:27:57Z

Please pick a number with a hex character in it, like "3F" or something.

dtonon · 2026-03-18T10:12:08Z

@fiatjaf I don't care about the code; any one will do, 3F is fine.
Is it not recommended to reuse a NIP, even though it's deprecated and hardly ever mentioned?

dtonon · 2026-03-18T10:21:06Z

@staab do you mean these?

["file-type", "<file-mime-type>"],
["encryption-algorithm", "<encryption-algorithm>"],
["decryption-key", "<decryption-key>"],
["x", "<the SHA-256 hexencoded string of the file>"],

I dislike summary and subject for the textual part of an attachment, they communicate the wrong idea.

vitorpamplona · 2026-03-18T12:23:53Z

33.md

+The decrypted `content` for the above would be:
+
+```json
+{"text": "Remember to pick up groceries"}


Why is this a json? Is the content another format?

To have the same (flexible) structure of the attachment.
In future I will plan to add some other metadata.

Nah.. you can always use a new kind when the "future" stuff actually becomes needed. Don't design for untested what-ifs.

For me it doesn't make any sense to add a kind to manage, for example, a favorite bit or tags.

You will need to specify all of that; otherwise, the experience of clients who code the first version here will be broken because they won't display the other tags. If you don't have other tags right now, I wouldn't even parse this json.

Later, if you have other info, you can create a new kind that is just like this, but with a json with the properties you want in that JSON. Then, people implementing the old kind will still work, and they can decide to migrate to the new stuff with additional information in the json properties as needed.

It's a draft NIP while I'm still developing Manent, things will change quickly.
Creating a new kind for something like this seems complicated and unnecessary to me.
I'll just add the favorite bit, and that solves the problem.

vitorpamplona · 2026-03-18T12:28:01Z

33.md

+{
+  "filename": "photo.jpg",
+  "mime_type": "image/jpeg",
+  "size": 204800,


Dimensions are more important than size because clients can pre-compute screen layout and then just transition to the real image when it's available. Without it, everything moves in the UI.

Image dimensions should be a MUST everywhere.

I thought about that, but here we are talking about private notes that are displayed in a really simple structure. Anyway, adding the dimensions doesn't hurt, it can be useful to infer the orientation of an image.
File size is really important, since it allows to decide if the image/file should be downloaded automatically.

vitorpamplona · 2026-03-18T12:28:51Z

33.md

+
+```jsonc
+{
+  "filename": "photo.jpg",


The filename is just confusing. There is no need for this. The name of the file is the hash.

The filename is absolutely necessary. If I upload a document I WANT to know its exact original filename, not an useless hash. We don't just deal with images (where I might still be interested in the file name, btw).

Nobody chooses filenames in modern computing architectures... this is a 90s idea. Especially in this case where people will want the metadata info, not the filename as a reference.

It's not only a matter of users naming files (I do it, and many other people do it), but also softwares name files with useful bits of information (dates, usernames, etc) that are useful to quickly understand the content, especially when you cannot open/parse the file.
The filename is a metadata, trashing is without any valid reason is against user's interest.

If you are using Blossom, the filename is the hash. There is no way around it. Otherwise, the mirroring system fails, the API fails. It's fine to add a name or description to the file as extra information, but as long as you are using Blossom, it will never be an actual filename. That's why it is confusing (and to me completely unnecessary).

I cannot understand the problem. The filename is a metadata and I want to save it. When the user save back the file locally the original filename is proposed. What's the issue? I only see advantages.

It's just confusing... are we supposed to save files with that filename in disk when the user asks to save or to download? That breaks Blossom and makes things difficult to sync with other Blossom servers. Is the user going to see a readable filename in your app, but a hash on his own Blossom server? Why? That seems confusing too. How are they supposed to find things if the names keep changing?

To me, this is an unnecessary interoperability mess.

fwiw, I think filenames can have a lot of value; it doesn't matter if in blossom its served as the hash -- when you save it as whatever filename its been given

This doesn't break Blossom in any way. And it doesn't create any confusion for the user, that for sure doesn't know (and doesn't have to know) how the blob is stored remotely. Try Manent's UX, it's simply good and meets users' basic expectations of uploading and downloading a file with the same name, or simply check it, if needed.
The user comes first; any changes should respect the values that make the experience useful; don’t simply eliminate them for the sake of “protocol cleanliness.”

vitorpamplona · 2026-03-18T12:29:54Z

33.md

+
+## Notes
+
+To add an additional layer of privacy, clients SHOULD publish these events to personal or authenticated relays (e.g. via [NIP-42](42.md)) that only serve events back to their owner. Publishing to public relays is not forbidden, but it increases metadata exposure (everyone can observe pubkey activity and event timestamps).


Consider using the same relay list (kind: 10013) that NIP-37 Drafts use

Having a dedicated list is good, but I'm unsure about NIP-37: drafts are supposed to be temporary and so a relay, maybe a free public one, could clean them with a temporal logic; it is, however, essential that personal notes never be deleted.

It's not supposed to be temporary... It's just a relay list that is for private information that only the user has access to them. We save a lot of settings and other event kinds in there too. It because the main list for any private event that other users don't need to know you have.

vitorpamplona · 2026-03-18T12:30:29Z

33.md

+
+```jsonc
+{
+  "kind": 33302,


Why is this replaceable if blossom is not?

Because the caption can be updated (and any future metadata, e.g. tags).

vitorpamplona · 2026-03-18T12:31:22Z

33.md

+  "sha256": "<hex SHA-256 of the encrypted file bytes>",
+  "key": "<hex-encoded 32-byte AES-256-GCM key>",
+  "url": "<Blossom URL>",
+  "data": "<base64-encoded encrypted bytes>",


Are you storing image/video data in relays as base64?

IMO, drop this and make Blossom only. Optionality always sucks.

Files smaller than 32 KB MAY be stored inline, as stated in the NIP.
Again, we are not just dealing with media.

optionality sucks. 100% -- just store them in blossom, regardless of size -- blossom is for blobs; doesn't matter if its media or not

It's not about optionality, it's a kind of progressive enhancement. You can use just your relays for light (< 32KB) stuff without having any other dependencies, and add a blossom server (that is actually a spec outside Nostr) if you need to save other stuff.

vitorpamplona · 2026-03-18T12:33:23Z

33.md

+**Payload example (before encryption):**
+
+```json
+{"text": "<note content>"}


There is no point in this JSON. Just put the text in the content as usual.

Already explained before, this is needed for uniformity and future metadata.

staab · 2026-03-18T15:36:23Z

@staab do you mean these?
["file-type", "<file-mime-type>"],
["encryption-algorithm", "<encryption-algorithm>"],
["decryption-key", "<decryption-key>"],
["x", "<the SHA-256 hexencoded string of the file>"],
I dislike summary and subject for the textual part of an attachment, they communicate the wrong idea.

Subject is a nip 17 specific thing, I have no opinion on summary. But yeah, for encryption/hashing that's what I had in mind.

dtonon · 2026-03-18T15:49:52Z

Subject is a nip 17 specific thing, I have no opinion on summary. But yeah, for encryption/hashing that's what I had in mind.

Ok, it's fine for me.

NIP-33 Personal notes

2810906

staab reviewed Mar 17, 2026

View reviewed changes

vitorpamplona reviewed Mar 18, 2026

View reviewed changes

dtonon added 3 commits March 19, 2026 15:36

Rename some fields of the json payload

5b54ae8

Remove the statement about reserved kinds

63b8379

Add 'sensitive' field to the json payload

7da2813


		## Notes

		To add an additional layer of privacy, clients SHOULD publish these events to personal or authenticated relays (e.g. via [NIP-42](42.md)) that only serve events back to their owner. Publishing to public relays is not forbidden, but it increases metadata exposure (everyone can observe pubkey activity and event timestamps).

Conversation

dtonon commented Mar 17, 2026

Uh oh!

dtonon commented Mar 17, 2026

Uh oh!

staab left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fiatjaf commented Mar 17, 2026

Uh oh!

dtonon commented Mar 18, 2026

Uh oh!

dtonon commented Mar 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dtonon Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dtonon Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

staab commented Mar 18, 2026

Uh oh!

dtonon Mar 18, 2026 •

edited

Loading

dtonon Mar 19, 2026 •

edited

Loading