It would be useful to have more refined control over participation in a group. Someone should be able to create a group that gives permissions to specific individuals. A variety of permissions would be useful:
- permission to see that a community/mag exists (some groups may or may not want to be listed in searchable a public directory)
- permission to read the posts in a community/mag
- permission to vote in the community/mag
- permission to start a new thread in the community/mag
- permission to comment on an existing thread in the community/mag
A forum creator should be able to set the above perms on:
- individual accounts
- all users on an instance (e.g. users on an instance
@weH8privacy.com
might be unfit for voting and writing comments in the community “fightForPrivacy”)
- all users not on an instance (e.g. local users only for example)
- instance IP-based (e.g. users from Cloudflared instances might be unfit to participate in a group called “decentralizationAdvocacy”)
Settings for individuals should override instance-specific settings. So e.g. a “fightForPrivacy” forum might allow all forms of participation from an instance stop1984.org
, but if antiprivacyMallory@stop1984.org
is uncivil, a mod should be able to block all inputs from that user yet perhaps still allow antiprivacyMallory
to just read the posts on the off chance of influencing the user to be more civil through exposure to civil chatter.
More background on the rationale - why the fedi needs this (click to expand)
The fedi has undergone a huge flood of new users, largely moderates from Twitter. The moderates dilute movements.
Consider the evolution of raves and Burning Man. The beginning was a rich subculture that briefly evolved in isolation apart from the ordinary world. These subcultures became more enriched within their own world whereby the core ideas spawned more culture. Then word got out and spread like brush fire. Masses of uninitiated crowds flooded into raves and Burning Man faster than they could be integrated. Commercialization took hold faster than people could be integrated. The scene became diluted with clubbers and conservatives who essentially turned raves into clubs. The way to promote raves that resembled the original experience was to selectively flyer party goers who overtly embraced the experience, who were not merely there to be seen. IOW, the fix was invite-only events.
The flood of moderates into the fedi has crippled the decentralization movement and corrupted the vision. The fedi is now swamped with people from huge instances that are centralized on Cloudflare (lemmy.world, sh.itjust.works, lemmy.ca, lemm.ee, programming.dev, zerobytes.monster) and lemmy.ml. People without a firm grasp on the meaning, purpose, and benefits of decentralization and privacy still find their way into “privacy” communities and make foolish remarks (e.g. not sharing personal correspondence with Google and Microsoft “is tinfoil-hattery”). Sure, it’s favorable that the “I have nothing to hide” crowd intermingle with more sophisticated privacy-aware folks. It’s important that there be a venue where ignorance can be reversed. But--
Moderates are a drag on activism. A “PrivacyAction” forum does not benefit from a mob of idiots who see those practicing established infosec principles as “tinfoil hat” nutters to heckle. Security-wise people with infosec degrees naturally and unavoidably appear “paranoid” to normies. These normies and hecklers can only get in the way in a workshop-centric forum with the mission of strategizing activist movements and protests. Fair enough if a “climate” forum has climate deniers butting heads with those who accept the climate-relevant science. That dialog is needed. But we don’t want climate deniers in a “climate ACTION” forum. They are only there to dilute and sabotage.. to side-track the discussion. A workshop is not interested in rhetoric from those who oppose their mission.
So the status quo of #Lemmy and #Kbin disservices activism.
Workaround 1 (Lemmy only):
Make an announcement community and make all participants a moderator. Bit crazy unless you really trust everyone involved.
Workaround 2 (Lemmy):
One community per instance using instance-specific registration control. Still too blunt, cumbersome, excludes mods who don’t have their own instance.
Question
Sometimes I click to subscribe to a community which then goes into a “subscription pending” state. What does that mean? As a moderator of some groups I never receive a signal that someone is requesting to subscribe.
BTW, the reason this enhancement request is not in the official bug trackers:
- Lemmy’s bug tracker is in MS Github (#deleteGithub)
- Kbin’s bug tracker is on codeberg, who silently deleted my account without warning or reason, and #Codeberg reg forces a graphical CAPTCHA (which fails on my non-graphical browser).
#lemmyBug #KbinBug
/cc @nutomic@lemmy.ml @ernest@kbin.social
Self hosting would mean I could control account creation and make many burner accounts. But there are issues with that:
I think it complicates the problem and then each author has to deal with the same. If it’s solved at the fedi API level, then the existing infrastructure is ready to work.
(edit) I recall hearing about a fedi client application that operates in a serverless way. I don’t recall the name of it and know little about how it works, but it is claimed to not depend on account creation on a server and it somehow has some immunity to federation politics. Maybe that thing could work but I would have to find it again. It’s never talked about and I wonder why that is.. maybe it does not work as advertised.