NIP-54 - Inline Resource Metadata #521
Conversation
|
Sorry, why are we moving the description to alt on NIP-94? Do we need 2 descriptors? |
|
@vitorpamplona It's because alt is basically for blind people, so it should be a correct description. While the other one (NIP-94 event content) could be a loose description, like a funny caption that not really describes the picture, just like html image titles. edit: content is also a description (just like alt is), but I called it "caption" to try to differentiate it from alt tag edit2:
|
|
We used the |
It is exactly that. I imagined a photo gallery of NIP-94 kind 1063 events. On one of the photos, the Now if you want this on regular social feed, the 1063 event would be referenced on a kind 1 note. |
|
So, the stories in Amethyst are exactly that. But without any additional descriptors. Users can only add the accessibility descriptor. I understand that it makes things easier to not have another kind, but I am not sure if it's the right approach. We have to keep in mind that NIP-94 and NIP-95 are generalized file references and not posts. I believe another type is required to host them correctly if your goal is to make another non-kind1 feed. Otherwise, you will start seeing 1063s that were included in replies in a Kind 1 on your image feed, disconnected from the Kind 1 context they were designed for. Or files that were added to a GitHub on Nostr project, or boring marketplace product pictures. If your feed is based on Kind 1063 alone (like ours is, for now) you will see a bunch of images and posts out of context. And keep in mind, 1063 is for any file. Not only for images or videos. |
Yes, but just put a |
|
I consider caption part of metadata but I'm ok reverting the NIP-94 change. I will just wait if someone has anything to add. |
|
It doesn't make much sense to have this NIP given that the Damus way already exists and is being used in practice. We should all use that. Yes, that's not the best way to write a spec ("just follow whatever Damus is doing") but that is probably the best way to make an existing protocol interoperable. |
arthurfranca
force-pushed
the
inline-resource-metadata
branch
from
120b793 to
c06cba6
Compare
|
@vitorpamplona I reverted the change on @Giszmo is author of the # fragment idea.
@fiatjaf, the quote is from here by @jb55. After re-reading the discussion, it seems both approaches are useful and "should" be used together. I highlighted the reason and differences here. The NIP also features a complete event example. |
|
I don't see why we should have two approaches, that goes against all reason. |
|
This is because imeta tag alone lacks some features. Different from imeta tag, inlining with # fragment makes it possible to:
imeta tag is better for:
|
|
Concept ACK. Skimmed it and looks good. Need some time to do a full review. |
|
LGTM |
arthurfranca
force-pushed
the
inline-resource-metadata
branch
from
eb02eda to
136ae8f
Compare
|
Just rebased, no changes |
|
What if we do: Instead of: Positive:
Negative:
|
arthurfranca
force-pushed
the
inline-resource-metadata
branch
from
136ae8f to
eb2b1b7
Compare
|
IMO using URL fragments is not a good solution. See #751 which uses a JSON string. |
|
Replaced A kind 30023 event JSON file (with A PDF file without extension with added MIME type information: |
|
@alexgleason your solution 1) force tag usage that may not be suitable to current DMs/encrypted events (metadata leakage). 2) make copy/pasting urls lose metadata 3) force kind 1/30023 clients showing events to not only parse ⚔️ The clash of the url metadata PRs |
|
Most clients don't display inline media anyway, they pull it down to the bottom. Enumerating tags instead is an easier solution to what they're already doing. Leaking metadata in DMs is already an issue, and it's why giftwrap is being proposed. The tags would be hidden with giftwrap. |
|
Most clients, not all of them |
|
@alexgleason This note on Amethyst gets the image inlined at the intended position: https://nostr.com/nevent1qqsdnu95d6lxct2k6nx5nprauwhauchad544sctdjmrtfv33y334lfgpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzq3huhccxt6h34eupz3jeynjgjgek8lel2f4adaea0svyk94a3njdqvzqqqqqqyvseq6w edit: In fact, of all the clients listed at nostr.com, 5 were inlined at correct line (not at bottom). 1 turned the URL into a link. 1 didn't find it and the other 2 didn't load. Of the mobile clients I know, Amethyst inlines it while Damus and plebstr put it at the bottom. |
|
Amethyst does everything under the sun currently possible on Nostr. It is most prepared to deal with things both ways, while the majority of clients just want to stick media at the bottom. |
would have to strip the # if metadata is detected I guess |
Nothing personal. I go with what's best at the time. If somebody creates a better one, I am happy to migrate. |
|
BTW, For completeness, I also implemented shoving the entire NIP-94 event in a tag as a serialized json for each URL and then using a It's ok. But it ended up still URL-based (it just transferred the limitations of dealing with a URL to the NIP-94 event). And since this PR allows the use of any nip-94 tag in the fragment, this version is just shorter. |
function renderLink(href: string): string {
const url = new URL(href);
const search = new URLSearchParams(url.search);
if (isMediaParams(search)) {
url.hash = '';
}
return `<a href="${url.href}">${url.href}</a>`;
}
function isMediaParams(search: URLSearchParams): boolean {
// how am I supposed to detect this?
return search.has('m'); // ?
} |
|
You can't remove the hash unconditionally, otherwise people can't post links like: |
|
You should remove it just for display purposes, not from the actual link. I get rid of everything and just keep the host and some of the path. |
|
I don't think it's a good solution to hide the hash from URLs. |
You mean the file at the end of the path? For instance, for
I remove the For long hashes, like:
I add a
Assuming of course that I can't preview it for some reason. |
|
Hashes also seems to break imgproxy. Still NACK on this, imeta is better. |
Any examples of the issue? If it is breaking in these simple cases, we better fix it before the real content servers come in. |
|
Oh, nevermind, the bug was my own |
|
Snort is using the |
|
some of the links seem to have evaded my url parser, leading to broken images in a few cases 😢 |
|
Most image parser will expecting |
|
I think this was a good try but the big URLs create a big burden on everybody and we should stop. I guess it's correct to say that the URL parsers and regexes should have been ready for this, but in practice in the real world no one ever does such big URLs with # and * and { and whatnot, and when they do it's not a big deal if they fail to get recognized, but now it's thousands of notes with them and their authors don't even know they're publishing such giant monsters. |
|
There are even posts that put |
|
boy, do we need to sacrifice (end) user experience for a feature? |
This is the dumbest way to check what the content type of a URL is. There are no file extensions in URIs. Some things look like them that show up in URIs, but that's only because some servers map URIs to files internally. They are meaningless for anything outside those servers. The only way to reliably establish if a resource identified by a particular URI is an image or not is to make a HEAD or GET request and look at the Content-Type response header. Take the famous site 500px, for instance. None of their photo URLs end with an extension. https://drscdn.500px.org/photo/79694843/m%3D2048_k%3D1_a%3D1/v2?v=0&sig=5cd241cf922efd12d8aa1dac2722e261b006648cd0b7e3902bb6f4360e17d450 If you are relying on extensions, you are offering a terrible user experience already. |
The thing is that most nostr clients did it this way for quickly recognizing the URL as an attachment. |
Sure. They can keep doing it. Just remove everything after |
We should standardize and enforce that extensions are required for media content. |
Why? We have NIP-94, Keep in mind that clients can't add extensions on links that don't already offer them. There is not much we can do. If we want to truly fix this, we should not use URLs at all. Everything else is just a half-ass hack. |
I agree, but Nostr itself is a half-ass hack. The URL system is very broken and I wanted to fix it too, but is it worth fixing? We have tradeoffs here at hand. If we can get a system that works it will be better than one that is perfect but doesn't work because it's too complex, has too much indirection, slowness.
But yeah, maybe let's not try to force-standardize this for now, since it wouldn't work. But I still think people should try to put extensions in URLs whenever they can, as a kind gesture to the dumber clients that rely on that flawed hackish property of URLs. |
Yes. The decentralization benefits alone are a huge win. And clients get a better set of preview tags to optimize their UX before the content is loaded. It's a win-win situation. This feels very similar to the NIP-04 discussion. Everybody knew it was wrong but complacency and laziness kept us stuck in that model for far too long. Sometimes the easiest design and the simplest design are vastly different from one another. This is one of those cases. We can keep piling into an easy design the URL overlords want us to use or design our own content naming and resolution scheme to make it 10x better (more aligned with Nostr needs). In the end, our design will be simpler to implement than trying to make URLs work in 100% of the cases. |
You telling me kind:1 client devs that are already dealing with decentralized relay quirks and other harder NIPs are incapable of updating an url regexp to a valid one? =o If |
|
On Wed, Dec 27, 2023 at 09:39:42AM -0800, arthurfranca wrote:
You telling me kind:1 client devs that are already dealing with
decentralized relay quirks and other harder NIPs are incapable of
updating an url regexp to a valid one? =o
This is the code in damus:
func classify_url(_ url: URL) -> UrlType {
let str = url.lastPathComponent.lowercased()
if str.hasSuffix(".png") || str.hasSuffix(".jpg") || str.hasSuffix(".jpeg") || str.hasSuffix(".gif") || str.hasSuffix(".webp") {
return .media(.image(url))
}
if str.hasSuffix(".mp4") || str.hasSuffix(".mov") || str.hasSuffix(".m3u8") {
return .media(.video(url))
}
return .link(url)
}
What are we arguing about exactly? what is wrong with using extensions?
It works perfectly fine and is simple for devs to implement.
|
|
It works alright no need to change. Clients will only fail to load an image/video if the parser use some poor regex not accounting for valid urls (that may include
Probably just media with no extension. Nothing related to this NIP. On NIP-96 i have added the advice to append the media extension to urls so that nip54 or imeta isnt required to detect mime type. Nip54 is totally optional and beautifying long urls or not when no media is detected is a dev choice. |
It extracts the best from the previous discussion.
One additional upside is that when the regular user right clicks an image and copies then pastes the url on a new note, it preserves all added metadata. Also, it can be appended to any url like this NIP-21 one:
nostr:nevent1qq...epm#a-metadata-name=a-metadata-value