😵

So I’ve made a fair bit of progress with a white label Nostr CDN (use your own domain) that accepts Lightning payments and checks access either via a cookie session or Nostr HTTP AUTH spec.

For paid images you don’t have access to, it shows a blurhash or thumbnail preview (but with a 402 response status), then you can hover and click to buy via lightning (money goes to seller directly, with a provider service fee added using a wrapped invoice).

You can pay with Ably. And then if you refresh the image, and send either the session cookie or Nostr HTTP AUTH header, it will show the unmasked content.

The best part is this actually seems to work fairly well in web browsers. Nostr apps would just need to detect a 402 image response, and either try auth or offer to pay the invoice.

Early days, however it’s possible to use Alby as a Nostr auth extension and invoice payment method. And a simple JS library for loading 402 style images that leverages it could be pretty cool.

PS. If this post kills @fiatjaf with boredom, forgive me.

The idea was basically that lnproxy is run internally (not a public api) to wrap an invoice on behalf of a seller. It asks the seller for an invoice (lots of ways, but I have LND with Invoice Macaroon working, but could even be a Lightning Address). It then wraps the seller invoice with a new invoice for the seller sell price, plus a maximum routing fee for your wrapping invoice, plus a service provider fee (fixed, %, variable, etc) you decide.

Then you use hold invoices to do two things, ensure routing is possible to pay the seller, and things like your server doesn’t crash or items are in stock. You present the buyer your provider invoice which includes your provider fees to pay, and if all goes well, when you release the hold, both your invoice and the sellers invoice clear.

Maybe I’m missing something, however it seems to all hold together. I have it working locally - just need to make sure there are no attack vectors I’m missing.

I wrote about it more in the PR.

https://github.com/lnproxy/lnproxy/pull/24#issuecomment-1537341469

Test https://cdn.wako.ws/m/PAIDIMAGE

😵‍💫

The best part… they literally control who can join 😅

I’m almost sold on it. Yep, I’m really just experimenting - however fighting for adoption of new is largely harder than using existing like functionality even if not great.

nostr:note1clk67fp29mea0ldldpqn7a8c8p3cdxvg3r899q38t75m34mq89hs8q2skn

I almost died by testing my idea more and I think the web is too fucked to make some of this actually work 🫠.

Still trying to make browsers have some reasonable inter-op.. anyway.. one can dream.

Browser JS APIs don’t allow websockets to open with connection (auth) headers 😳

You can’t get http status code or response headers from an img tag (without manual JS requests), to interact with JavaScript and show custom UI, or dynamic send AUTH or pay an invoice 😵

These are decade+ old gaps that still exist today. Maybe web browsers fade out of existence sooner than I thought.

You can’t even make this stuff up..

WWW-Authenticate docs are worth a read. I didn’t know about this part.. apparently it’s a MUST to include.

“A server using HTTP authentication will respond with a 401 Unauthorized response to a request for a protected resource. This response _MUST_ include at least one WWW-Authenticate header and at least one challenge, to indicate what authentication schemes can be used to access the resource (and any additional data that each particular scheme needs).”

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate

Thinking out loud how we can easily support Nostr 402 (payment required) and 401 (unauthorised). Good news — I think we can just use a WWW-Authenticate header to indicate supported auth methods - which can double as a way to prove payment.

Basically, for 402 Payment Required, we can return a mime/type suitable response.

For an image we can return a blurred/masked image and maybe some kind of indicator it’s paywalled with two HTTP headers. An invoice header to optionally pay and a WWW-Authenticate with something like Nostr-NIP-98.

Doesn’t solve the issue of knowing if you’ve already paid. If you get 402, do you automatically try auth to see? Privacy issues exist. Do you try auth once before invoice payment as a sense check? Also doesn’t solve normal web browser inter-op. Maybe closer to an approach.. but lots to solve still.

One possible approach is to whitelist domains you are happy sending HTTP AUTH events for accessing the content - paid or private.

I used to dislike them, however it’s helped me see content I used to consume, where the source hasn’t joined Nostr officially.

I feel a hesitation commenting or discussing the content from feed bots however. I often check before I reply and skip if it’s a 3rd party bot. And I’ve noticed they often get less engagement when I would expect.

It’s not clear in Damus; there are three images in the above post.

For dead simple one off pay and receive, delivery via a Nostr DM - for sure, no URL. Only a common relay URL/domain is needed. But if your event has an image or video (and you’d prefer not just to be a secret sharing approach, like a ‘anyone with this private link can read this file’ approach), then how do you control who can access the image or video in this scenario - without the risk of someone sharing the access publicly? Obviously downloading and reposting is possible too - however it’s impractical at large scale (like where is the YouTube clone that rips all their content?). Largely tied to demand (like ripping movies/series).

For example two, how does the user access the service? A relay URL? A URL/domain to configure for translation APIs? Depends how your service is delivered. If you use a Nostr event request and response approach, using like a HTTP Nostr API to access it, sure that can work - I’m less convinced it’s suitable for many use cases, as Nostr events have real overhead many performant/scalable APIs don’t need. Maybe in 5-10 years the overhead will be negligible.

For situations that require repeated/future access (did pay, is current member, access not expired, etc), where there is an access check mechanism, it needs some centralisation (if again you care about its distribution). Maybe some key exchange encryption can work - however it doesn’t have the same properties as being having a centralised gateway.

I may be overlooking something, and I’m hoping other methods exist - I just don’t know of any that have the same or better attributes than a URL/Domain approach today.

Domains/URLs are really just pointers, I entirely agree. Controlled distribution is just one use case they support well.

Sometimes it seems like ideas are common sense - however the majority that get adopted are hard fought.

An example with BTCPay server resistance adopting LNURL. Not trying to call people out.. this happens behind most innovation - however it can make us appreciate those who keep iterating and striving for better. Thanks 😊

I’d love to replace URLs, yet I think they’re here to stay for some time. They also appear to be reasonably censorship resistant - while I think ICANN and their shit-domains strategy is borked - you have countries and domain TLDs not solely under a single/coalition countrie’s laws/control. It’s still centralised - and no silver bullet.

Long live:

The Pirate Bay

Wikileaks

Etc

URLs are particularly useful around services that need some centralisation - like a paywall or paid service. How can you trust a decentralised someone to collect money on your behalf and validate payment for access your service or content?

I haven’t read the NIP for implementation details, however this is a much nicer way to support moderated and curated content for Nostr. Opt-in, easy to follow competing/alternative methods (humans, AI, statistics, topic enthusiast, etc), it focuses on its own content and not hiding/suppressing other content, can be primarily hosted by specific private or community relays, etc. and when we get local client keyword/hashtag filtering, you can personalise it even more.

You can build a custom feed admin view that makes it easy to repost existing Nostr events or post new ones. You could even accept proposals for content to get added. You can have multiple curators or just one. You can enforce rules, like required hashtags or content warning on every post. You can suggest accounts to follow or click to follow all when someone joins your community - perhaps similar to discord chat channels - but post focused. nostr:note160wnuh522ufea564e02p9699k4xzl2gvgzjfwrcz63ygfm36e3msj4eldq

This Satoshi guy knew Game Theory well. Almost unbelievably well.

And the adoption curve has been perfect so far as well. Harder to kill over time.

You’re still in the matrix. Wake up Tony.

GM 🙂

I was going to give my Bluesky invite away for free without using it. Sadly, I’m not sure I can morally object someone to such a scam-social company now… nostr:note1638pzg87rw8g9drepu05w004khgghr7hvg60l9zk7m27p9tdxrjqn0mpj7