how would you approach this problem nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ? seems a lot different than the twitter way of using follow lists to avoiding spam.
I'm leaning toward a few servers run by different people for redundancy/weak censorship resistance, but they all would be required to have heavy anti-spam protections and maybe even shared spam ip blocklists.
could just make it stackernews style and require payment for every interaction, but I feel like that is too limiting.
The best approach (and to me the only that doesn't have crucial flaws) I could think of is still the NIP-29 one: groups are identified by a random id and can have owners and mods and rules, but the rules are enforced by a specific trusted relay. So in fact a group "address" is given by id+relay.
If the relay goes offline or become evil groups can just move to a different relay.
Anyone can also fork the group by reusing its id but defining a different relay that accepts the new ownership.
Why do few Nostr clients support groups? Groups are essential for engaging people. My dream is to recreate the old Orkut through Nostr.
this seems more suited to closed groups vs open reddit-style communities?
That's true, but I think something like that should be the basis for both. Telegram has groups that require invites and groups that anyone can join at will, but they're the same underneath and in both cases these groups have an "owner".
Now you only need to have a group like that (it's the default for most such style groups that exist today, for example, in https://chachi.chat/) and a relay that allows anyone to join, but only if they fit some arbitrary anti-bot requirements.
Authorship vs. Authority.
Curation vs. moderation.
Being able to fork a group's identity, and just port it somewhere else is incredibly interesting from a curation perspective.
as long as there is a space, where people can meet randomly, basically open public microblog relays, there will be avenues for two branches of one group, living on two different relays, to interact in their intersections.
What are the requirements you're working to?
My intuition is to start off with one relay per community, with relay selection options for that. Easy to work with, can have multiple communities of the same name. The moderators configure who joins through configuring relays.
Its a base case that most are familiar with, and higher granularity can come as needed.
