Replies (53)
Exciting stuff!! Good work!!
Thank you! Lots of work to do but it feels magical to have the content appear on any nostr client.
Awesome mate! That feeeling is great 😊
I would love to try that!
Awesome! I sent you a DM with more info.
love it. Cannot wait to try
Thanks Sherry!
Baller
Question: it only work from a web client like Snort?
The relay works on ANY client that supports NIP-42 client authentication. The ones I know off the top of my head are Amethyst, Snort, Coracle, and Satellite (although not sure if you can set your own relays there yet).
And Current!
If I watch a video via Amethyst, then my IP is remembered so I can watch it from a web browser if eg. There was a bug in the client?
Literally this video stopped half way on my client and I had to load it on the browser to see the full video.
Second question, does this mean all people in my home network are now permitted to see the video? If I visit via VPN, all people using the same exit node can access this video?
Thanks in advance. This project is super cool. 🔥
Great questions! The IP whitelisting is short lived and only happens after you connect to our relay. You should have no issues moving the content links directly to the browser.
Yes, all the people on your IP would have access to the content you have unlocked but they would still need the links or access to the content on the relay to get them. If you shared the content links with them, they would have access to it.
We hope to move away from IPs all together and use NIP-98 instead (signed nostr event in the header of the content link request) but it does not have much adoption at this time. Soon, we hope!
@Michael I'll be the first to subscribe if you're in👀
Nice! I guess more granular sharing would not be too difficult to add to the mix, such as posts that are only for a certain tier in the beginning but become public after a few days
Yes! Right now we let you manually adjust which notes are tied to which tier so you could accomplish this. More granular access control can be offered in future for sure.
How does it work? I can't see the demo
Here is the link of the demo: v.nostr.build/WQza.mp4
Or is it geo blocked? I can upload it elsewhere if needed.
ok. I am ready to try this on with Current App..!
Got a link?
@jb55 @Vanessa how hard/long will it be to make Damus work with Mazins new relay?
💯🔥
Cool
Wow! Great demo, such an great use of relays
Thank you! Understand the concern, but if we showed all the “hidden” posts as hidden for every creator the global fee would just be filled with “hidden” posts. We can signal an approximate number of notes each creator has in a given tier or something along those lines to help with discoverability though.
Absolutely freaking amazing work. 👏
OK OK devs cookin
View quoted note →Appreciate it. I’ve read through the NIP and some of the comments. I’ll try to add some comments to the repo later this week.
I think the 7002 tier event is particularly useful and we could immediately use that standard on Creatr so that clients could easily pull subscription tiers for a given user.
I am not so sure that users will want all their subscriptions to be public and I echo the same concerns about relying on a deletion to “stop” the subscription. It doesn’t address how to actually deliver subscriber content though, right?
It’s great progress. And totally agree on NWC being very helpful for payments here. Definitely want to discuss a plan for that with you more soon.
Soon!
This is really cool. Isn’t using a single relay for content like that just the same as having a centralized database?
Question:
If I were to use this, I'd still want all of my content to be public (no tiers blocking certain content), I'd want it to be more of a: "If you like what I'm building, here's an option for you to support me on an automatic monthly basis, rather than zapping my notes."
Do you think that will be a popular use for this in the future? Or will it really be geared toward people who have some of their posts public, and some behind a paywall?
Yes, with the advantage that it is interoperable with the existing protocol. Our goal with this product is nostr client and social graph interoperability, not decentralization.
There are centralization tradeoffs for access controlled content. If it needs to be spread on many relays, it needs to be encrypted. If it’s encrypted you need a key delivery mechanism tied to a recurring payment, either by a centralized entity or an always online user. You also need a way to modify/revoke future access to the now decrypted notes. The media/files also have to be uploaded somewhere that will access control the files and allow you to update which pubkeys have access and when.
I’m sure smarter folks than myself will figure all these things out but for now we built a relay that does the heavy lifting and works out of the box with most nostr clients.
Creatr is definitely focused on the latter. The main challenge we are solving is adjustable access control for notes/files. If you just want to offer a monthly support me kind of button, I think something like AutoZap will be an easier (and less centralized) solution for you.
Cool. Thanks for the explanation. Tradeoffs inherent, as always. I’ll be interested to see how it goes.
Very interested in how this might support private groups. What does a client have to do to work with one of these relays?
Right now the only thing required to use the relay is NIP-42.
It’s possible we could adapt this to work for private groups too but I’d need more details. I haven’t kept up too well with the current proposals. Are the messages in these private groups encrypted? How does moderation/access work?
I put together the inbox.nostr.wine prototype that allows anyone to write events that p-tag a user with an inbox and users with inboxes can only query notes they have authored or been p-tagged in. The main focus there is minimizing metadata leaks.
I am exploring the idea of nostr in business contexts. Even if posts default to a business private relay e.g for employees only, there is still lots of value add in the interop, data/acc portability, app ecosystem, etc. I am super pumped about this. Your relay/ NIP-42 should unlock many use cases here.
Thank you! We will eventually offer a relay-as-a-service offering that allows easily configurable AUTH for read access along with existing write control tools.
Still thinking about it, hopefully going to break ground soon. But it should work similarly, just as a place to post encrypted notes to to reduce metadata leakage. I'd also like to figure out invite codes as well, but that might not need to be special cased by the relay either.
I believe I gave your pubkey access to play with inbox.nostr.wine but let me know if you have any issues AUTHing there. I’d like to adapt that to work for most of the “private” use cases.
Please let me know if there’s something you need that doesn’t fit in to that current design and I’ll see what I can do to adjust it to fit.
Thanks, will do
I love it. I can see the market for it. I see "xyz for Nostr" directly attacking every business SaaS and winning. There's absolutely a market here, and the unique value that Nostr provides is not just going to catch them sleeping, it will be unassailable. Incumbents cannot directly compete on interoperability without destroying their own moats. I'm here for it!
Is your relay completely custom? Or is there an existing relay implementation which restricts read access to authorized users in the way that you've demonstrated? I'm looking at nip 42 implementations and finding that they usually about restricting write access rather than read access. Or maybe I've misunderstood. I would truly appreciate your input!
All of our NIP-42 stuff is custom. Most paid relays only restrict write access but not through NIP-42, just by keeping a pubkey whitelist or other restrictions.
I believe the rust nostr relay has a NIP-42 implementation but I haven’t used it.
Thanks for the fast reply Mazin, so cool. I think I have that rust relay up and running. Docs make me wonder if the NIP-42 implementation is focussed on write rather than read. If you have custom rolled yours, was stirfry your starting point? Do you have any plans to share or license your code? I am not sure what's involved in that, I am just trying to figure out an entry point to explore further.
We use strfry for our relay backends. For AUTH that is on connect (not for a specific type of REQ) we have a fairly simple custom websocket that sits in-between. Once the user passes AUTH, you can simply connect them to strfry.
For more complicated types of access control, the middleware becomes a lot more complex as it needs to parse each request. Strfry will eventually have NIP-42 built in - it is often discussed in the strfry telegram as a desired feature. The truth is it’s a complicated spec to implement for anything outside of “on connection” and for that use case it’s a poor solution (a header would be better, more like NIP-98).
I’ve ranted about this before but ultimately it’s not going to change and I’ve embraced NIP-42 for the time being.
Thank you so much!
I DMd you.
Do you accept Adult Working Creators?
Yes! I’ll send you the onboarding form.
Okay, this is really great! Many Zapit users have been asking for something like this, and it clearly has many use cases.
When your service is ready, I will also add this to NostrNet. Users will love it.
Thank you! We’ve been dragging our feet a bit getting this out because it’s quite a big undertaking but it’s slowly coming together now that we are onboarding creators.
