Oddbean new post about login | logout This guy is building the relay infrastructure I always imagined would happen. I'm just worried that clients are not yet ready to interact with such a great amount of power. nostr:nevent1qyv8wumn8ghj7cm9d3kxzu3wdehhxarj9emkjmn99uq3wamnwvaz7tmfde3x77pwdehhxarj9emkjmn99uq3jamnwvaz7tmhv4kxxmmdv5hxummnw3ezuamfdejj7qg3waehxw309ahx7um5wgh8w6twv5hszxrhwden5te0vdex2ct5wghxummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqzpywagj8yn7xnm8kfr7ea5eppnzaxssc6tjx9utyk3ugllfjedtfyeqc2eg
Many clients already support NIP-42 and our relays don’t need anything special, but not all implementations work correctly with all AUTH flows. I think most of the problems can be solved by clients correctly implementing the spec as it is today. The original spec did not include the CLOSED response so we used to send NOTICE/EOSE instead which wasn’t ideal. With CLOSED, clients know why a REQ was closed and whether it requires AUTH or is prohibited. They can then know which REQs to retry after they complete the AUTH.
I know I didn’t really answer your question… I think clients that are strictly interested in public content do not need to implement NIP-42. If your client handles DMs, NWC events, or any other “private” data I think some form of AUTH is useful and important for access control.
I will will use this for DMs in my onboarding client. https://nostrmeet.me
I know I didn’t really answer your question… I think clients that are strictly interested in public content do not need to implement NIP-42. If your client handles DMs, NWC events, or any other “private” data I think some form of AUTH is useful and important for access control.
I will will use this for DMs in my onboarding client. https://nostrmeet.me
I thought you were referring more generally to NIP-42. In the case of Creatr specifically, it is as simple as isolating your global view to the relay. We will continue iterating to support whatever community views that clients support as our main goal is interoperability. There’s still a long ways to go for sure. On several clients it’s quite easy to isolate a single relay. Here is a video showing the free preview content on the relay if you aren’t subscribed to anyone on Damus. If you were subscribed to someone, you would see their exclusive posts in this feed. If you went to a Creatrs profile feed, you’d see their exclusive content and free posts together. Clients could support labeling these posts and filtering them to make them stand out further, but it’s not required for our relay to work. https://v.nostr.build/xvJz.mp4
Fair enough! I’m glad there are multiple solutions. We are backend developers and not interested in building frontend clients so we came up with a way to do it as a relay. The most valuable part of Creatr, in my opinion, is the interoperable access control file host which can be decoupled from both the relay and the current website.
That’s the thing - since we aren’t building a client we can’t use NIPs that currently 0 clients support. The payment/invoicing/DVM part doesn’t seem to be fleshed out yet either. At least not publicly or in a way we could use it yet. We started building Creatr in April of last year. None of these ideas even existed. I had to pay for bounties on 4 clients to even implement NIP-42 so I we could even do some testing. Ultimately the project stalled on our end due to lack of NIP-42 support and being busy with other work. Finally decided to finish it a few months back. We will implement whatever the standards are once they exist and work in the wild (again, our focus is interop) but until then we have to focus on working with existing clients.