search

nostr-protocol / nips

Nostr Implementation Possibilities
2.19k stars 519 forks source link

Embedding decentralized media #131

Open grantwest opened 1 year ago

grantwest commented 1 year ago

Relays can't be expected to host media, the infrastructure requirements would be immense. URLs break and many image/video hosts do annoying things that prevent simple unobtrusive viewing of media. Use of decentralized URN to embed media in messages should be normalized.

Example URN:

urn:ipfs:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

There is an open issue on the IPFS repo to register this URN with IANA, not that being registered really matters and nostr could adopt either way.

It would be up to the individual nostr implementations/clients to decide how to implement. They could embed an IPFS client or just issue http requests to public gateways. So this is not truly part of the nostr protocol, rather just a suggestion to clients.

fiatjaf commented 1 year ago

We can definitely standardize this, but I think it would be nice to see it implemented and used with success first because I am not sure people will prefer this over https://gateway.cloudflare.com/ipfs links (or whatever is the best gateway these days).

grantwest commented 1 year ago

A client could convert URNs to cloudflare gateway links on the fly. The signed nostr message should use the URN because it is permanent. How the client wants to access the referenced file and how it wants to present the link to the user is client preference.

I think it is important to establish a truly decentralized media strategy early on. The nice thing about using this URN scheme is that clients don't HAVE to implement a full blown IPFS implementation, they can just make use of a number of different reliable public gateways for now. It provides the option of quick centralized implementation, but also the option of fully decentralized media retrieval.

fiatjaf commented 1 year ago

I agree. What is the format of that URN?

grantwest commented 1 year ago 
urn:ipfs:<IPFS CID>

More info on IPFS CID: https://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid TLDR: CID or Contend Identifier is a hash of the file. Although it's a bit more sophisticated then that to allow chunking and stuff.

Example:

urn:ipfs:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Which can be accessed using the cloudflare gateway for example with this link: https://cloudflare-ipfs.com/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

burdiyan commented 1 year ago

I think it would be better to standardize on URLs instead of URNs, as it's equally flexible and probably more portable. Also, IPFS community has settled on ipfs://<cid> URL scheme for these portable linking capabilities. There was even some effort to support this in browsers, among which I think Brave does support this kinds of links by default.

grantwest commented 1 year ago

@burdiyan Thanks for your input! I think that is a very good idea!

ghost commented 1 year ago

Relays can't be expected to host media, the infrastructure requirements would be immense. URLs break and many image/video hosts do annoying things that prevent simple unobtrusive viewing of media. Use of decentralized URN to embed media in messages should be normalized.

I think this is incredible. For example, there is an open question about bittorrent on nostr here: Protocol for decentralized image and video hosting. An example URN with bittorrent would be something like:

bt:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Also, I think this is a good idea because there is a proposal to specify the url scheme for bitttorent here. Proposal: protocol scheme for urls. Another interesting option is to add magic links in the URN.

fiatjaf commented 1 year ago

Mr. Ghost, please stop using the Ghost account to talk here.