Oddbean new post about | logout
 > I'm curious about the goals part you mentioned toward the end there. You mentioned a relay implementation. Curious what that means. 🌱

Me too 😅 It's something I'll have to put some thought into. Off the top of my head though, things I want:

- Invite codes that a user can enter into a client, which then get sent to the appropriate relays to broker admission
- Multiple dynamic levels of membership, similar to Patreon. Some posts should be accessible publicly, some only for members, and only certain people should be able to post.
- Prevention of content leakage for public notes. Similar to how gift wrap works, but with no encryption. So you might have a public note (maybe protected using AUTH), but you don't want it re-published to other relays. So you instead publish it "to" the relay by doing some kind of relay-specific signature. That way, readers have to know where it came from to verify the signature.
- AUTH support, obviously. I think a way for a user to ask to authenticate would be good — that way relays can serve public content to unauthenticated users without asking for their pubkey. Then users can opt into KYC to access subscriber content. 
 Invite codes would be amazing!  Ie, put a code into amethyst and it sets them up for the friens relay instead of dumping them in the global dumpster fire.

Not sure about being able to prevent leakage, as some have said "paywalls only work once" rings true, (also given that nostr is easy to make your own client and you can harvest notes pretty easily no matter how much wrapping happens).  

Pointing notes back to their origin relay is nice, I think we already can do that with hints..?

A lot of this stuff, just needs AUTH to be a complete solution using strfry relays.  I've been meaning to pony up a bounty for this.. 
 Regarding invite codes, I've proposed using Nostr badges for access control. 
https://github.com/neilck/nostr-access-control 
 Nice, I like that a lot, although I imagine it wouldn't work for access control based on non-public data 
 I haven't thought about it like that...
until now. :P 
 How would you handle access revocation? 
 With auth based access control it would be simple, otherwise key rotation would be necessary 
 nostr:nevent1qqsvxf0k8p8zvsgxhjvctpn3w3dp30jfqdw6lwghcv8ed8h7fra6ltqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqqqqqqphw4qzgy6etty7zcfta4ggs90f3mz248tg5f3glas4fpt0qvzqqqqqqymz8wzd ?  
 You got it