Oddbean new post about login | logout i'm in, but i still don't know how invites work, @isolabell.art 🎨 said @fiatjaf probably gives them out. interesting concept, indeed. happy to be onboard.
I think each person gets two or three? Or is it by tier?
I believe the original intent was 2 per person, but doesn’t appear to be programmed in nostr:note1zw6372m4jz6a8w2n8uprcx5dqnmgp94a9u692fnnurxhnv2k2w6spnsw84
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.
it seemed like that. no updates afaik. https://image.nostr.build/838d0f2b127cd8f820fb874b99f08e80c35f146f970d3c7b5554e04b37022a20.jpg
the login link is dead for me on mobile... ends in /# and i haven't received any dms, have you?
I can login with NIP-07 and I'm able to invite people.
logged in on desk top, same. i believe the limit is 2 people
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
