I have a spec ready for #communikeys that lets holders of a Community-badge (confirmed by the communikey) hand out that same Badge to others. Those invited profiles, however, cannot hand out that Badge, until the communikey confirms the Badge for them.
I think an invite tree that only has one layer like that is the best middle way for good UX and feasibility on the App, Relay and Spec level.
https://wikistr.com/nip-badge*a9434ee165ed01b286becfc2771ef1705d3537d051b387288898cc00d5c885be
nostr:npub1h49w8en79xty6j2pwgnpm3znjhyf767jua6xgt3kvyn3w80ms86s2z9kay how easy would something like this be to implement on the (automated) relay side?
The idea is that you'd (for example) ONLY accept Articles from the profiles that have a "Member" Badge (awarded by the #communikey itself OR someone with one awarded by the #communikey, not deeper).
If I understand the spec correctly, it shouldn't be that much hard. In a general big relay that is used by different clients, this check may break the function or performance of the relay. But in a Communikey specific relay it won't have any issues.
I'm setting up the spec so I can do in-app verification and still have it work in nostr:npub18stt78efprta2el02tzgnez6ehghzgtt000v58967wvkgezjmprs0n7h7u for #communikeys that use general dumb relays.
It'll just be slower and (potentially) a bit spammier.
Nice, will read it once you published it.
It's coming together in these wikis:
Thanks a lot. I'll read it. 👀
Great! Good to know 😃
