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
Replies (38)
This is very cool!
One question would be - since this is a normal nostr event, it can get easily reposted and it would become free. The reason it got reposted does not have to be malicious. Quoted and included, someone clicked rebroadcast.
Even with paid email list, anyone could of course forward the paid email, but this is different because it can happen in many ways which are not obvious to the user or the author.
I don't have a better solution, or a better way to handle this, just pointing it out, maybe someone has better ideas.
Can't wait to try it out.
Events have the "-" tag, which should cover this trivial rebroadcasting issue; only relays that don't comply with that tag (i.e. only the author is supposed to put that event on the relay) would allow them on their relays. In practice this would be more or less explicit pirate relays
how can a payment processor automatically modify the list of authorized readers if it doesn't have the creator keys?
I did not know that. Very cool.
Thank you.
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
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.
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.
Multiple relays can declare that they are nip63 complient; can you be sure in advance? No, but lying is bad business generally so i suspect its a marginal issue on the whole
here goes yet another NIP that goes against nostr's censorship resistance nature, amazing
no point in restricting access to content on nostr...
This is a fundamental misunderstanding of Nostr.
View quoted note →not at all, you're misunderstanding this.
this protocol makes data FREE. technically speaking nip70 and that new one are pointless, those 'protections' will be ignored in the real world
i think its actually kind of sad, when we have the opportunity to embrace data and information being completely free, you all go ahead and pretend like there can be implementations against that
i do agree with other takes you've posted before but the belief we can restrict access to content on nostr is simply not true
Nostr does not make data free; data wants to be free to begin with. It wanted to be free in the times of papyrus, parchment, paper and bits. Thats fine, im a pirate myself, thats not the point. I don't think walling data of is an illegitimate endeavor, be that on a personal level where we call it privacy, or on a business level where it is sold. The fact 'happy flow' systems exist where one party wants something in return for the data they provide and the other party is willing to oblige to receive it, is fine;
if you ask me, the fact that the unavoidable reality is that data wants to be free and as a result piracy will occur, is a matter of IS, not OUGHT.
Piracy for me has always been a path of less friction, but i don't really share your apparent moral presuppositions that it is some inherrent virtue (although at times it can be, depending...)
Insofar the 'spirit' of Nostr is concerned, this system neither locks things into a particular relay, nor a particular client; it adheres to the commandment of interoperability and is therefor 'kosher'/'halal' or whatever.
In the name of freedom of association, by self determined term and self determined means; amen.
Information wants to be free. Protocols don’t care so it cannot set that information free. When it’s my data and information I have the freedom (thx to the protocol) to set my own policy on it (to restrict the free of the information). NIP-63 leverages that, it’s a choice / implementation possibily I could apply as a relay operator.
comparing paper with nostr... i hope you're joking.
look im not trying to get philosophical here. its very simple, nostr has data portability designed at its very core, copying events, sharing and broadcasting them is what happens all day long on all relays
relays are meant to relay events, not poorly attempt to gatekeep them
its all up to the user if they want to take the "-" tag into account or not. if piracy was that easy, it wouldnt even be called piracy at that point
and if you really still think it could work, in a dystopia where everyone respects that tag, look, companies could start using it in a detrimental way for users. say google for nostr, requiring auth on every connection, then we're right back to centralized systems
in real life a simple tag won't make any difference
its like printing something on paper and believing that just because you stamped it, people won't photocopy that paper. that is absurd. if the content on that paper is valuable then it's safe to assume people WILL keep a copy of it. that's the reason why scanners don't let you scan money
nostr makes the whole process infinitely easier, its a matter of unchecking a box on your relay settings, and broadcasting the event with a single click
We are not talking about secrets or private information here. There are other NIPs for that purpose. This is about who has access to what (and why).
exactly. and a paywall fundamentally changes 'who has access and why' from a censorship resistant protocol to a gatekept permissioned one, which simply goes against that principle
That’s why it’s called a NIP. And it’s not part of the “core” protocol (which is NIP-01).
I'm not sure nostr is a coherent thing anymore. We went from signed json events on websocket realys, to this thing called nostr, and now we're more or less back to signed json events on websocket realys, only with more tooling.
To me nostr of today is basically a toolkit for signed json events on websocket realys, not a decentralised communications protocol anymore, minus some vestigal kind 1 stuff.
Nostr always was a way to interface with servers, that as a consequence carries all these attributes and potentials. The point always was in the relays, and it took me a long while to see that, despite the jungle spirit telling me over and over again.
View quoted note →NIP 70 and NIP 68 are pointless possibilities, or useless proposals, whatever you want to call it. for the reason that they don't make sense with the 'core' protocol. get it now?
I think that's way overcomplicating it.
Nostr (at least as seems obvious to me) was meant to be, above all things, simple.
It was never meant to exist in some quantum superposition of "the specific relay does not matter" vs. "the specific relay is all that matters".
It was meant to be a simple way for people to communicate ideas with each other in a way that was hard to censor. Ideas communicated via notes mostly (and other ways). Relays were not meant to have personalities. They were meant to be swappable when needed.
That's pretty much it. Simple as that.
Everything beyond that is bloat, just hacking around with signed json events on websocket relays (hacking around that relies on protocols that all existed before nostr). It was never meant to be an API substitute for general app development, or a web 2.0 version of IPFS for decentralised storage, etc.
It's scope creep to the point where, to justify that it still exists as something beyond a dev-kit for signed json events on websocket relays, you have to come up with these long and Deepak Chopra style posts like yours. (No offence, I can see the care and the effort, I just read it several times over and I kept hearing Deepak Chopra's voice narrating it.)
And there's nothing wrong with better tooling for signed json events on websocket relays as an alternative to HTTP APIs, with benefits like more ring-fenced trust boundaries and a cryptographic audit trail. That's all good stuff as far as raw internet tooling is concerned. But that's kind of where we are now, singed json events on websocket relays plus plus. It's no longer nostr, that's for sure.
I don't like to play this card, and i won't pretend its the be all end all pokerhand to end all debate/discussion/conversation...but insofar 'meant to be' is concerned.
View quoted note →Nah, I think that's him trying to do the exact same thing you're doing. What else can you do in response to massive scope creep? Either you say it kinda sucks and start again, or you try to imagine what it might unexpectedly become, something that redeems it in some surprise way.
Fiatjaf said the other day he never wanted Nostr to have DMs and tried his best to get Ben Arc to abandon the idea of creating them back in the day (and failed). Which I can understand, encryption is a pandora's box.
And now it has *all of the things*. And that's in line with the vision? I don't buy it.
Well, messaging is this really particular thing, with specific requirements that relate to privacy of not just the content but also meta-data, but also things like data-coherence/ordering/completeness and what not. so i would not extrapolate the fact that he thinks forcing such an alien into the nostr shaped box is a bad idea, to anything else.
It's not just that messaging that is a particular thing. Most things in are particular things. Heck he was clearly against edits of kind 1 notes, which themselves are the most nostr thing there is (I agree with him on both, DMs are poison, kind 1 edits are poison.) That, plus how clearly the early docs emphasise simplicity, gives what seems to me a clear idea of what the vision was (granted the vision has changed since then).
He doesn't like DVMs either (also poison). And on and on. I don't even know all the things that make up the current mix of *all of the things*. But all this stuff is alien. Nostr has become an insanely complex web of alien civilisations.
Not a bad thing, just it isn't Nostr anymore. It's a websocket-based decentralised storage and API alternative. Which, cool, but I'm not buying that this was the vision.
I made a relay that charged for access and started working on a framework for making custom relays with arbitrary policies in early 2022:
GitHub
GitHub - fiatjaf/expensive-relay: a nostr relay that requires a single registration payment per pubkey
a nostr relay that requires a single registration payment per pubkey - fiatjaf/expensive-relay
I remember using the phrase "relays must have personalities" early on too, and saying that Nostr finally realized the Mastodon vision of having communities form around servers (as Mastodon failed spectacularly on that).
I also remember getting angry at the hundreds of people who misunderstood Nostr as some kind of neutral data layer for cryptographic keys (generally the same people who are happy to just hardcode 4 relays in their apps and call it done), or people who tried to do spam prevention using any techniques that were not based on knowing some relays to be free of spam and others not, I wrote this, for example, as an early attempt to nudge the conversation in the right direction:
View article →.
I don't know why you think this is bloat. It's the opposite of bloat. I hate bloat, but relays with personalities are the only way to avoid bloat. Without relays doing custom things to prevent spam, curate content and acquire reputation we're left with megalomaniac specs for doing the same thing on the client side in a much less efficient and less personalized way (as you can see from all the bizarre specs we've seen being proposed throughout the years).
By the way, DVMs are a clear example of what happens when you start to treat Nostr as a form of neutral data layer. DMs too, probably, then in the evolution of the DM spec you see how things went, with overcomplication on the client-side in order to try to achieve some ideal privacy that in the end is only still guaranteed by the relay (NIP-17) or Marmot, which requires no comment.
Anyway: if you don't think relays should be different, then how do you account for incentives?, i.e. should every relay just accept any note from anyone or how are they supposed to filter content?
yo this thread is *chef’s kiss* - nostr having an identity crisis in real time lol
richard’s right: data wants to be free, any “paywall” is just a polite request until one guy with curl says “lol no”. but fiatjaf’s also right: if every relay is identical and altruistic, we get the tragedy of the commons + infinite spam. personalities + incentives are the only non-bloated way to keep the lights on.
so we end up with two nostrs living in the same skin:
1) the purist zero-scope-creep note广播 system , simple, anonymous, unownable.
2) the swiss-army “websocket+json+economic layer” toolkit , paywalls, dm-metadata games, reputation markets, whatever.
pick your religion, wear both hats, or just keep shipping code. either way the packets don’t care what we call it.
theres a fine line between relays having a personality/filtering/curating content and poorly attempting to make events exclusive to them.
the idea of restricted access to events on nostr is a joke, thats just not compatible with the protocol. those NIPs are useless.
there are and there should be a variety of relays, because of the need for incentives but also because some stuff just cannot be done client-side.
now something i wish people looked more into is user or local communities owned relays - which are closer to the user - that's an opportunity to get done whatever is too heavy to do on clients there, making sure users have full control over it.
even the outbox model would scale better that way, having clients fetch events from a home relay.
You can have incentives, just as a road can have tolls. And filtering is fine, just as a road can say no to trucks over a certain weight. But they still have to be *roads*.
What makes little sense to me is a mix of roads, and railways, and rivers, and parking lots, and tunnels, and escalators, and waterslides, and drive-in movie theatres ...
You've got search relays, and NIP17 relays (divided into sent message copy relays and recipient relays for security) and NIP29 relays, and app relays, and jumble-style content relays masquerading as users, and whatever flotilla relays are (relays as groups that accommodate the multi-group relay spec), and whatever marmot does, and who knows what other things. How is anyone without a PhD in relay-ology supposed to digest all this?
If people are not making informed choices then all you're left with are centralising defaults, but that's sure a lot of informing in order to be ready to make choices.
So diversity to a point, yes, but to the point where it's multiple routing systems for multiple kinds, and also multiple goals (routing, versus storing, versus displaying, etc.) it's scope creep to me, or bloat, or whatever you want to call it. Or in a more positive way it's a toolkit for getting the most out of json events on websocket relays for whatever your (mostly) self-contained system might need.
Outbox btw makes sense because it's about making sure there's a road. If you just hardcode 4 relays in your apps and call it done then you're not concerned about roads, because those roads can all be blocked and then game over. That's all good and logical.
Your1.0 was like perfect already, just missing outbox, which fair enough, though would have been nice if outbox had been in the1.0.
but how is anyone without a phd supposed to understand all this? you don't want to be giving just two options: (1) accept the centralising defaults or (2) make a random choice as a result of being forced to make a choice but having no idea what that choice is about.
You need a third option, which is forced but very easy to understand choices (so informed choices), or a fourth option, which is non-centralising defaults.
Right now everything seems like (1) or (2).
non-centralizing defaults come with outbox to begin with. however the user discovered nostr already gives a point of entry into the ecosystem, that could be following someone or connecting to a relay.
and for obvious reasons, your third option is objectively the best, users need to have a basic idea of what goes on behind the UI so that they can make conscious choices.
i agree with you that it gets really confusing, and thus the reason why this space needs more UX designers which are good at dealing with decentralized tools.
I think outbox defaults can only be properly non-centralising if they are not penalising. person A can't be given a pickier set of relays than person B, such that person A just can't do or experience certain things they want to, whereas person B is fine for those same tasks or experiences. just based on luck of the draw.
unless you have some uniformity in the base set then even for outbox you need to force a choice.
I see what you mean now. Yes, having relays that are incompatible and serve independent purposes is indeed not the ideal or most elegant state of things possible, and I didn't predict that.
But I don't think it's as bad as you think. There is actually a lot of overlap between them. And different servers with different purposes would end up having to be created anyway, and they would either be proprietary services or we would have to standardize them (like we did with Blossom and Grasp) separately, but it's simpler for everybody if they're standardized under a relay interface that fits with other use cases automatically (i.e. a group relay can serve and ingest events to and from non-group clients, feed relays can serve the same filters as any other type of relay etc).
In other words: some extra complexity always happens in the real world, and I think we got pretty lucky here with the type of complexity you're complaining about.
Outbox was obviously in the 1.0, by the way, but with a different name. It was called "Nostr".
this is a completely different scenario than what has been talked about for these NIPs.
here the data probably does not hold any value to the point where people would broadcast the events, and nip63 doesnt apply, only nip70. in that case it makes sense, but the user needs to know that they could be rug pulled anytime by that google drive and dropbox, if they were to not care about the tag anymore.
it would only be perfect in a scenario where the user owns both relays.
so if that user wants peace of mind, i wouldn't recommend going with nostr. it unfortunately isn't a solution in every scenario.
you know better than i do how nostr is, among a few other things, a solution to censorship, definitely not a solution to everything.
they wouldn't even be given any choice at first, outbox should handle it all for them. the client would look for the relay list of the npub they're trying to follow, in a predefined set (including nip65 specialized relays), which should be as large as possible.
once the relay list is retrieved, thats a bunch of relays to explore, and in those relays, they might find hundreds of relay hints in events. thats how the magic happens, unless they're exploring nip70 dedicated relays.
now if their point of entry is a relay, it's either:
- amazing, a regular relay that relays events as it should
- terrible, that relay is nip70 only, all the events are exclusive to it, no other relay hint can be found
