i said this before, but gonna say again.
so on nostr people usually post stuff right?
use it as social media.
but we know we can use nostr to share other things as well.
for example videos, images, shorts. etc.
so for these nostr has kind 20, 21, and 22.
but if you post these kinds, many clients will not show them to you followers on their feed. because its not a social media post.
also for example if you wanna post a normal content with a video, you have to publish video event separately under kind 21, and then quote them on your posts.
kind 21 has some advantages over just sharing a video link, such as it lets you enter the aspect ratio of the video, add a cover image, and caption.
same thing applies to images.
knowing the aspect ratio of an image or video before it loads lets you prevents layout shifts without having a locked embed size for the image and the video. even knowing the type of content helps. without secondary requests.
yes having different kinds for videos, shorts and pictures, has some advantages like, it lets you filter them from regular content easily.
BUT my idea of nostr was always, on the social media clients you should see EVERYTHING, on the feed. You post a video? It should appear to your followers without you also posting as post separately. You publish a new song? It should also appear on the feed. You publish an app on ZapStore? this should also appear on your feed without you posting its event id separately. and on specialized apps you just see specialized things filtered.
so in this spirit, i always liked formats inside the kind 1 notes directly. for example normally you share media using content links in kind 1, right? so if we need more information why not try to encode it inside the url directly?
for example hash ( # ) part of the url is useless with contents. so we can use it to store information about the content, right?
so for example kind 20 pictures. have some data fields like "title", "location", "m(Media type)", "dim(Dimensions)", and more... we can just include these directly in the hash part of the URL using URL Query format on the hash part.
so:
- we dont need to create a separate event
- we are using already existing standards for the metadata.
- and data is just directly inlined in the note requires no additional requests.
- and its a progressive update, if the client doesnt support it, it still shows the content, but if the client does support it, good client now has more information.
this can be used for videos as well. same thing.