NIP-24: add published_at as a general tag for replaceable and addressable events

[alexgleason]

NIP-23 defines published_at for articles, which is a generally useful tag for replaceable events.

This tag is for display purposes only, and expects no special behavior from relays or clients. Clients can choose to use it to indicate the original publish date for an event (eg "joined at" for kind 0 profiles).

If the value is equal to the event's created_at, clients display that the event was "created" when the event is shown in feeds, while if it differs, clients can display that the event was "updated" when shown in feeds.

[vitorpamplona]

Imo, we should not create tags that affect other nips. Each nip should go through the process of updating their tag list to accept these common tags, one by one. In that way, implementers can simply track one nip and ignore what's happening in the others.

[alexgleason]

I want published_at for kind 0, every list kind in NIP-51, and many otherstuff kinds used by Ditto.

I suppose adding it to NIP-51 would cover the most ground at once. Kind 0 is arguably the most basic ("joined at" date).

But I also can't think of any replaceable or addressable kind where I would specifically not want this. Can you?

[vitorpamplona]

NIP-51 defines title, description, image for all lists. Every other NIP that uses those redefines them. I don't see a problem on them redefining when they need published_at

I also can't think of any replaceable or addressable kind where I would specifically not want this. Can you?

Most replaceables don't care about the first published_at. Let's not add things when they are not needed.

[alexgleason]

Most replaceables don't care about the first published_at.

I thought about it. You're right kind 3 doesn't need it. But wait, doesn't it? People overwrite those accidentally all the time. Having published_at helps determine which version to restore. It actually just seems like something that should be part of all replaceable events due to the way they work. But as a soft MAY and not a SHOULD or MUST, hence why to put it in NIP-24 instead of NIP-01. Because it's not really required, it's just helpful.

[vitorpamplona]

Because it's not really required, it's just helpful.

I know, but I really don't like interfering with other nips just because it MAY be helpful.

If it was actually helpful, it would have been there in the first place.

[alexgleason]

I'm fine with not merging this as-is. I can open a separate MR to add it to NIP-51 and kind 0 separately. I'm just not convinced it shouldn't be on every replaceable/addressable if it could. Unless there's some better system that would solve the same UX problem.