What would be really cool is a project that allows you to upload media from inside your Nostr Apps, and then use your own custom domain for the access url.
Main reason being if you control the domain, links don’t break if you change provider or host in the future. Host could be AWS, VPS, maybe a paid Nostr CDN service.
How much interest is there in something like this? How much risk is there for runaway S3 cost?
Maybe uploads require a NIP-98 HTTP AUTH header. Pretty simple.
Access to files could also require an auth header access check.
Easy enough to do, but market for that is so small, that I doubt it’s worth doing. 🐶🐾🫡
I think it’s small in the sense that currently people are using centralised hosts like youtube, Patreon and OF. If you want personalisation (email, NIP-05, website, etc) and de-platform resistance - you’ll need to at least control the domain.
And if you add in subscription services where to access content you need to use Nostr HTTP AUTH - then that can just sit in front of the CDN data.
I can definitely do it, it’s not hard. But again, most people have no idea what a domain is. And we end up with people who knows what it is, and likely can do it themselves already. We are talking about 1% of 1% of people. Don’t see how it can even recover initial investment 🐶🐾🫡
Fair points.
I think most content creators tend to be self learners and willing to follow a guide or setup, if they find the outcome valuable.
The every day common consumer - far less likely, unless it’s a tap to configure.
Precisely. Unless it comes with the purchase of a domain, which is doable, not likely accessible to consumers outside of tech. If with domain, then price bracket changes further up and again shrinks the customer base. 🐶🐾🫡
So would this be the equivalent of a client allowing you to add your own custom image upload service in the settings, in addition to the nostr.build, nostrimg, etc options?
Yep.
Technically Nostr.build or other Nostr upload services could support custom domains too. They would just need a way to link a domain to a pubkey, and redirect the cdn.custom.com requests. If you use HTTP AUTH for uploading, it could be as simple as just select provider in the app drop down - once domain was verified/configured in some web portal.
The goal being if you used them and then moved away in future, as long as the file paths don’t change, you can just download and upload to a new provider. URLs won’t break.
Interestingly, this sounds kind of like one of the problems IPFS aims to solve. Files are identified by their content rather than where they're stored, since IPFS is distributed and copies of the file can be stored all over.
My use case is more focused on content creators who want some control over their content distribution and logic/rules. Maybe it’s as simple as members get to see content 2 weeks before everyone else.
If it’s general public content, and no payment or access checks are required, for sure - hash content addressable over http/p2p/Nostr relays is fine. I like it.
interesting, i would love to be able to do that
I’ve already built a functional POC - but would need a lot of work to consolidate before open sourcing. Making it as simple as possible.
I’d also love perhaps to have services that providers can advertise via Nostr events. There can be a spec file, and then upload providers can publish their spec and service offering. Apps just use that config to add them as an option. 
> How much risk is there for runaway S3 cost?
Depends I guess on how popular it is to download your posted images. That’s the most highly variable thing. The storage costs are under your control presumably (they’re your images IIUC).
I would recommend having your static fronted return HTTP 302 responses to point to your service provider(s), as opposed to fetching and forwarding the day like a proxy.
Thanks. Makes sense.
Only partial issue is unless the CDN also has an auth layer, you’re redirecting to a ‘anyone can read’ link. If member access is required, this doesn’t work sadly. Unless you know of a one time key approach.
It sounds like you want ACLs on image reads. That is:
* unauthenticated user GET request -> 401 challenge
* unauthorized user GET request -> 403 forbidden
* authorized user GET request -> 200 OK
In that case, the authorization check could happen either at the stable proxy domain provider, or at the image hosting provider. I’m guessing the former is where you’d want to put that logic.
But yes, if the image hosting provider does authenticate requests, then leaking the image hosting provider URLs could get your content backdoored.
A way to solve this is to have your stable domain provider authenticate with the image provider and include a short-lived token in the 302 URL. That way, only clients authenticated with the stable domain can GET the image hosted resources.
Whether this roundabout token business is worth it I can’t say. 😅
If you're already logged into nostr, NosDAV based storage might be the way to go, by implementing NIP-98. I think some storages will take this path. Custom domains are a logical extension. OTOH an S3 API would also be cool!
I'm still looking for a relay that doesn't delete old notes
#[3] what’s the Nostr.wine paid user event retention policy?
Snort premium seems to have event retention as well. “Unlimited note retention on Snort relay”
We are hesitant to state a long term data retention policy at this time because it would be a pure guess.
For now space is not at all an issue for us and all nostr.wine events exist in a minimum of 4 separate geographic locations at all times. We have never deleted any events from nostr.wine and have no plans to start doing so.
If future resource constraints cause us to have to make a policy change our users will be the first to know and will be given a way to download/backup their own events first.
