nips
nips copied to clipboard
nostr-protocol
Moderated channels with membership invite links
This NIP defines a way to create channels that have restricted membership, where members may invite other members and only members can send messages. This depends on #1242 - this nip requires a mandatory bot for managing the channel computation.
This nip allows the implementation of permissions systems similar to Telegram or Discord, and the creation of easy-to-use invite links. By enabling an invite-only system but giving easily spreadable but revokable invite links, this can greatly mitigate spam problems while also not adding unnecessary friction.
Sample implementation will be released soon tm
This is different from #875 but you might give that a read through if you haven't already. It includes a mechanism for invites to private groups and member lists. If you have a bot with an admin key managing membership and moderation, you could probably build what you're creating on that spec (although moderation isn't yet specified).
Clients must not show kind 42 events without approval.
This is a repeat of the fatal flaw of NIP 72. Those communities tend to die, because moderators disappear, and no posts ever get approved. I would recommend defining moderation more loosely as in https://github.com/nostr-protocol/nips/pull/1024
https://github.com/nostr-protocol/nips/pull/875 but you might give that a read through if you haven't already.
This is semi-compatible with #875, I may consider rewriting this to be an explicit extension of that rather than being its own thing. Right now though I want to keep separate any discussion of message encryption or forward security, as that is besides the point of this NIP.
This is a repeat of the fatal flaw of NIP 72. Those communities tend to die, because moderators disappear, and no posts ever get approved.
The point is that the nip explicitly requires a bot to handle this. There must not be a human in the loop.
The point is that the nip explicitly requires a bot to handle this. There must not be a human in the loop.
Seems unenforceable, and like it would raise the bar for people who want to create their own channels without running infrastructure. But I've definitely had the same thought — in fact, I built triflector in an attempt to automatically manage group membership. It's not really complete, but it has support for both relay invites and group invites.
it would raise the bar for people who want to create their own channels without running infrastructure.
It is intended that end users do not run their own infrastructure, but instead a variety of providers implementing this nip will be available. Though that definitely wasn't clear before - I updated the nip and explicitly added a way to create new channels.
I built triflector in an attempt to automatically manage group membership.
The fundamental problem I see with relay-based access control is that any access to controlled resources must necessarily pass through only a single resource. The same events passing through a different relay would be uncontrolled.
By decoupling the auth-rule black box from a relay and turning it into a bot, controlled events can and should be stored and transmitted through multiple relays.
The fundamental problem I see with relay-based access control is that any access to controlled resources must necessarily pass through only a single resource. The same events passing through a different relay would be uncontrolled.
Not necessarily, you could have two relays controlled by different people, both implementing access control. It's basically the same situation as with a bot, except you can use commodity relays. The choke point is the admin's key, which is needed for moderation.
But on another once-over of this NIP, it looks like the moderator may not necessarily be intimately tied to the group, but is simply a reasonably trusted third party? That could be interesting — moderation as a service. You could even ask multiple moderators to watch your messages simultaneously for redundancy.
That could be interesting — moderation as a service.
Yep exactly
Not necessarily, you could have two relays controlled by different people,
Hmm I need to read the approach in more detail - what I said mainly applies to nip29. Is there a nip that describes triflector?
Only #875, but the way it works is you basically set up the group to point to two relays which are run independently, each of which enforces auth. Increases possibility of event leakage, but reduces possibility of censorship by the host.