Handling User Media Uploads

[leesalminen]

Starting a discussion based off this PR #268 .

To recap my understanding to date:

• @michaelhall923 opened up the PR that allowed a user to choose from 2 image hosting providers (nostr.build & nostrum.com) in settings. Then, users could select media to upload directly from the New Note screen.

• @jb55 expressed concerns about hardcoding integrations to hosting providers without guarantees of reliability in the long term from these providers. He also mentioned that he would prefer a proper spec that would allow users to configure their Damus client to use any provider they want that conforms to the spec.

• @BenGWeeks mentioned the idea of using torrents (dht/magnet links) to handle media uploads. @michaelhall923 expressed concern about illegal content moderation using this method.

• I mentioned the idea of conforming to the AWS S3 API as the proper spec @jb55 is looking for. Many, if not most, cloud object store providers expose a S3-compatible API.

My thoughts so far:

I had another conversation with @monlovesmango about this and we discussed using the pre-signed URL aspect of S3-compatible APIs to allow clients to POST directly to the object store without having to run an intermediary web server.

@monlovesmango is also working on building hostr (https://github.com/monlovesmango/hostr), which is intended to be a NIP-5 auth + lightning payment layer for media uploads to nostr.

hostr could be built to act as a wrapper over a user-defined S3-compatible object store provider that handles nip-5 auth + lighting payment + S3-compatible pre-signed URL generation.

Clients would just have to conform to S3-compatible APIs w/ pre-signed URLs. Users could then choose to self-host on their own AWS/Cloudflare/Backblaze/whatever account. Or they could choose to set up their own hostr instance for them and their friends. Or they could choose a service provider (like someone hosting hostr for sats).

[michaelhall923]

Should this be a NIP?

[BenGWeeks]

Up to the client isn't it?

[michaelhall923]

Yes but NIPs can also be about how clients should behave I think. Maybe this isn’t relevant though because it’s not about clients interacting relays. Still would be good to have everyone on the same page so media hosts don’t have to adapt to a million different specs used by different clients or vice versa.

[leesalminen]

I'm also unsure as to whether this is appropriate as a NIP or no.

[monlovesmango]

i think the hostr layer would be, as it is tied to nostr data.

the pure client s3 api integration prob not

[michaelhall923]

I like the idea of S3-compatibility.

[nostrbuild]

Please just work with us on connection requirements moving forward so we can plan and adapt. Thank you!

[leesalminen]

Thanks! That was my aim in opening up this discussion. Would be great for the image host service providers and clients to have some sort of understanding on this front.

[leesalminen]

While using torrents (dht+magnet links as media URIs in clients) is cool, after much consideration, I've come to the conclusion that this goes against the nostr ethos. It's spelled out pretty clearly in https://github.com/nostr-protocol/nostr -- "it does not rely on P2P techniques, therefore it works.". I agree with this and believe something like a S3 compatibility layer makes the most sense.

[leesalminen]

Sounds great for power users like us, but most people will expect image uploading to work out of the box. How will that happen?

Clients can choose to provide users with some default host provider... at the end of the day though someone is paying to host media online, it's not free.

[michaelhall923]

Maybe something like “add a lightning address to enable image uploads”. And then it just uses a default host with lightning payments

[monlovesmango]

this is why I wanted a "hostr" layer that uses nip05 to look for where media is stored. uploads go through that nip05/media hosting provider, whether that be 3rd party or self hosted. any client you login to could find your media content, and can sign for uploads via nostr event. also want to hash file names so that users are signing for the media uploaded.

and doesn't have to be nip05, could create net new field in the metadata.

@leesalminen I was also thinking with the hashed filenames it might be easy to construct a torrent index file, though I know absolutely nothing about what this entails haha. alternatively we could have a nostr version of an index file, that queries for a specific event type that users send to say 'hey i am reseeding this content'. just throwing out thoughts that have crossed my mind but haven't been able to validate if possible or worthwhile.

[leesalminen]

@leesalminen I was also thinking with the hashed filenames it might be easy to construct a torrent index file, though I know absolutely nothing about what this entails haha. alternatively we could have a nostr version of an index file, that queries for a specific event type that users send to say 'hey i am reseeding this content'. just throwing out thoughts that have crossed my mind but haven't been able to validate if possible or worthwhile.

AAIU torrent indices (aka DHT) actually keep a hash of the content of the file- providing some level of immutability that the magnet link points to a specific piece of content that can't be altered. It's an interesting idea to use nostr itself as a DHT of sorts...pretty cool actually. Will have to think it through some more.

[kimico]

"immutability"
Yes exactly why, "torrent is oky for me", "s3 not"

I'm thinking about developing a torrent client/server (for this purpose) with "s3" api that will make the files available on port "80" "just sha1" in the address. who wants, copies, by http or by "torrent".

So if "normies"(sorry) develop upload support for "s3" it will be easy for third parties to develop very "smart" and distributed solutions based on user needs. But I would like to guarantee "some things" and not img/base64 xD <3

My goal: allow uploading, strip metadata (very important privacy issues, for anyone who wants to implement it) at least on images.

[starbackr-dev]

Thanks to @monlovesmango for pulling me into this discussion. I am glad this is being hashed out now. Image hosting can be a local storage running on Umbrel or a cloud storage like AWS. It should be an option in the Nostr client settings. The deal between user and storage provider should be outside the scope of Nostr client. Nostr client calls the url from settings and pass on the image to get an image link in return. That link goes into the note and published into relay.

This may be ok for a web Nostr client. But may be a problem for App that goes through App store review. At starbackr we push all the uploaded images through google vision API to scan for illegal and Ch..Po.. stuff and reject them based on filters. So a client may choose to list only approved storage providers and not all. Or a client can choose to bundle their own service such as hostr.

NIP is definitely recommended to make it standard for all clients to follow.

[kimico]

"Sorry". #272 (reply in thread)

Still need a nip? :)

[Egge21M]

I have been thinking around on the idea of a more distributed approach to file storage in nostr for a while now. In my mind Relys can act as a hosting providers, without introducing any other requirements such as an S3 endpoint, by building on the protocols that are already implemented so far: WebSockets.

As it has been mentioned before, the nostr-protocol is not optimized for raw data transmissions, so I propose a second layer sub-protocol that is. I have started to note down some stuff on this approach nostr-ing.

This would not only allow us to share files over multiple Relays, but also lays the groundworks for distributed live transmissions (e.g., Nostr Spaces/Audio Chatrooms).

[monlovesmango]

clients wouldn't need to support additional tech. but they would need to support an additional protocol, right?

were you envisioning the distribution of content to also happen over websockets?

[michaelhall923]

We would need to consider legality etc. of hosting images. I for one would be very wary of hosting images on a server with my name attached to it.

Not without earning enough in relay fees (and even then I'm not sure) to pay someone to be reviewing content (that could be tips from relays to clients btw) as well as auto-detecting "bad" images.

I think the ideal situation is image uploads cost sats to users. This pays for hosting as well as using something like Cloud Vision to remove illegal content.

Hosting providers can change the file inside a URL without invalidating the note

hash alone is not sufficient to load the image or point to where the image is stored. IPFS Style URL will solve the problem of where it is stored and when that storage gets moved.

The idea is attach hash of the image data as note metadata. Then clients can alert users if the image has changed from its original state. Not sure if its scalable though. Also would prevent hosts from compressing images asynchronously, making upload times longer.

[leesalminen]

The idea is attach hash of the image data as note metadata. Then clients can alert users if the image has changed from its original state. Not sure if its scalable though. Also would prevent hosts from compressing images asynchronously, making upload times longer.

I wonder if it is really that important to provide cryptographic guarantees that uploaded user media hasn't been altered. Are there any image host providers out there today that can provide this? If so, perhaps it's worth taking a look at they handle it. Though, AFAIK, this isn't really a thing. Content at URLs on the web can change.

[Egge21M]

Content hosted by a third party is not censorship resistant.

Relays have to rely on the third party to keep hosting the content, as there is no way of effectively mirroring the file (note will point at old useless URL).

Without including a file hash, notes including URLs are not tamper-proof

I know my proposal is less convenient than centralised file-hosting, but it allows:

• a client to upload files to multiple relays
• other relays to independently mirror the content
• for signed references to the file to stay valid even when only mirrors are left
• clients to verify the integrity of the file
• streaming continuous/live content from one/many to many

I agree that not all use cases need this amount of decentralisation and that it might be suited for files that are at the risk of being censored.

[starbackr-dev]

good point @Egge7. files/images range from cat pics stored on centralized server to at risk censorable content that owner need to prove it is authentic at later point. We should spec for decentralized provable content and client/user can choose based on their needs.

[leesalminen]

@fiatjaf chiming in on nostr:

Some ideas that would be interesting to explore:

• A file provider like https://nostr.build but offering torrent seeding instead of direct downloads
• A platform for turning torrent magnet links into images (caching them briefly)
• Nostr clients uploading stuff (small images) to these torrent providers and inserting the magnet links in the notes
• Nostr clients that download render magnet links as images (if file size and content-type are applicable)
• Nostr clients that don't want to download torrents directly can turn the magnet links into normal image links from the aforementioned platform

I think this enables somewhat decentralized image-hosting:

• The torrent metainfo/magnet is derived from the file content for each image doesn't change, so even if one provider (or yourself) goes offline it can be in multiple others
• Since the magnet link doesn't change even if the provider that turns magnet links into HTTP images dies, the clients can just replace it with a different one, the notes do not lose their content
• Each of these steps can be done by different people, with different degrees with redundancy, cost and pricing

[fiatjaf]

@fiatjaf , since you're here now, do you have any thoughts on this comment earlier from @leesalminen ?

I don't think it is against Nostr's ethos. I think BitTorrent works despite being p2p, mostly because of trackers, which are similar to Nostr relays and a direct inspiration. IPFS poses as p2p, but in practice it is not, everybody uses gateways, and that is how it will be used in 100% of Nostr clients (I would bet on this if we had https://bitcoinhivemind.com/), so if people want to use that I'm fine too.

The only ethos I want Nostr to have is that things should backwards-compatible and don't bloat the protocol. So if someone introduces IPFS file links in posts that will probably be backwards-compatible, as any client written yesterday will just display that as some text that can be copied and handled manually by the reader, so it is fine. But I am repeating myself.

[starbackr-dev]

We have 2 options. 1) Do nothing 2) Implement base option that sets the direction for the clients so that a note can move around between clients. If option 1, then each client will implement their own version and soon the event generated on one client will be incompatible with another. Walled gardens starts to emerge. 80% of Social media interactions are visual (images, gifs and videos). Need to get this right to be successful and provide direction for clients yet to be built.

I think that is a very small benefit that isn't worth implementing. HTTP doesn't have these things by default, no one does this in the real world and yet here we are, everything works. Also, what if the creator wants to post an image that changes over time?

Cryptographic signature only emerged in the recent years and has become useful to prove ownership and authenticity. Hash is optional and creator can choose to post it or not.

2. Text based clients can show only text and hide the image links. I am posting event from starbackr with images. Some clients are not parsing the image file but simply displaying them as link which makes it difficult for the user. Keeping the links on tag will solve this.

Here's the illustration of same event displayed on 2 diff client with image url embedded on content.

[fiatjaf]

What is wrong with these two images? Looks perfectly to me. One has rendered the image, the other doesn't.

[fiatjaf]

Hash is optional and creator can choose to post it or not.

Then I'm fine with it.

[michaelhall923]

Ya… having images as tags would more likely mean that client #2 doesn’t display the image at all.

[starbackr-dev]

Alright. We had a good discussion and explored several options to come up with the best way to handle user media uploads. I want to summarize the discussion and see if we have a clear path forward for next steps.

Reading through PR #268 created by @michaelhall923 he proposed a way for users to upload media within Damus app. At the same time, I proposed a similar idea to @monlovesmango to implement in the Astral app.

The discussion was around how to support different storage mechanism such as torrent, S3-API, IPFS or use base64. From the discussion above, it is clear that all these options can be implemented by the clients, and they should choose which one to implement.

The goal is to be as open as possible with supporting different media storage. But at the same time, provide a way for clients to be compatible with displaying event properly to end user.

Also, we should discourage clients from using base64 image data and directly storing it on the event.

Change proposal

Nostr protocol : (May be a new NIP) - completely optional and backward compatible

Event structure will have additional tags to link to the file and a hash to the file when created.

Sample:

content: '\n' +
' Do you want the red pill '<'file1'>' or blue pill '<'file2'>' ? : \n '

tags: [ [ 'file1', 'link to image', 'sha256 hash to file' ], [ 'file2', 'link to image', 'sha256 hash to file' ]]

This is completely optional, and clients can still create events by directly embedding the URL in the content. but for the client displaying the content, they can scan for tags and replace the tags with the actual file they get from the location. They can also verify the hash of the file to confirm hash matches and only display the file when everything is good. Text only clients can display the content and ignore the tags. Tags should not conflict with anchor tags such as "p" and "e."

Nostr Clients: Clients can provide options for the users in their settings to pick a storage provider based on their choice. This can be a torrent location, S3-compatible storage, or a common storage location such as nostr.build.

Proposed file/link formats

1. Torrents: If the file/image need to be retrieved through torrent links then the link should be magnet link

A magnet consists of several parts:
magnet: (This is the magnet link identifier)
?xt=urn:btih: (Defines a Bittorrent Info Hash, the Edonkey identifier would for instance look like this xt=urn:ed2k:)
5dee65101db281ac9c46344cd6b175cdcad53426 (The content hash)
&dn=name (The name of the file)

Detailed implementation will be the responsiblity of the client team and possibly share info to other clients.

2. S3-Compatible API: Publishing the image to S3 storage will require authorization based on user pub/private keys, and the client will be responsible for sending this info to the storage provider and in return getting the retrieval link.

Displaying event: The client makes a call to the http url found in the tag and displays the file or image appropriately.

3. Generic storage: There can be generic storage like nostr.build that lets anyone upload images for free or for some SATs. If you pay for a service like 100 Sats per image, they let anyone upload with a pubkey and send an invoice as a DM to that pubkey. Once the user pay for that image then the link will be accessible with event. I can see may models emerge overtime. The key here is to have the options available to the users, so they can pick and choose based on their needs.

Let me know if I missed anything.

[michaelhall923]

Update: there is now a primitive spec that standardizes media uploads and retrieval in Nostr clients. Right now it defines an API similar to Imgur's for the sake of simplicity. It can be expanded upon to include support for things like S3 compatibility or torrents.

https://github.com/michaelhall923/nostr-media-spec