nostr-protocol
NIP-71: Add addressable video events (kinds 34235, 34236)
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
dtag: Unique identifier for addressable events - Optional
origintag: 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
- [x] Updated NIP-71 with new addressable event kinds and format
- [x] Added required 'd' tag documentation for unique identification
- [x] Added optional 'origin' tag for tracking imported content
- [x] Updated README with new event kinds 34235 and 34236
- [x] Validated JSON examples and referencing format
- [x] Clean branch without unrelated NIP-29 changes
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?
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.
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.
We could verify that the d tag is the hash of the video. In that way, you can change anything but the video itself.
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.
@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.
I like that we use the same structure as the 21/22 events but be aware that this structure (field names, imeta) is incompatible with old existing 34235/34236 events, they used to have thumb and description fields.
Unrelated to this: I think the text-track field needs changes, but I'll create a new PR for that when I have figured it out.
old existing 34235/34236 events, they used to have thumb and description fields.
I think those where bugs in some client.. Olas I believe. We did imetas pretty early in the game.
Amethyst reverted the deprecations of the old event kinds to follow this PR.
Supposing I'll upload a Vine video and I know I won't change the video metadata, can I use the kind 22? @rabble
