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