nip71: make video events regular

[fiatjaf]

This follows the example of NIP-68 and turns video events into regular event kinds, because

• interacting with video content that can change underneath you is dangerous.
• it's not common to edit videos anyway, and media source URL can be solved with blossom.
• edits must be done with overlay events, if necessary (unlike on kind:1, where edits are a threat to the protocol) -- this can be defined later in an addition to this NIP.
• addressable events are annoying and shouldn't really have ever been used for things that are expected to be loaded in a feed.

[vitorpamplona]

I am not against it, but this is a breaking change to many clients at this point, including flare.pub

I think this breaks a lot of things for minimum gains. There is no really compelling reason to do this.

[fiatjaf]

What clients do this? flare.pub is abandoned and broken already.

[fiatjaf]

Even if this breaks everything I believe the risk of commenting or liking the wrong thing is very worth doing. With articles that risk exists, but it's less likely because people who read and write are less likely to be scammers, but video is a big avenue for scamming. Also it's much easier to store old versions of articles and make it clear we're commenting on those and that's what we will have to do eventually.

But with videos, damn.

If this grows enough and become TikTok we are doomed.

Videos are way too small at this point, basically no one is even aware of the existence of these events, so I think it's still time to change. All past content published is mostly worthless anyway.

[pablof7z]

Perfect. I think this is great. I'm all for it and will switch Olas' videos to kind:21. It's not really a breaking change because we're using a different kind, so existing clients aren't broken.

[v0l]

I was just thinking of this yesterday!

zap.stream has videos/shorts will update it

[eskema]

do we really need 2 kinds for vertical / horizontal? what about square videos?

[vitorpamplona]

vertical / horizontal?

It's more about making the distinction between long form (youtube like) and short form (tiktok/instagram). Clients don't tend to manage both well at the same time and I think a user that wants to watch youtube is not looking for shorts and vice versa. Even Youtube struggles with this.

We could rename them to shorts and longs if that makes it better. We used vertical because "shorts", "stories", etc are basically "name brands" of certain companies.

[eskema]

We could rename them to shorts and longs if that makes it better. We used vertical because "shorts", "stories", etc are basically "name brands" of certain companies.

yes, I think it should be categorized more something like this. general videos (kind-21) and specific formats.
"short vertical stories" beeing one format using kind-22

[pablof7z]

perhaps we don't really need to make the distinction and just make the duration a MUST tag and let the app decide what "short" and "long" mean. Perhaps the dim should also be MUST and then the client can decide whether to filter by orientation.

[v0l]

perhaps we don't really need to make the distinction and just make the duration a MUST tag and let the app decide what "short" and "long" mean. Perhaps the dim should also be MUST and then the client can decide whether to filter by orientation.

I think we need both kinds, its a cheap way to filter at the relay if you're only looking for certain type of video, kinds are cheap and clients that want both and easily include both kinds and treat them the same

[fiatjaf]

"Horizontal" and "vertical" are indeed retarded as categories.

[vitorpamplona]

Though I have to say that when @pablof7z limited Olas's pictures to being squared, it created one of those "limitations" that are actually quite nice. So much that I even thought about making kind 20 square only (cropping those who are not). Meaning that instead of having to write dim to make sure clients can pre-layout before the image loads you would just force an entire style of pictures as a kind, getting rid of any dynamic calculation based on an unloaded image size.

It would be nice to keep shorts vertical since that's how most mobile apps will use them. Maybe there is a future where "shorts" can also exist on the desktop and thus a "horizontal shorts" start to exist. If that is the case, I would prefer having a separate kind for horizontal shorts because the experience will suck on mobile if horizontal and vertical are mixed. It basically forces users to rotate the phone or zoom to read horizontal videos.

[fiatjaf]

YouTube video screens have fixed size and they just add fillers on the sides when the video doesn't have the right dimensions, right?

I think this should be enough to nudge everybody into making videos of specific standard ratios, but also allowing for exceptions when that is unavoidable.

[vitorpamplona]

Sizes are less of an issue. The problem is different aspect ratios and how they impact the UI in the milliseconds of loading stuff. It's nice when things don't move around.

I don't know... I think I am becoming an "opinionated event kind" maxi.

[fiatjaf]

Yes, I get it. By size I meant aspect ratios.

[vitorpamplona]

Ok, new position on this:

1. Don't just change the numbers, mark the kinds as deprecated or just leave them there for historical reasons since flare is still up and producing new events. People need to know what they are.
2. Create new kinds that more precisely match what each of us is looking for on a "Video" kind. It could be in the same nip or as a new NIP.

I think there is an opportunity to do a "Shorts"-only client. And if that is the goal, then let's make the kind specifically designed for Shorts on mobile. Are we doing threaded replies on Shorts or just chats? If threads, how many levels do we want to do? What's the ideal size and length of the videos? Minimum and maximum aspect ratio as well as cropping expectations when things exceed. Are we showing the title and description or not? and where (top of the video, bottom, center, different screen, maybe just on notifications)?

Tracks and Segments for instance, only make sense in the long-form video kind and are very poorly defined as of now.

Shorts could also offer links to the base video/audio for people to edit and reply to with another video. Anything that can speed up a reply in video should be added.

Thumbnails & blurhashes should be a requirement for these kinds.