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