nips
nips copied to clipboard
nostr-protocol
NIP-71: `imeta`
I think it makes more sense to use imeta as it will allow for multiple variants of the video to be specified in the same event.
I have also added a new attribute to NIP-94 tags to flag an upload as NIP-96 for example which can be used to find the files even if all the links are dead.
Also dropped the video views, it makes no sense to me that you would want to update your view status just for more accuracy, imo we need a simple reaction like event which is a view that is non-replaceable
@staab @zmeyer44 @vitorpamplona
Example: naddr1qqjrqce3xvcnzep395un2etz956rgdp495unzepk94jxgdnyx5ex2et9vsunzq3qv0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnksxpqqqzzmkgxlsep
{
"id": "a9750dae8affb7100e0843ae8ae807a68b71f793ff818705168ea51615c7ab0f",
"pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed",
"created_at": 1716549817,
"kind": 34235,
"tags": [
[
"d",
"0c1311d1-95eb-4445-91d6-dd6d52eeed91"
],
[
"imeta",
"url https://void.cat/nostr/bb4f1d44d968f6828e4b43cd4eea19da9d49040123a9b0d823c1b121c7258130.mp4",
"m video/mp4",
"x a73a717dfbe4222e3772c062033621887f29c388267ab245ee75ee77795d9928",
"ox bb4f1d44d968f6828e4b43cd4eea19da9d49040123a9b0d823c1b121c7258130",
"dim 854x480",
"image https://i.nostr.build/O4qAO.webp"
],
[
"published_at",
"1716549817"
],
[
"title",
"Upscale test"
]
],
"content": "",
"sig": "adc0fe1c3b29b3a89698fe8f84bf4f3e9d15f99b58c55b408e37a98ef6e45e890fdb84a60691012972003726abb83cd02dce790257494d31baf3bfa8e02eaff1"
}
Maybe keep the tags in the main event as a "non transform" base? Then each imeta could point to different pre-cached sizes/formats.
About the NIP-94's service tag, what if instead of that, you add nip96u set to the uploader's pubkey? (the uploader's pubkey can be different than the nostr event author's pubkey, as @quentintaranpino points out at #1097)
It's presence would be enough to flag it as a NIP-96 upload. I imagine other alternative services could have their own tags if needed, even if not pointing to a pubkey, like ["aws", "1"]. Clients would know which tags to look cause they decide wich service types to support, after all.
ACK for the rest.
I mean instead of ["imeta", "service nip96"] it would be ["imeta", "nip96u <pubkey-of-the-user-who-uploaded-the-file>"].
It boths indicates which service type was used (if it has a nip96u tag, a nip96 server was used) and also helps finding fallback servers, if looking at the uploader's nip96 server list
I mean instead of
["imeta", "service nip96"]it would be["imeta", "nip96u <pubkey-of-the-user-who-uploaded-the-file>"].It boths indicates which service type was used (if it has a nip96u tag, a nip96 server was used) and also helps finding fallback servers, if looking at the uploader's nip96 server list
Ok but for brevity can we also have service nip96 and the pubkey is the author of the event? What use case do you think you would want to post images from a different pubkey?
What use case do you think you would want to post images from a different pubkey?
example 1) If I copy/paste this https://link.to/image.png#ox=<hash>&nip96u=<pubkey> from someone else's kind:1 to my own kind:1, when nostr client fails to load the image from https://link.to/image.png, it can fallback to the nip96u guy's server list. If it was to look into my server list, the file may not be there cause I haven't uploaded the file myself.
example 2) One could make file indexes of ox hashes and one or more nip96u pubkeys, without static urls (without https://link.to/image.png). Checking the nip96u user's server list in search for the ox hash would be enough to find the file.
example 3) I can copy someone else's meme to my list of memes, without reuploading. Adding the nip96u tag would enable nostr clients fallbacking to the nip96u user's server list in case they move the file to other server.
Though it is merely a suggestion.
@arthurfranca ok, but i dont think you should be encouraged to copy paste somebody else upload because if they delete the image then its also broken on your note.
NIP-96 supports multiple people uploading the same image so if you wanted to share somebody else image you should also upload it so that its linked to your pubkey, in this case your own nip96 server list should contain the image
@vitorpamplona @zmeyer44 are you going to update your clients to support this format? Its already supported on https://zap.stream/videos
Also what other clients support this spec?
Yes, but I'd like to keep the unmodified original video (with original size/quality/hash) included as well. I thought it could just be using the regular tags as before and the imeta tags provide transformations. Either way, knowing which imeta is the real file is key for decentralization/reprocessing.
We also need subtitles, alts, sections definitions, floating cards, and other video-related metadata that should apply to all transforms.
We also need subtitles, alts, sections definitions, floating cards, and other video-related metadata that should apply to all transforms.
We have subtitle tracks, alts, chapters, missing the floating cards though
@zmeyer44 @vitorpamplona @pablof7z
Coming back to this after a while, i believe highlighter does videos too
Would also be good to start using https://github.com/nostr-protocol/nips/pull/1233