The point is that NIP-94 wasn't meant to be for embedded images in kind:1 notes. If someone really wants to reference a kind:1063 they should be able to, paste a nevent code and that's fine, but they shouldn't expect other social clients to be able to understand these events, so it makes no sense to make that the default way of loading images.
The best way to ensure that the protocol is kept simple is to not assume other clients will implement whatever NIP you think it's cool -- you can implement anything you want, but you should still make it so the experience works for others that don't.
Replies (5)
Just a Nostr pleb here but isn't that setting completely subjective standards and therefore adding politics into it?
How can we have clients competing for the best experience and most features, within the rules of the NIPs, while at the same time asking for all-vs-all compatibility?
I think a core issue is that kind1 is getting overloaded with specs. Two mention specs, quote repost. We should probably stop adding shit or kind1 posts are going to be impossible to implement in new clients.
This is why I like the longform kind, still text but we can have markdown, inline images, etc without having to overload kind1 with more interpretation and parsing.
Well said
Do nostr clients currently fetch the mime-type for each url that is inside a kind:1 note from a remote server? Or is this information embedded meaning there is no need to send a request to a remote HTTP server somewhere?
Other than privacy issues, isn't this bad for UX since there is always few seconds that images are shown as links before the UI would reflow. Is there a way to implement loading placeholder or blurhash with just kind:1 notes?
If users can't all connect on the very basics of social media like text & images, it seems to me this presents a potential hurdle of unintended censorship.
