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.
Maybe uploads require a NIP-98 HTTP AUTH header. Pretty simple.
Access to files could also require an auth header access check.
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?
It’s a fair use case. Perhaps coupon codes or similar can be used here. The offers concept can allow custom offers per pubkey offered by the service itself - like special discounts or prices, or even free trial perhaps.
Or perhaps prepaid services can allow (p2p-style) you to send your existing credits to another account - like M-Pesa. However, I’d imagine that would sit outside this spec.
Maybe ‘shareable identifier’ for npub.
And optionally if they want a Nostr Username, let them setup a NIP-05. It’s literally just a username in all aspects (I think) - login, sharing, search, comparing accounts if identical other info, auto-complete, etc. ability to setup a username later.
And then secret/recovery/master private key (or similar) for nsec. Ideally nsec backup is an in-app action after initial setup - “keep your account safe, sync to cloud, save to password manager, write down seed words”. Setup 100% complete.
POC Nostr Paid Services Interface. I’d like to start formalising the subscription Nostr event data model.
I’d like to make it as generic as possible and it may not even be for a direct Nostr services - perhaps it’s like a Patreon, or credit/usage based API.
https://gist.github.com/blakejakopovic/a0deee4c945c122a59ed2dcf442d2e2a 
Definitely top 10 all time favourite Nostr accounts.
You can do either. Setup with a new key, or add an existing.
Once setup you should only ever need your seed phrase as a last resort or during updates (check you have access to it before upgrading as a precaution).
Depends on the hardware wallet, however you can export for xpublic key and it can tell you balances without any secret keys - just know that the xpublic key should be kept private for your privacy, but you can’t steal funds using it.
Plus the wallets come with instructions. I’d just follow those.
Basically we can have CDNs that ask a client to verify the viewers Nostr pubkey by sending an event.
Phase one from unauthorised to sending auth. Then you can check anything, like have they made less than 5000 requests this month. Or are they a member of my website.
Phase two is once authorised, you can ask/offer payment options - like a one time fee or become a member. Basically offer lightning invoices for payment to unlock access.
nostr:note1r94watxt6ulc8pv032ztnwsu7g4596ycwv7hryd9csyd7mzshqzs05yr5y
I have something early you can look at. Lots of todos, a small bugs/issues.
https://github.com/blakejakopovic/damus/commit/e27162b00fb10dcf2f02cc2fe533e1a09cb168aa
Basic testing endpoint (doesn't validate actual BLA content, just that something exists)
curl -I -H "Authorization: Nostr BLA" 
Endpoint code: https://gist.github.com/blakejakopovic/2e8fa806e1b85c17411b66b55f3df4e8
nostr:note172de9jv7nthqj06eznqke0u7v3zngluz9j06rskrauf5kry4428s8d7haw 
I’m confident it’s deceptively simple on the surface.
I still think Nostr would greatly benefit from having them defined by someone who has built a sizeable client. I’d do it, but it makes far less sense.
#[2] said he split out 28 subscriptions to cover all his use cases, but it didn’t really work due to relay max concurrent subscriptions. I don’t think it was shared.
I’d still like to see/have a common list. It’s extremely useful for apps, client libraries, relay optimisations, etc.
nostr:note1zu6r3hrmr4lmagmq5g8jdvnujcsfwyd4r89klnxh88hfnvf3syrq3057nf
It’s all good. A back door to extract your keys from a Secure Enclave just helps the government manage their expenditure better. Maybe the world needs an Octagon to keep it safe?
I didn’t realise Keet had added micropayments. Using USDT.. but still. nostr:note12djy7trtwfaee55u7k0x9zwj8zacc47aduem5yg863244npucdlqyyefrx
Did you star it and know around when you started it? You can look at your starred repos to try find it by sorting by starred at date.
Hey all, it’s me Ledger. I’m sure glad _our_ funds are safe. It’s just smart security that we share private keys with corporations we shouldn’t trust.
