Improving Nip01 Text by vitorpamplona · Pull Request #963 · nostr-protocol/nips

vitorpamplona · 2024-01-03T17:29:24Z

I have added some missing info and reduced some of the verbosity of the text. Moved kind:1 definition to NIP-10 (since it's not mandatory) and added descriptions about the replaceable tags.

Is this better?

Read here

arthurfranca · 2024-01-03T18:48:25Z

It looks better.
One important thing that got deleted was the implied descending sort order if using limit filter when the original text said "last n events ordered by the created_at"

vitorpamplona · 2024-01-03T18:53:57Z

Yep, it was duplicated. I kept only in the json descriptor.

fiatjaf · 2024-01-04T13:01:13Z

01.md

+  * `["EVENT", <subscription_id>, <JSON-serialized string of the event>]`, used to send events requested by clients.
  * `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time.
-  * `["CLOSED", <subscription_id>, <message>]`, used to indicate that a subscription was ended on the server side.
+  * `["CLOSED", <subscription_id>, <prefix>:<message>]`, used to indicate that a subscription was ended on the server side.


why isn't the OK message listed here?

I split them into a subscription protocol and a publishing protocol.

fiatjaf · 2024-01-04T13:02:28Z

I like this, let's do it.

…aphs.

vitorpamplona · 2024-01-04T13:32:48Z

@fiatjaf maybe later we can move the NOTICE part to a non-mandatory NIP. They are cool, but I think we must make NIP-01's feature set as small as possible while still covering the entire protocol.

jb55 · 2024-01-04T16:10:25Z

01.md

+This NIP defines the mandatory part of the Nostr protocol. New NIPs may add new optional (or mandatory) fields, messages, and features to the structures and flows described here.

-## Events and signatures
+# Events


I always call these Notes instead of Events in my codebases, but maybe the ship has sailed on that one because of ["EVENT",...]

"event" was probably a poor name choice, but "relay" too.

I thought kind 1 events are "notes". All notes are events but not all events are notes.

jb55 · 2024-01-04T16:12:28Z

README.md

 - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
 - [NIP-09: Event Deletion](09.md)
- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md)
+- [NIP-10: Text Notes](10.md)


NIP-10 is more about threads than Text Notes, you can have threaded events of different kinds.

NIP-10 is more about threads than Text Notes

Yes, but I think we need a place to coalesce all behaviors that are specific to kind:1. Getting it out of NIP01 opens space to add much more information about what should and should not be on kind 1s. NIP-10 can easily become that home since it was already kind1 specific.

threaded events of different kinds

The e and a definitions has been moved to NIP-01 since the previous restructuring. Now NIP-10 only defines what those mean for the kind:1 context.

vitorpamplona · 2024-01-04T16:33:41Z

FYI, I just noticed NIP01 never defines the type of each attribute in the Relay protocol messages. I think this new hack of using the js syntax highlight can be quite effective to separate type and description in a <> inside the json.

fiatjaf · 2024-01-04T18:05:48Z

What if we moved the basic protocol stuff to NIP-00 and used NIP-01 for the "basic microblogging client flow" including kind 0 and kind 1 -- then we can even include implementation recommendations like to which relays connect and how to better load threads, for example? Even conflicting alternative recommendations if that's the case.

staab · 2024-01-04T18:21:56Z

I think if we're going to restructure things that heavily, we might as well get rid of the NIP system

vitorpamplona · 2024-01-04T18:27:39Z

I do think it makes sense to separate the basic microblogging stuff out of the core protocol discussion but I am not sure the "basic microblogging stuff" is a well-defined set right now. For instance, I don't consider kind:0 to be "microblogging stuff".

# Conflicts: # 01.md

pablof7z · 2024-01-05T23:17:23Z

ACK on moving nip-01 to nip-00 and extracting the microblogging flow to it's own NIP.

I agree with @vitorpamplona in that kind:0 is not part of the microblogging flow

alexgleason · 2024-01-05T23:24:57Z

What if we moved the basic protocol stuff to NIP-00

It will make NIP-11's supported_nips potentially wrong. One thing I noticed after a bunch of NIPs were combined into NIP-01 is that you can no longer tell which relays support replaceable events or parameterized events.

vitorpamplona · 2024-01-06T00:36:08Z

which relays support replaceable events or parameterized events

In theory, both are required to be supported these days.

pablof7z · 2024-01-06T00:42:50Z

It will make NIP-11's supported_nips potentially wrong.

Only as far as supported_nips not indicating that NIP-00 is supported, but given that NIP-00 is required that can be implied (otherwise it's not nostr and you wouldn't see a supported_nips at all)

The only caveat is that NIP-01 must remain backward-compatible so relays don't lie when they say they support NIP-01.

vitorpamplona · 2024-01-09T18:42:41Z

This is also ready to merge if people agree it's better than the current NIP-01 description.

01.md

schmijos · 2024-01-11T10:42:48Z

01.md

+All single-letter (only English alphabet letters: a-z, A-Z) tag names are indexed by relays for faster queries. 

-These are just conventions and relay implementations may differ.
+This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY `a`- and `e`-tag parameterized replaceables simultaneously.


Suggested change

This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY `a`- and `e`-tag parameterized replaceables simultaneously.

This NIP defines the format of 4 standard tags: `e`, `p`, `a` and `d`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY set `a`- and `e`-tag parameterized replaceables simultaneously.

Do we really need to duplicate the definition here? Tag d was already defined in the previous section.

schmijos · 2024-01-11T10:43:59Z

01.md

+| Name | Value                                                      | Other Params            |
+| ---- | ---------------------------------------------------------- | ----------------------- |
+| `e`  | `<32-byte lowercase hex of an event id>`                   | `<relay URL, optional>` |
+| `p`  | `<32-byte lowercase hex of a pubkey>`                      | `<relay URL, optional>` |
+| `a`  | `<kind>:<32-byte lowercase hex of a pubkey>:`              | `<relay URL, optional>` |
+| `a`  | `<kind>:<32-byte lowercase hex of a pubkey>:<d-tag value>` | `<relay URL, optional>` |


Where is now #d ?

hum.. I was hoping d wouldn't be part of this table since it's different than the other referencing tags.

Let me explain why I have difficulties with the "d" tag.
I looked at the README and saw: "Aha, there's an official #d. Let me have a look at what this means."
I then go to NIP-01 where it's supposed to be defined. I ctrl-f through the page on GitHub and don't find it.

After your PR here, when I ctrl-f, I'll still be confused because I'm lazy and I'll find two things:

A statement saying

This NIP defines the format of 3 standard tags: e, p, and a.

Where the heck is now #d?

A table with e, p and a
Why the heck is it missing #d?

01.md

# Conflicts: # 01.md

mikedilger · 2024-03-28T21:56:57Z

01.md

+# Signed Events

-Event is the only object type available. It is a hashed and signed payload in the following format:
+Events are the only data type transferred across the network. They consist in 4 main attributes: 


5 main attributes

3 m'lord, 3

6 if you count id?

5 things are hashed: pubkey, created_at, kind, tags, and content. The other 2 are generated: id, sig

# Conflicts: # 01.md

vitorpamplona · 2025-07-31T14:25:03Z

Closing this due to partial adoption via other PRs. Though I still think the Relay section is better described here (separated by action) than in the current nip01.

vitorpamplona added 14 commits January 3, 2024 11:23

Rewriting NIP-01

0c37bd1

Improve formatting

8f739d0

Formatting

5e437f0

header formats

c4cc963

Typos

2c0b534

improves naming and formats

6231cbc

consistency

f0d0fb4

Formatting change

3fa03a1

opening some space.

8dfb59c

Removing ]

99201a0

typos

b6ddf59

fixes the definition

c4f3164

adjustments

2b6edc0

adjustments

f2e016f

vitorpamplona added 8 commits January 3, 2024 13:54

Improves singing and verification procedures.

6feac3e

Adds better explanation for limit

f69e5b2

Improving the d-Tag needs and prefixes in messages.

e1b9ffd

Moves the kind 1 definition to NIP-10

c4daa69

Better defining kind:0

2f8da3a

Updates readme to match new kind 1 definition

2511931

Adds description about the replaceable format.

9bbf505

Fix the new NIP-10 name

309298a

fiatjaf reviewed Jan 4, 2024

View reviewed changes

Additional adjustments and further breaking down the text into paragr…

479561c

…aphs.

vitorpamplona added 2 commits January 4, 2024 08:43

formatting

3a06859

Typos

b36336b

jb55 reviewed Jan 4, 2024

View reviewed changes

declaring types in the relay protocol messages

a4d656a

Merge remote-tracking branch 'upstream/master' into improving-nip01

b5e6244

# Conflicts: # 01.md

vitorpamplona mentioned this pull request Jan 10, 2024

Remove "d" tag reference from README #982

Closed

schmijos reviewed Jan 11, 2024

View reviewed changes

01.md Outdated Show resolved Hide resolved

schmijos reviewed Jan 11, 2024

View reviewed changes

vitorpamplona added 2 commits January 11, 2024 08:57

Clarify the unmodifiable nature of the dtag and its uniqueness needs.

fe9792b

Changes standard tags to be referencing tags.

bf2218d

AsaiToshiya reviewed Jan 13, 2024

View reviewed changes

01.md Show resolved Hide resolved

Merge remote-tracking branch 'upstream/master' into improving-nip01

17e2bd7

# Conflicts: # 01.md

vitorpamplona requested a review from fiatjaf February 1, 2024 13:23

vitorpamplona mentioned this pull request Feb 23, 2024

Moves Kind:1 definition to NIP-10 #1076

Merged

vitorpamplona added 4 commits March 28, 2024 09:42

Adds further descriptions to the event fields.

e3c1e88

fixes number of attributes

92badf4

separating calculated and inputted attributes.

0b24ad8

Expands the explanation of kind ranges.

61fd568

mikedilger reviewed Mar 28, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/master' into improving-nip01

dda1b24

# Conflicts: # 01.md

vitorpamplona closed this Jul 31, 2025

	This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY `a`- and `e`-tag parameterized replaceables simultaneously.
	This NIP defines the format of 4 standard tags: `e`, `p`, `a` and `d`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY set `a`- and `e`-tag parameterized replaceables simultaneously.

Conversation

vitorpamplona commented Jan 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arthurfranca commented Jan 3, 2024

Uh oh!

vitorpamplona commented Jan 3, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fiatjaf commented Jan 4, 2024

Uh oh!

vitorpamplona commented Jan 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

vitorpamplona Jan 4, 2024 • 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!

vitorpamplona commented Jan 4, 2024

Uh oh!

fiatjaf commented Jan 4, 2024

Uh oh!

staab commented Jan 4, 2024

Uh oh!

vitorpamplona commented Jan 4, 2024

Uh oh!

pablof7z commented Jan 5, 2024

Uh oh!

alexgleason commented Jan 5, 2024

Uh oh!

vitorpamplona commented Jan 6, 2024

Uh oh!

pablof7z commented Jan 6, 2024

Uh oh!

vitorpamplona commented Jan 9, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vitorpamplona Jan 11, 2024 • 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!

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!

vitorpamplona commented Jul 31, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

vitorpamplona commented Jan 3, 2024 •

edited

Loading

vitorpamplona commented Jan 4, 2024 •

edited

Loading

vitorpamplona Jan 4, 2024 •

edited

Loading

vitorpamplona Jan 11, 2024 •

edited

Loading