NIP-71: Add addressable video events (kinds 34235, 34236)

[rabble]

Summary

• Extends NIP-71 to support addressable video events for content that may need updates after publication
• Adds kinds 34235 (normal videos) and 34236 (short videos)
• Enables metadata corrections, URL migration, and preservation of imported content IDs from legacy platforms

Key Features

• Kind 34235: Addressable normal video events
• Kind 34236: Addressable short video events
• Required d tag: Unique identifier for addressable events
• Optional origin tag: Track original platform and ID for imported content
• Full compatibility: Same format as regular video events with addressable functionality

Use Cases

• Metadata corrections without republishing
• URL migration when hosting changes
• Vine/legacy platform migration (preserving original IDs)
• Platform migration tracking

Rough Consensus & Running Code.

The replaceable events for short form video work in amethyst and the upcoming vine like app.

• https://github.com/vitorpamplona/amethyst
• https://github.com/rabble/nostrvine
• https://github.com/rabble/divine_media_server
• https://github.com/rabble/divine-web

Test plan

• Updated NIP-71 with new addressable event kinds and format
• Added required 'd' tag documentation for unique identification
• Added optional 'origin' tag for tracking imported content
• Updated README with new event kinds 34235 and 34236
• Validated JSON examples and referencing format
• Clean branch without unrelated NIP-29 changes

[v0l]

I think its important to retain the hash of the video being unmodifiable, maybe add a metadata correction event that links to the kind 21/22 instead?

[fiatjaf]

The way @vitorpamplona did edits for kind:1 notes could be good here.

I'm against it for kind:1 notes, but for videos it may be a good idea.

[vitorpamplona]

If @rabble copies the edit's spec, he would only be able to change the .content of the event. That seems very restrictive in this event kind.

[vitorpamplona]

We could verify that the d tag is the hash of the video. In that way, you can change anything but the video itself.

[mplorentz]

This PR LGTM.

I do support the idea of making the d tag the hash of the video. Unlike edited text you can't provide users with a nice history or diff of what was changed in a video. And considering that other metadata like comments or even reaction videos may reference the original version it seems important in some cases that people cannot change the content of the video after posting.

But a counterpoint: if you really want edit your video after posting the current version of this NIP allows it. Just post it using the non-replaceable kind, and swap out the video hosted at the given URL. So as written this PR doesn't really make the situation much worse.

[rabble]

@fiatjaf i think we will want to update more than just the content. Assuming the client takes a while to get the thumbnail or gets additional meta data like tags. the .content is not really enough.