How do we cite a non-parametrized but replaceable event (10000-19999)?

[vitorpamplona]

Tagging events in the range 10000-19999 is not defined. Can we converge in a common way?

I propose using the same a tag we use for parameterized events, but with the d tag equals "". So, tagging a pin list (kind:10001) would be:

["a", "10001:<pubkey>:", "<relay url>"]

It leaves an extra : in the end of the tag, but that also happens with parametrized events.

Super easy.

[fiatjaf]

What is the use case? Normally you only need the context and the pubkey of the author. For example, the app wants to fetch a user metadata, it only needs the pubkey, the kind 0 is implied by the context. Same for contact lists, relay lists, mute lists etc.

It feels to me that if you require a kind to be explicitly specified there something may be wrong in the way you're modeling the problem.

[vitorpamplona]

To tag in another event. You have a kind 10000-19999 established and now you want to do a nostr: citation in the body of a Kind 1 or on a blog post. You shouldn't use the e tag because it will get outdated. So, it must be some type of a tag. But there is no d value to make a full a tag.

[fiatjaf]

But why would you ever want to cite a contact list while also ensuring it doesn't get outdated?

[vitorpamplona]

Because I want to share that list with other folks so they can subscribe to the people in it or to the list itself.

[staab]

I want to do this to disambiguate different uses of a pubkey. A npub/nprofile = a user profile, but #706 uses pubkeys not connected to a person to administer a group. I'd like to be able to share the group by pointing to its metadata event (whether it exists or not). A kind 10024 event would be encoded as a naddr and interpreted by clients as a group listing.

Of course, maybe the proposal will look different ultimately, but it does illustrate a use case for having naddr defined for replaceable events.

[vitorpamplona]

I think this is a no-brainer. We just need to declare one specification and go.

[mikedilger]

I haven't come across a need for this, but it sounds like there are cases and it's a reasonable proposal.

[pablof7z]

ACK on the proposed reuse of the NIP-33 format.

["a", "10001:<pubkey>:", "<relay url>"]

[fiatjaf]

I understand what you're trying to do here and I understand the appeal of it, so please go ahead with it, but for the record I still think it's a bad idea. If you want to share a contact list you could just have a tag in your event that means "I am sharing a contact list" and then clients will fetch the contact list from that person that is speaking. Or you could share a specific event id for some use cases. Anyway I'll close this and move to the PR above.