NIP-60: Record Events

[alexgleason]

This is a new take on kind 30382 and 30383 events, originally defined in Event Sets: #784 (Related: #761 #1321)

But it is a spec for generic records of pubkeys and event IDs, and it does not define n tags.

Read here: https://github.com/nostr-protocol/nips/blob/619ff20a871e4316ec59c2b211f20b4f8df26853/60.md

cc @arthurfranca @vitorpamplona

[arthurfranca]

I think it is better to try merging #784. Although 30382/31383 are important events, I think the others should also be listed, along with the standard n values, to enable migration from NIP-51 where it fits (be it some of the current NIP-51 lists or future ones).

For example, currently a mute list can include "p" (pubkeys), "t" (hashtags), "word" (lowercase string) or "e" (threads). So to mimick this we need events 30382, 30385, 30389 and 30383 with n-tag=mute.

[alexgleason]

@arthurfranca I want to get these kinds in the nips sometime this decade, and I think there's a better chance when it's kept simple. We can always expand this document later.

I have actually implemented kind 30382/30383 events as spec'd and am using it in a real project. I haven't implemented any of the others things in #784

[vitorpamplona]

I like simple NIPs that solve a specific problem, like this or #761, as opposed to a spec describing the basic framework to tag things like #784. It allows these NIPs to be expanded to support new tags for each kind.

However, #784 is a great base if people need to tag URLs, words, or other things. Maybe #784 mixed two ideas:

• Putting events into sets.
• "Labeling" things with replaceable events.

I think if we want Event Sets to become a thing, #784 could abandon the definition of standard d-tags, and just introduce the n tag with the nset. Then we can move each one of the "Standard" sets to it's own NIP and add more tags to help annotate each of these relationships.

In some ways, this NIP is more of a replacement for #761 than for #784. It just doesn't care about the private stuff on #761.

I just don't know if "Event Record" and "Pubkey Record" make sense to be in the same NIP. If so, this list will keep growing with the new things to tag/annotate.

[alexgleason]

I decided to strip it down because of #1264

They should be fully implemented in at least two clients and one relay -- when applicable.

I have not actually implemented private event sets, and don't have any immediate need to, even though I think they're a nice idea.

With this version we can actually get two implementations going and merge this.

[arthurfranca]

I think the event sets nip is very similar to NIP-51 in that lists/sets should be inside the same NIP.

Though relationship status does could be a separate thing by defining specifc tags (although these tags are present on event sets NIP as examples, I don't really explain them). The same way as #1321 defines a new tag and how to use them.

[arthurfranca]

I decided to strip it down because of #1264

This is just for looks. Instead of two implementations, a NIP proposal needs two blessings in order to be merged.
One from @fiatjaf and another one from one of these: @staab, @pablof7z or @jb55.
😁️

[staab]

I still stand by my comments here, but this is much better. As a primitive with far less semantics attached to it, it could be useful in novel situations. I do think it still violates the "do things one way" rule, and could lead to fragmentation, but it's at least concise.

[alexgleason]

The idea proposed here is simple. I would compare it to NIP-78. It is an emergent property of parameterized replaceable events. It seems obvious to me to have a generic event kind for d tagging a pubkey or event ID. Every developer thinks of this when they first read NIP-01. It WANTS to exist.

Event Sets would use this, but this NIP is specifically not Event Sets, even though it is inspired by it (I updated the OP to clarify). The NIP-61 proposal does not actually name the event kinds they propose, and only in #1321 did I first see the name "Set Item Reference". What I am proposing is more generic: "Record Event".

This NIP would not make Event Sets a reality. It would simply define and reserve these event kinds, because they are already being used.

[vitorpamplona]

I would change the name from Event Record (I don't know what it is meant to mean) to something like "Editable Stickers" because "Editable" is the most important part of this spec and you are "Sticking" additional properties into existing events and pubkeys.

[arthurfranca]

Now that its clear we don't want to use event sets to migrate from NIP-51, I see it is a good idea to remove the "Set Item Reference" events from there and add them here.

Starting with references for pubkeys and events as you did is probably be the best approach cause event kinds to reference other things could be added later as people see the need. But I think 30384 for referencing a replaceable event seems like a good addition?

I think it should also include the corresponding private kind numbers and the part from here that teaches how to obfuscate one-letter-tags (that can't be encrypted to .content to remain searchable) for the private use case.

[arthurfranca]

Well, in fact #761 (edit: I previously linked to the wrong one) already teaches the obfuscating part and introduces one of the private "record events".

I understand you want to keep this lean with just the part that has already been implemented. No need to change the PR.