Subnostr

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.

⚡️🌱🌙 2y ago

What I keep seeing is new protocols falling into the grooved road of older protocols.

I hasted to add… This is OK, because there is a lot of wisdom in those grooves.

But just be mindful of this when you see it.

There’s the fabulous anecdote (best told by Buzz Aldrin) that the solid rocket boosters of the space shuttle were limited in size by the width of a horses ass. All because Romans standardised chariot design around using 2 horses spaced 4ft 8.5in, this then became the root decision that specified every carriage, road, railroad, tunnel, bridge, etc for the next 2,000+ years.

Now if they hadn’t all standardised on optimal horse dimensions, maybe we wouldn’t have progressed so fast? But if trains had standardised for trains and cars for cars maybe things could have gone faster / better? It’s hard to know, but the compromise is really early growth v’s late growth.

If you are following grooves for interface reasons, that’s probably a good thing. If you are following grooves only for convenience then that’s a risk to future growth and you should state in public and seek to revisit at earliest opportunity as cost of fixing only grows.

There’s a lot of convenience decisions in MVP, and it’s that tech debt that often kills a lot of otherwise excellent ventures.

… not being critical at all, I assume you posted it for this kind of feedback?

I would certainly build for convenience and then seek to refactor for immediate optimisations as soon as you feel the case is made.

Reply to this note

Please Login to reply.

Discussion

Blake 2y ago

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