it also runs on a TCP socket, and it makes no sense to do request/response style API over sockets if you can just use HTTP, because with HTTP you can literally make calls with CURL
Discussion
NIP-86 is over HTTP
in any case, i don't think it even belongs in a NIP because it isn't machine to machine relevant
It also requires a NIP-98 auth event... feels very convoluted - but maybe I'm wrong.
If you had to design it, how would you go about it, including the auth?
yeah, that's a good one... i'm just focused on how to make it as simple as possible
that means http, http basic auth
i don't have control over building a client so that's the thing... this more sophisticated with signing events requires a client to generate the signed event
while on the other hand, i'm right now using a client app framework (web browser) that understands http and basic auth
i tend to think that more than a few admins on one relay is asking for trouble anyway, and i have in mind more the "small private relay" situation
anyway, think about the game theory of more than a few admins on one relay, i think from 3 and upwards, you start to get potential politics, and are we going to encapsulate game theory into our auth system to mitigate this?
i think better to just keep relays small and max 3 admins using a single password to do this kind of back end management
and i guess actually if the objective is to make management able to be controlled by an app, then this complication becomes necessary and not any more talking about human clients who need to tamper with settings on the relay
so, long winded response but there is one more point
in my admin system design, it simply designates owners, and their follow addresses designate permitted users that must auth to read and write (except for directory events, as i have been discussing, event kinds that need to be public and easy to get at, but not access to publish them)
so it already works with existing clients for human control, and it is very small amount of code to write an automated scheme to make it automatic
i'm building out NWC capability in the relay now so it can be bound to a lightning wallet and when it receives zaps it can credit users to add them automatically to a relay npub follow list and voila
as for handling mutes... i've thought about a few ways to do that, but it's really a relay owner's prerogative so that's separate, again, game theory, democracy, blah blah politics i'm not letting that stuff inside my work, it can stay outside thankyou
so, yeah, that's my thoughts
mostly it's about thinking of what actually you are going to do, and not complicating things by adding multiple ways to do the same thing
liek using follow lists as a mechanism for access control, this fits really neatly with a relay's inbuilt logic if it has payment rales plugged in, it can receive payments, and then allow users in
if a paying user is abusive, the humans who are also listed in admin, can add the user to the mute list, and mute list precedes the follow list, and triggers the relay to reject requests and events
so you see, it doesn't need to be complicated... i guess when i'm done building out all the bits that it needs i'll maybe talk about formalizing it
i will sit and read those two things a bit closer and formulate answers to all the points more concisely
i think the main thing is that there are data structures and contexts we can use to make a different semantics
a human follows to subscribe, but it's just a list of npubs, so it can easily be a whitelist for posting or a whitelist for access, and opposite for mute list
lists as a whole would let you add more functionalities, so you could annotate them and create a hierarchy of meaning about what these differently labeled lists mean
so you see, none of that required me to invent a new protocol, i just used what exists with the new context of "robot nostr user that controls relay" and you have several ways to regulate permissions and relay settings right there
anyway, just elaborating a bit more on answering the question, really i'm just implementing things that form a small part of what this NIP is about and i do want to look at it to make sure i'm not mishandling the information somehow or wrongly thinking about how to work it
right now i'm just refactoring this admin interface to have basic auth on it which means relay owners literally can just access at least some of the controls with URLs and a web browser, i think that this is a simple mechanism that would enable a lot of things... and i already have #realy whitelisting read/write access and blacklisted npubs feature implemented, and control it with my regular account, which is perfect for a personal relay
Do you have a repo?
https://realy.lol is my nostr work
it runs pretty nice already, i'm now into that stage where i'm adding this kind of feature as management
Cool, I just saw the docs on export/import. nice
I'm using Khatru because it's a library and I need customizations
i built this out of relayer and go-nostr you can build other things off the libraries in there
they have handy names...
realy.lol/event
realy.lol/envelopes/okenvelope
the data structures differ a lot, there is almost no strings anywhere, in some cases i've used generics to make it easy to assemble lists of arbitrary types that commute (eg string/bytes, integers, etc)