Add imeta tag#904
Conversation
|
snort is pushing some |
|
Nostur is already reading imeta tags, and I am now in the process of adding them to new posts. I don't have strong opinion against changing the spec but changing it now would mean I would have to support 2 versions because there are already many imeta posts out there. |
|
I think there is no way to change this. Let's merge it. |
|
I continue my position that static content should never be referenced with URLs inside Nostr due to:
The dynamic nature of the content resolution makes it impossible for a Nostr or Web crawler to correctly weigh the content of such URLs since the crawler cannot verify if the image host has changed the contents without the author's consent or not, making Nostr search way more difficult to correctly index. But I won't block adding this to the repo if people are using it. 2+ clients rule always win. I just think it is a huge mistake to keep building on top of a structure that doesn't align with Nostr's goals. |
|
I don't get why not use NIP-54. For fallback urls it would be like this: It is like query params but using |
|
On Tue, Nov 28, 2023 at 05:08:57AM -0800, Vitor Pamplona wrote:
I continue my position that static content should never be referenced with URLs inside Nostr due to:
1. the centralizing nature of domain name registrars,
2. the full state control of the DNS resolution stack,
3. the centralizing nature of the domain name resolution to a single provider
4. the immutability break of today's extremely frequent editing of such images by the image host without the author's approval or review
5. the potential for rug-pulling a massive amount of users at once by a hostile takeover of an image host provider to replace the image and video files for profit (ads, porn, SEO-hacking, etc) or criminal activities (scams, impersonation, etc).
The dynamic nature of the content resolution makes it impossible for a Nostr or Web crawler to correctly weigh the content of such URLs since the crawler cannot verify if the image host has changed the contents without the author's consent or not, making Nostr search way more difficult to correctly index.
But I won't block adding this to the repo if people are using it. 2+ clients rule always win.
I just think it is a huge mistake.
Your tirade against URLs is bizarre. URLs are here to stay unless there
are some fundamental changes to the internet itself. nostr is an
internet protocol, it will naturally interact with other aspects of the
internet and the web.
|
|
On Mon, Nov 27, 2023 at 02:50:53PM -0800, hodlbod wrote:
It would also be nice to use a query string or json or something instead of space delimited data.
I maintain that splitting on the first space is way simpler than query
string or json encoding. This scheme allows a variable number of
arguments without fixed positioning downsizes, and allows us to not
duplicate the url string into many tags.
|
|
On Tue, Nov 28, 2023 at 06:26:24AM -0800, arthurfranca wrote:
I don't get why not use
[NIP-54](#521). NIP-54
reuses and supports all NIP-94 tag names and works both inline (in
`.content`) or inside a tag.
For fallback urls it would be like this:
`https://abc.com/img.jpg#url=<fallback-url-1>&url=<fallback-url-2>` and
it would work inside `.content` for both `kind:1` and `kind:30023`
markdown.
It is like query params but using `#` instead of `?` so that the params don't get sent to the server (in the example an `<a>` html tag with the src as `https://abc.com/img.jpg#url=<fallback-url-1>&url=<fallback-url-2>` would request just `https://abc.com/img.jpg` and could use `onerror` handler to swap src to the fallback url)
I would use this for DMs, but imeta for public stuff allows you to
quickly pull out the blurhash before parsing the contents. Pulling out
the blurhash as quick as possible so that you can generate an image is
pretty important if you want to load posts as quickly as possible
without image popping and before the image has been downloaded.
|
|
I don't strong opinion, but is better to be two elements tags? since this can pass empty value like |
|
Well, Sorry. I can't explain it well immediately, I mean it should be a nested structure. |
|
There really needs to be a way to represent media attachments that are not part of the text content. This is very common on platforms such as Twitter, Facebook, Instagram, email, Mastodon, and practically every other social platform users are accustomed to that isn't Medium, and it fills me with existential dread that we cannot do it on Nostr. |
|
On Tue, Nov 28, 2023 at 08:46:05AM -0800, mattn wrote:
I don't strong opinion, but is better to be two elements tags? since
this can pass empty value like `["alt": ""]`
If you want an empty value you just don't include the tag element? If
there was more than one image what would you do? The point of imeta is
to group metadata for each image. The querystring thing is another
approach but this modifies the contents and makes the urls huge.
…```
{
"content": "More image metadata tests don’t mind me https://nostr.build/i/my-image.jpg",
"kind": 1,
"tags": [
[
"imeta",
"url https://nostr.build/i/my-image.jpg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt A scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",
"fallback https://nostrcheck.me/alt1.jpg"
"fallback https://void.cat/alt1.jpg"
]
]
}
|
|
I really like this idea. |
|
On Tue, Nov 28, 2023 at 08:53:19AM -0800, Alex Gleason wrote:
There really needs to be a way to represent media attachments that are
not part of the text content. This is very common on platforms such as
Twitter, Facebook, Instagram, email, Mastodon, and practically every
other social platform users are accustomed to that isn't Medium, and it
fills me with existential dread that we cannot do it on Nostr.
What does this gain you over urls and metadata?
|
They can stay. I just find it dumb to have a decentralized protocol based on a centralized and even state-controlled infrastructure. But people never pay attention to these things until they get rug pulled. I was rug-pulled once over DNS when doing signed payloads between two countries at war with one another. I learned my lesson. |
|
I think there are room for both approaches but not everyone is going to have the same threat model. |
People always say that until somebody buys nostr.build out and start advertising fake Damus coins in the images of your own signed posts for everyone but your own location. People will be scammed by your own posts and you won't even see until it's too late. That's the threat we should fix as soon as possible. |
By replacing URLs with inline attachments in posts (which most clients do), we have inadvertently created an undocumented custom data format for Nostr similar to Markdown or HTML. I just want to add |
|
On Tue, Nov 28, 2023 at 09:26:11AM -0800, Vitor Pamplona wrote:
> I think there are room for both approaches but not everyone is going to have the same threat model.
People always say that until somebody buys nostr.build out and start
advertising fake Damus coins in the images of your own signed posts for
everyone but your own location. People will be scammed by your own
posts and you won't even see until it's too late.
That's the threat we should fix as soon as possible.
Then I would just add sha256 to imeta? I would download the image after
upload and then hash it before posting.
|
Not just add but verify as well. Then that does solve one of the issues there. Then you have the rest:
So many things can happen after the post is signed... all because people insist on specifying a host at the signing time. |
|
For me the image dimensions and hash are the most important, this solves jumpy image loading and content rug replacement. Where this info is seems less relevant as long as its somewhere in the event, NIP-54 and imeta seems to solve it good enough, not sure why one would be better than the other, but imeta is already in use. I don't think DMs is a good enough reason to use NIP-54, because DMs shouldn't leak any tags at all, this needs to be fixed on the DM level so you can add any tag probably in a way similar to NIP-51 lists. Otherwise for every spec that requires tags you need to find a special way to use it in DMs also. |
|
On Tue, Nov 28, 2023 at 09:26:54AM -0800, Alex Gleason wrote:
> What does this gain you over urls and metadata?
By replacing URLs with inline attachments in posts (which most clients
do), we have inadvertently created an undocumented custom data format
for Nostr similar to Markdown or HTML.
Maybe we could spec it? It seems universal at this point.
|
Agree, DMs should never, ever have any public tag but the receiver's pubkey. And static content (pictures, videos, pdfs, etc) transferred through DMs must always be encrypted to the receiver in the same way the content of the event is. We tested that expectation a few months back with our users. Neither a hidden but public link nor an image encrypted with a shareable secret is enough. People expect significant privacy on DM attachments. |
|
On Tue, Nov 28, 2023 at 09:37:34AM -0800, Vitor Pamplona wrote:
> Then I would just add sha256 to imeta? I would download the image
> after upload and then hash it before posting.
Not just add but verify as well. Then that does solve one of the issues there.
Then you have the rest:
- User tracking by the image host.
Somewhat ironic, don't you track every view on every post on your app
using images? VPN or image proxies solve this. Image proxies could
modify the image, so you would need to fallback to the original link and
check the source if the hash check failed, an action the user could do
manually if they were paranoid enough.
- Posts might be broken when such a host disappears.
This is what the fallback url is for
- Image hosts might fully censor your past or just decrease the
bandwidth/increase the latency for disliked persons.
Based on what, their IP? Use a VPN.
- Image hosts might request payment from downloaders before sending the
image/video.
That's a different spec.
|
|
On Tue, Nov 28, 2023 at 09:39:29AM -0800, Fabian wrote:
I don't think DMs is a good enough reason to use NIP-54, because DMs
shouldn't leak any tags at all.
I was only referring to the querystring mechanism for metadata, which
wouldn't leak anything.
|
|
Ok, I can't think of any real problems with that. |
I have exactly the same problem. Not only images, but I can't control how other media in my note is displayed, or even how all |
|
Can you please decide on this versus the inline metadata? Otherwise we will end up everybody having to implement both in the long run. |
Probably too late for that, but Coracle reads both and only publishes imeta. |
|
As a "requested-changes" person on this MR, I've conceded the point about not having URLs in the text. It's work-around-able. We do need some kind of media tag, though. I wish it were just called It would support images, videos, and any other type of file. The We get the feeling that things are set in stone and we can't change them. But Nostr is really still in its early stages. We absolutely can afford to change, and we'll be glad we did 5 years from now. So I would strongly suggest naming the tag |
|
Nostur also reads both but only publishes imeta. |
|
Damus only reads and publishes imeta
|
|
Snort also apparently reads and publishes Looks like should merge this. I think we should merge @alexgleason's code suggestions before. |
|
@fiatjaf I thought the consensus was that appending urls to the end of text notes was the best way to handle this to avoid weird UI problems in clients that don't support attachments. |
|
When there is an |
|
ignore the tag |
staab
force-pushed
the
imeta
branch
2 times, most recently
from
ae3a0ba to
3cfc981
Compare
Yes, I definitely think that should be how it works. Isn't that what this NIP describes? |
staab
force-pushed
the
imeta
branch
2 times, most recently
from
7c1aaed to
fc26ed4
Compare
Yes, Alex just had an outstanding suggestion that changed that. Resolved now. I've rebased and fixed a couple formatting things, merging now. |
|
You have merged your own PR! |
|
I kept waiting for you to do it and you kept telling some indeterminate person to do it |
|
Outrageous! (I'm kidding) |
Add imeta tag
Add imeta tag
12 participants
This is adapted from Damus' DIPS repo: https://github.com/damus-io/dips/blob/master/01.md. I don't love the format, but I think there are probably a good number of events in the wild already using it. This PR is backwards-compatible except for renaming sha256 to x following NIP 94.
@jb55 correct me if I'm wrong and there is an opportunity to revisit the format. My preference would be to make the
urlthe first argument of the tag rather than the value of theurlkey to make it more conventional. It would also be nice to use a query string or json or something instead of space delimited data.