NIP-30 Resources

[plantimals]

nip-30

Looking for feedback.

I believe adding a resource kind will unlock a lot of immediately useful interactions in nostr, from being able to filter events based on their media content (find all images, links, audio, etc from a particular pubkey), to directly mapping podcasts and similar content to nostr events. I elaborate on the favorable dynamics in the NIP. An important aspect is that the URL and type fields are in the tags so they can be filtered on without updating existing filter params.

I can also imagine the resource tag being added to kind 1, which would fit the form of kind 9 perfectly. I went with a new kind in this draft because it seems the least disruptive. perhaps if the kind 9 is approved and found to be productive it could eventually be merged into kind 1.

The name resource seems best, but I can imagine it also being called an attachment, URL, link, enclosure, etc.

[Giszmo]

I don't see what's the benefit of this nip. We already embed images, link to videos or audio, ... what is the use case actually? Are you developing an app that actually needs this feature?

[eskema]

I like this and think it makes sense to have in nostr. A dedicated kind for resources is a good thing. not sure about the tag name resource though, I think it should be a single character for indexability. how different is it from the r tag? couldn't that be unified? should it be limited to a single resource? couldn't it be a collection of resources by using more than one resource tag (think gallery, reference list from article etc)? adding additional p tags should also be useful to credit other authors for that resource.

[plantimals]

I don't see what's the benefit of this nip. We already embed images, link to videos or audio, ... what is the use case actually? Are you developing an app that actually needs this feature?

@Giszmo thanks for the feedback. The point of this feature is to allow the creator to make specific resources semantically available to consumers. I have so much more work to do, but the use case I am working on now is import/export of RSS feeds to nostr, including podcasts. I'm running into a lot of ancillary issues around publishing these, but the idea can be seen here: https://nostr.io/podcasts , with this being a specific instance of an event with the resource tag: https://nostr.io/e/497ab84e67f754fdf1ba85d8b8ff91362416f1f160cd509392b91f292a10e062 It's possible to parse the message text for links with specific file suffixes, but I think in the long run we would all benefit from being able to tag resources specifically and give their media type. for example, nostr.io sees the tag and wraps it with the browser native audio controls. the same thing could be done for video, PDF, or whatever makes sense. one way it would help with respect to displaying images, not every nostr client does markdown parsing. so some will see ! [ image here ] ( http : / / blah blah . com / image . jpg ) displayed and others will see the formatting. one could also include that image as a resource, which I think is much more reasonable as an ask for client implementors, and would allow modes of display other than plain in-line html.

[plantimals]

I like this and think it makes sense to have in nostr. A dedicated kind for resources is a good thing. not sure about the tag name resource though, I think it should be a single character for indexability. how different is it from the r tag? couldn't that be unified? should it be limited to a single resource? couldn't it be a collection of resources by using more than one resource tag (think gallery, reference list from article etc)? adding additional p tags should also be useful to credit other authors for that resource.

@eskema I think it should be a generic tag, and r would be ideal, but I'm not sure how people are using it right now. I see it described as a "reference" tag, but I'm not sure about the semantics. it may make sense to roll the functionality of the reference tag into the resource tag. I agree about multiple resource tags, I can imagine many uses and no obvious drawbacks.

[0xtrr]

Should the mediatype tag string follow some RFC such as RFC 6838?

And should it still be it's own kind or should it be merged to kind 1?

[AsaiToshiya]

This NIP looks the same as NIP-94 to me.

[staab]

This stuff still needs to be standardized somehow, but I'm going to close this due to inactivity, nip 94/96 seem more promising.