Improving Nip01 Text

[vitorpamplona]

trafficstars

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]

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]

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

[fiatjaf]

I like this, let's do it.

[vitorpamplona]

@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.

[vitorpamplona]

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]

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]

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

[vitorpamplona]

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".

[pablof7z]

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]

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]

which relays support replaceable events or parameterized events

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

[pablof7z]

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]

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