Nostr Web Client

So there is a NIP63 now, that is called ''Relay-based Paywalls'', but should be called Relay-based access control or something like that. Doesn't really matter, the point is this:

A creator has 'premium' content, i.e. content that for some reason should only be provided to particular people. The creator gives a list of these people to a relay, and then the relay is supposed to enforce this. There is room for a little bit more complexity to allow for more fancy situations, but this is the basic premise. I would like to briefly explain the reasoning behind this set-up.

First lets point out that the system is agnostic towards the reason someone is one the 'premium-list', as the name of the NIP suggests it could be a 'pay-wall', but it is up to the content creator to figure out why and how people get on that list. It could be because he got paid (in zaps, or via creditcard or gold coins), or because people publicly follow the creator, or because people pinned a post expressing their eternal devotion, love and praise to the glory of the content creator; it does not matter, as long as the content creator is compelled to put you on the list.

This puts responsibility on the content creator to figure out the logistics of maintaining this list, which could be a bot they run themselves, or some service provider that helps them do it. Assuming there will be more than 1 relay supporting this NIP, the content creator has the 'same'(albeit in theory a bit more limited) flexibility in terms of using redundant relays and switching when needed.

The whole point of the system is to make it such that the experience and flow on the side of the audience is as smooth as possible. From their perspective, they just follow the content creator and get the 'free' content, up until the point they performed the required action to be put on the list, after which they now magically also get the 'premium' content; this works for any client, any kind for as long as they remain on the premium-list. Other than being not completely retarded in handling AUTH procedures irt the relay, which should not be the case to begin with, the client-software needs nothing special for this to work.

When i say that the experience and flow on the side of the audience is as smooth as possible, i don't mean just in a Nostr context, i mean in general. I can't think of any possible scenario which is better; regardless what app you use, or decide to use later and regardless the purpose of these apps, it works. RSS based podcasting can't do this, nothing can.

Nostr

the axiom 3w ago 💬 2

how can a payment processor automatically modify the list of authorized readers if it doesn't have the creator keys?

Reply to this note

Please Login to reply.

Discussion

Constant 3w ago 💬 1

Well, it cant, but a service could receive a bunkerlink from the creator, where the creators bunker/remote signer only allows for the automatic signage of such lists events

Constant 3w ago

I can imagine many more models, but there are three elements:

The required action infrastructure (for instance creditcard payments);

The observation the action occured (for instance the payment provider anouncing a payment happened via a DM);

The mutation of the list (for example a bot on the creator side that looks for such dm's before it takes action).

The last part always demands something from the content creator because of requirement to sign with particular keys, but where those other two are residing could differ.

Dawn 3w ago

The creator is authorizing the relay to act on (or not) whatever particular information it receives, in order to serve content, so it's just collecting data until it meets a certain threshold. Starting out, that's zap reciepts.

A (possibily close) future implementation could be that the creator tells their WoT provider that they want to send "premium" notes to only their most trusted associations. That provider could collect mutual interactions or whatever until they meet some defined threshold. At which point, that provider could send the newly approved npub to the relay, and the relay can start acting. The lockbox relay is kind of a light version of that now, serving notes to only the author's follow list.

Integrating traditional payment methods could be a simple form with CC info with a spot for an npub. A relay would just need to be modified to listen for said information and the payment processor would just need to send the proof of payment + npub.