NIP-34: Media Attachments

[alexgleason]

There is no good obvious way to add media attachments to events on Nostr.

Parsing media data from inline URLs is unacceptable, and the other proposed solutions (like adding query parameters to URLs) are also hacks. NIP-94 is not acceptable either because every attachment has to be a separate event. We need the ability to easily add media to a single event.

Nostr should just support media tags:

["media", "<url>", "<optional data>"]

Read NIP here: https://github.com/alexgleason/nips/blob/9f545ee94974cbd8ffec411196a90175e30f8a5a/34.md

[vitorpamplona]

Is this just an idea or has it been implemented somewhere?

[alexgleason]

@vitorpamplona Not yet. I have been thinking about it for months.

I didn't do it yet because I don't want to make people mad. But I strongly believe it's the right solution. I'm going to postpone a bit longer to see what other people say, then I will likely proceed with it.

[vitorpamplona]

I am ok with it.

[Egge21M]

ACK. In-line media makes sense if you want to give users the chance to choose where media is displayed (similar to markdown), but afaik most clients don't allow that anyways and will attach the image to the end of the note.

If positioning is irrelevant, than having the url in-line makes absolutely no sense to me and just adds complexity on the client side.

Edit: however transitioning to this is not easy, as it will break images for clients that do not upgrade.

[vitorpamplona]

Edit: However transitioning to this is not easy, as it will break images for clients that do not upgrade.

I am expecting the URL to also be placed in the post as well. So, it should work. Unless the idea is to not write any URL in the content at all. But that seems weird.

[arthurfranca]

Parsing media data from inline URLs is unacceptable, and the other proposed solutions (like adding query parameters to URLs) are also hacks.

Kind 1 and 30023 settled on inline media, including regular links and nip21 (nostr:...) links. 30023 can't even change because it uses markdown.

Please check this proposal comment out - using r tags instead with NIP-54. It is not exactly "query parameters" as you said. It is URI fragments with query parameters syntax. Similar, but it has the important difference of not getting sent to server, so don't have the possibility to mess with media fetching.

Though for kind 1/30023, media inside tags should only be used in addition to inline urls to aid in preparing the media placeholder faster, so may not need all available metadata fields.

[alexgleason]

Media URLs in content is a hack. Most clients add the URLs to the bottom of the post, and then do a crazy find-replace/regex to hide the URLs before displaying the post. Why? Why are we doing all this work instead of using tags for what they were designed for?

For kind 30023 events, inline media makes sense. For kind 1, it makes everything harder. I would also argue that it's not "settled on" since it's not covered by the NIPs repo at all, and people have just been doing hacks to try to work around it.

However, I think we can support both. If a media tag matches a URL in the content, you can put it inline, and if it doesn't, you can render it at the bottom of the note.

NIP-54 is alright. Using space-separated values is not ideal when we could just JSON.parse the whole thing and be done with it, like this NIP recommends. I don't see any benefit of splitting it out into separate tag values when it's so hard to parse anyway.

I think using URL query parameters is wrong, because it the media will be fetched with those parameters and it could impact the result from the server. There's no reason to change the URL. Just include a JSON object of metadata.

[arthurfranca]

I think using URL query parameters is wrong, [...] it could impact the result from the server.

You did not read my above comment about NIP-54 fully ---> "It is not exactly query parameters as you said. It is URI fragments with query parameters syntax. Similar, but it has the important difference of not getting sent to server, so don't have the possibility to mess with media fetching."

Media URLs in content is a hack. Most clients add the URLs to the bottom of the post, and then do a crazy find-replace/regex to hide the URLs before displaying the post.

I see what you say as a behavior of some twitter-like clients or as the presentation on the feed view only. Nostr kind 1 events can be very long compared to regular tweets, so inline media starts making sense.

[Egge21M]

I see what you say as a behavior of some twitter-like clients or as the presentation on the feed view only. Nostr kind 1 events can be very long compared to regular tweets, so inline media starts making sense.

In theory yes. But what we see kind 1 being used for today is short text content with image attachments. Most clients don't even let you choose the position but will simply append the URL.

For everything where media needs to be carefully positioned we got NIP-23 anywhere. By separating these use cases in separate nips clients can provide way better UI/UX around them both.

[arthurfranca]

By separating these use cases in separate nips clients can provide way better UI/UX around them both.

Imo you guys aren't noticing some details regarding kind 1 specifically.

Most non-nostr clients have taught millions of users over the years to do @name, #tag and paste all sorts of urls directly on .content. Leveraging this for me makes it a superior UX because users are already used to doing it.

Clients will already have to parse .content looking for these mentions and other links. That's why for kind 1 things are inline.
That's partially why NIP-08 was deprecated in favor of NIP-27.

You can try to change it in your client but people will continue pasting things inside .content, forcing you to parse it.

[Egge21M]

Most non-nostr clients have teached millions of users over the years to do @name, #tag and paste all sorts of urls directly on .content. Leveraging this for me makes it a superior UX because users are already used to doing it.

You are mixing things up. These clients have not taught people to in-line media. It's very unusual.

Clients will already have to parse .content looking for these mentions and other links. That's why for kind 1 things are inline.

Of course. This NIP focusses on media alone. I am a huge fan of in-line mentions and parsing and replacing them is easier. But they do not change the way a post might be displayed, while a media attachment might change the intend of the post completely. It makes no sense to have them in-line, because that might make a user think they could control the position of the media (which most clients won't let them do anyways). IMHO there is not a single good reason to keep inlining media

[arthurfranca]

My point was that 1) you will already have to parse content; 2) positional media in kind 1 content does is a thing

You disagree with point number 2. Agree to disagree and of course everyone is free to put media inside content or inside tags as there is no nostr CEO.

With that aside, imo this NIP-34 is useful for other event kinds but I propose using NIP-54 https://...#meta=data&meta2=data2 inside r tags instead (notice the # instead of ?). Because it could be used both for in-line and in-tag url/media metadata, different from NIP-34.

[alexgleason]

You can still use media tags for inline media. You would just match the tag with the inline URL.

[arthurfranca]

You can still use media tags for inline media. You would just match the tag with the inline URL.

But then clients that are already only parsing .content would be forced to look at two places (.content and tags).

[AsaiToshiya]

@alexgleason This looks the same as NIP-92 to me. Could we close this PR? Or is there more to discuss?

[alexgleason]

Yes, now that #904 is merged this is no longer needed.