Oddbean new post about login | logout Interesting experiment. Similar to the way that nostrocket.org is setup, building an adaptable trust network environment, but for a relay.
It's another way to build a community, which has me intrigued.
Nostrocket actually uses this for the relay too; you have to be in the identity tree to write to the relay, just like this example by fiatjaf. The difference is that instead of storing the list of allowed pubkeys in a local file, nostrocket stores them as events so that it can can use dynamic sets of relays that any participant can run.
If you just want a single pubkey to publish an ACL list you could just use the lists nip. For a self-propagating tree structure that's no good though, which is why it's more complicated.
it needs to be a hierarchy of owners, admins and readers/writers at least, that's the base user permissions needed for an access controlled relay the owners have absolute control and there is one or two of them maybe, perhaps 3 at most, the admins can be humans or they can be keys controlled by services that accept payments and when confirmed add or change the permissions of a key so i'm going to do it as a single event type that is gathered up and used to define the current state of a simple list of users with their permission levels and keys currently thinking to use kind 3473 but of course if someone else has got something working before i get the required relays and clients built then i'll change it the tags would just be sorted in chronological order and the operations performed to replay the event sequence to acquire the current state, and of course any conflict of event timestamps has to be undefined and not apply to let the race start again the clients will confirm the state change by requesting the state and if the event didn't get stored it's because it conflicted and it should retry i don't see any reason why to have multiple kinds for this, just going to define a set of tags that constitute instructions
it needs to be a hierarchy of owners, admins and readers/writers at least, that's the base user permissions needed for an access controlled relay the owners have absolute control and there is one or two of them maybe, perhaps 3 at most, the admins can be humans or they can be keys controlled by services that accept payments and when confirmed add or change the permissions of a key so i'm going to do it as a single event type that is gathered up and used to define the current state of a simple list of users with their permission levels and keys currently thinking to use kind 3473 but of course if someone else has got something working before i get the required relays and clients built then i'll change it the tags would just be sorted in chronological order and the operations performed to replay the event sequence to acquire the current state, and of course any conflict of event timestamps has to be undefined and not apply to let the race start again the clients will confirm the state change by requesting the state and if the event didn't get stored it's because it conflicted and it should retry i don't see any reason why to have multiple kinds for this, just going to define a set of tags that constitute instructions