Create NIP 71 for Video Events

[zmeyer44]

Nip for Video Events to enable dedicated video clients (e.g. Netflix, YouTube) to be built on nostr.

[erskingardner]

I'm curious to know if you've thought about the situation where the underlying video file can be swapped out, thus rendering views and any engagement (reactions, replies, etc) disconnected from the current video content. At best it's confusing, at worst it could be very damaging (e.g. a video about nostr with lots of positive engagement gets swapped with something illegal or horrible. All the people who reacted and commented on the original would appear to have been supporting the new video).

[zmeyer44]

reacted and commented

Yeah, that's a great point. I suppose one solution could be to tie likes/reactions to a specific version of the post, although, since the user could control the server where the content is hosted, this could still be exploited since the Video Event itself would not need to change for the content to be changed. To some degree, this is an issue with kind 1's as well. Anyone can post a heartwarming image/video as a kind 1, receive a bunch of positive replies, and then swap what the image/video URL is pointing to a malicious video.

[vitorpamplona]

I would try to match the tags used in NIP-94: https://github.com/nostr-protocol/nips/blob/master/94.md

src -> url
image and thumb are separate things.

Video dimensions (dim) are extremely important for a smooth experience when scrolling

Instead of doing one value for progress you can do [viewed, <start>, <end>], so when people jump around, there is a way to inform which sections were actually viewed and how much of it.

Since there is only one kind:34236 per person per video, I would make it's d tag equals the a tag, instead of a random UUID.

You might want to make 2 video kinds, one for vertical viewing (Stories, Reels, Shorts, etc) and one for horizontal content (monitors, TVs, etc). It's likely that the two video type require different interfaces and clients might one to filter each independently.

[zmeyer44]

viewed

Thanks! Great points, I just made those changes.

[staab]

I would try to match the tags used in NIP-94

I would even go so far as to say that this should just be an update to NIP 94. m already exists, so you can filter by format already, you would basically just add new kinds for different use cases, plus any new tags that are needed. Also, NIP 44 is pretty well-known as the new encryption spec, which should land any day now™️.

[zmeyer44]

Also, NIP 44 is pretty well-known as the new encryption spec, which should land any day now™️.

Happy to change the number lol, I didn't realize it was about to be filled by another nip.

I think that video and video clients are a substantial enough use case on today's internet that warrants its own Nip. Nip 94 seems to be focused on file sharing and organization, rather than the social and entertainment focus for this Nip. Nip 94 states that it is not expected to be implemented by "social" clients that deal with kind:1 notes or by long-form clients and while I think users of this Nip will be primarily video-centered clients, I could certainly imagine a world where a user's videos live alongside their kind 1's or kind 30023's on certain clients.

[vitorpamplona]

Amethyst uses NIP94 for our Stories-like feature, which also accepts images and audio files. Replies, boosts, likes, zaps and reports are done on the nip94 directly.

The only option that this one provides that NIP-94 doesn't is the text-track tag. But one can easily add it there as well.

I assume this PR uses a replaceable event for a specific reason. One could do a replaceable event that points to a NIP-94 event. So, if the user changes the video, you get a whole new NIP-94 event and just point to the new one.

If you want, the NIP-94 event can event be inside the .content of the replaceable. Then this PR would simply separate a video library from every other type of attachment a user might have.

[zmeyer44]

That's an interesting idea. How exactly would you format the .content to hold the NIP-94 event?

[vitorpamplona]

Similar to the Repost event: just serialize the signed NIP-94 into the other event.

[zmeyer44]

Similar to the Repost event: just serialize the signed NIP-94 into the other event.

Let me know if this is what you were talking about. I really like this solution

[vitorpamplona]

Let me know if this is what you were talking about. I really like this solution

It's a nice improvement in theory, but you are the one coding. It has to be better for you :)

[zmeyer44]

Let me know if this is what you were talking about. I really like this solution

It's a nice improvement in theory, but you are the one coding. It has to be better for you :)

I guess I'll get to work then 😄

[pablof7z]

The only option that this one provides that NIP-94 doesn't is the text-track tag. But one can easily add it there as well.

Since we already have "transcriptions" events, the text-tract should just be a kind:6000 with [ "output", "text/vtt" ].

[pablof7z]

reacted and commented

Yeah, that's a great point. I suppose one solution could be to tie likes/reactions to a specific version of the post, although, since the user could control the server where the content is hosted, this could still be exploited since the Video Event itself would not need to change for the content to be changed. To some degree, this is an issue with kind 1's as well. Anyone can post a heartwarming image/video as a kind 1, receive a bunch of positive replies, and then swap what the image/video URL is pointing to a malicious video.

Yeah, this kind of thing has been brought up multiple times but I always feel unpersuaded by this argument; we've been sharing URLs for decades and this "you said you liked a nazi website!" attack is basically non existent.

Furthermore, events a tagging should also do e tags to point to the specific version they are tagging, so I wouldn't worry about this at all.

[shocknet-justin]

Lightning.Video guy here,

We've been thinking about this as well, a few things missing imo,

• magnet link support, this allows for WebTorrent p2p swarming, redundant CDNs, and ensures the file hash is the same as the publisher intends
• chapters (both paid an unpaid), some refer to these as timestamps in their simplest form... eg click to a specific second in the player. Not sure what the paywalled video NIP will look like, but should probably at minimum be able to reference another event for the paywalled chapters. Another way to think of this is Trailer / Movie as separate chapters.

[basantagoswami]

Maybe we just need an extension to NIP-94 File Metadata with a parameterized replaceable event, that can only update the video URL, in case your current provider disappears.

That way the video (or whatever file) hash (via NIP-94's x and magnet tags) remain the same.

[vitorpamplona]

Maybe we just need an extension to NIP-94 File Metadata with a parameterized replaceable event, that can only update the video URL, in case your current provider disappears.

That way the video (or whatever file) hash (via NIP-94's x and magnet tags) remain the same.

There is no way to limit updates just to a single tag. :(

There is some discussion related to this in the new NIP-96 Image Server NIP: #547 (comment)

The idea is to use an ox hash for the original file and several x, m, dim, and size for each variation each server provides. We can then use a single NIP-94 to store each one of these OR add several tags inside a single NIP-94 to create redundancy.

But here, because you have the replaceable event, you can easily just replace one nip-94 for another.

[fiatjaf]

Number is so much better. Can we do numbers?

[zmeyer44]

Yeah, just numbers works. (I'm assuming in seconds)

[pablof7z]

This is basically the same intent as @staab 's #933

I think we should just use kind:15 here too with a [ "range", "<start>", "<end>" ]

[pablof7z]

I think a NIP-33 is a bit of an overkill here.

[zmeyer44]

This is basically the same intent as @staab 's #933

I think we should just use kind:15 here too with a [ "range", "<start>", "<end>" ]

I think that it would be useful to have both a kind 15 "Seen event" and an independent "View event". The main purpose of the kind 15 would be to clear notifications which makes sense in the context of checking your feed of subscriptions to see if anything new has been posted. But the kind 34237 is intended to indicate a video view, to both allow for users to continue from where they left off as well as allow clients to show a YouTube-like view count for a particular video. This may be useful for creating algorithmic feeds down the line.

[vitorpamplona]

I noticed that the summary tag and content are duplicated. Can we just use one? I think .content is enough.

[vitorpamplona]

Also, is the goal here to host only URLs that have their own players like YouTube? Or is it also for a direct video link?

I don't think native clients will be able to play YouTube content. They will need to redirect to the youtube app.

[zmeyer44]

Also, is the goal here to host only URLs that have their own players like YouTube? Or is it also for a direct video link?

I don't think native clients will be able to play YouTube content. They will need to redirect to the youtube app.

I think that the goal should be for the url to point to the direct video link. Seems silly to be relying on YouTube in the long-term. On Flare dot pub the player I'm using is able to pull in the video from a YouTube url so it works seamlessly, but this is definitely not the right way to go long-term. I see it as a nice low barrier to entry way to get more people posting.

[vitorpamplona]

Amethyst now renders these new types as well.

[zmeyer44]

@fiatjaf are we ready to have this merged?

[pablof7z]

Add the kind and NIP to the README, @zmeyer44 and I'll merge

[jb55]

On Thu, Feb 01, 2024 at 12:15:04AM -0800, zmeyer44 wrote: @fiatjaf are we ready to have this merged?

how many clients implement this?

[zmeyer44]

On Thu, Feb 01, 2024 at 12:15:04AM -0800, zmeyer44 wrote: @fiatjaf are we ready to have this merged?
how many clients implement this?

I believe Flare, Amethyst, noStrudle, and GetFaaans/the new highlighter once it launches.

[staab]

Not to derail you guys, but I think this nip is way over-specified (no need to repeat everything in NIP 92, 94, 31, etc). It also doesn't handle the use case of different files for different use cases (e.g. streaming vs download). I had occasion to go over this because I want something similar for audio files and used this NIP as a starting point. I came up with #1043 which is much simpler and uses established conventions.

[v0l]

@staab you did derail this, your nip doesn't even cover videos. Im going to implement this NIP for zap.stream

[staab]

@v0l that was merely an invitation for others who are interested in video to improve this PR. I don't really have a dog in this race, but I do like tidy specs, so I drafted #1241 for your consideration.

[staab]

This exists in at least 3 clients now and has a pretty fair amount of use.

[fiatjaf]

What clients?

[zmeyer44]

What clients?

I believe Highlighter, Flare, Nostrudel, Amythest, and I think Kieran is adding support in zap.stream

[staab]

Zap stream has it now: #1241 (comment)