This is really cool. Isn’t using a single relay for content like that just the same as having a centralized database?
Discussion
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.
Cool. Thanks for the explanation. Tradeoffs inherent, as always. I’ll be interested to see how it goes.
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.
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!