Private Communities

[Nutomic]

No description provided.

[grahhnt]

Rendered

[sunaurus]

Very nice, @Nutomic ! I have two suggestions:

1. If I understand correctly, you are proposing a binary private/public approach? It would be extremely useful to at least also have an in-between option: reading is public (everybody can see posts/comments/votes), but participating (adding new posts/comments/votes) is only allowed for users who have been accepted.

2. It would be awesome to allow mods to configure an instance allowlist, based on which follow requests could be automatically accepted. I think this is a very practical approach to reduce overhead of managing such communities, as there are many instances which already quite thoroughly vet their users with sign-up applications - mods might want to just default to always allow users from an instance like that.

[dessalines]

Overall this would be a great thing for lemmy to have. My main suggestions:

• Make sure your new table has an answer and a deny_reason field, just like the registration_application table. A random username applying to a private community needs to provide some context for why they want to join, otherwise the application process serves no point.
• The community table will also likely need an application_question column also.
• I'd prefer that this new table be called community_application or something like that.
• You'll be doing the apub work so its ultimately up to you, but you could probably just using the existing SubscribedType::pending for applications that haven't yet been approved.

[dessalines]

Instead of adding this table, we should just add a accepted_application to the community_follower table, or just not add any columns at all, and rely on the SubscribedType::pending for unapproved apps to private communities.

And I'd recommend that the new table is called community_application (this one's my fav), private_community_application, community_registration_application or something like that, and look almost like our existing registration_application table, with these columns:

• Answer, person_id, moderator_id (optional until acted upon), deny_reason (optional string)

[dessalines]

I'd say it is alright for accepted_application to be in community_follower , just like accepted_application is in local_user

[dessalines]

I couldn't find anything usable either.

[silverpill]

The micro-blogging part of the Fediverse uses manuallyApprovesFollowers property (boolean). It is not defined in AS vocabulary, and usually defined as {"manuallyApprovesFollowers": "as:manuallyApprovesFollowers"}. However, it is supported by most projects (including Mastodon).

[Nutomic]

That makes sense, Ive changed it. Only thing is that it doesnt give any indication that content in the group is private.

[silverpill]

Perhaps audience property can be used for that. as:Public would indicate a public or semi-private community.

Feels a bit awkward because audience is already used in FEP-1b12 objects.

[dessalines]

This is a good idea. Matrix has to deal with the same problem: as soon as 1 malicious instance gets access to the private room, they get all messages. Good to have warnings about that limitation.

[Nutomic]

@sunaurus

If I understand correctly, you are proposing a binary private/public approach? It would be extremely useful to at least also have an in-between option: reading is public (everybody can see posts/comments/votes), but participating (adding new posts/comments/votes) is only allowed for users who have been accepted.

This would partly overlap with the existing setting community.posting_restricted_to_mods. Do you have a specific use case in mind that isnt covered by it already?

It would be awesome to allow mods to configure an instance allowlist, based on which follow requests could be automatically accepted. I think this is a very practical approach to reduce overhead of managing such communities, as there are many instances which already quite thoroughly vet their users with sign-up applications - mods might want to just default to always allow users from an instance like that.

This could easily be handled by a bot or script. Id rather not add this much extra complexity, especially not in the initial implementation.

[Nutomic]

• You'll be doing the apub work so its ultimately up to you, but you could probably just using the existing SubscribedType::pending for applications that haven't yet been approved.

This is true, so we dont even need a new db table.

Overall this would be a great thing for lemmy to have. My main suggestions:

• Make sure your new table has an answer and a deny_reason field, just like the registration_application table. A random username applying to a private community needs to provide some context for why they want to join, otherwise the application process serves no point.

• The community table will also likely need an application_question column also.

• I'd prefer that this new table be called community_application or something like that.

The neat thing about joining private communities with a simple follow is that it should easily work with other Activitypub platforms. But including a reason field with Follow has no precedent afaik, and would require breaking changes in all platforms to support it. Plus it seems like bad UX when you have to enter a reason when following a community.

Anyway in most cases the user will have a profile and post history which should be enough to make a decision. If its a new user with no info, that alone should be enough reason to reject. However I can imagine when an application gets rejected the moderator can optionally enter a reason, and this gets shown to the user (federated as Reject). But that would require a new table again...

[dessalines]

Couldn't the reason field be an optional one, then it wouldn't be breaking.

But including a reason field with Follow has no precedent afaik, and would require breaking changes in all platforms to support it. Plus it seems like bad UX when you have to enter a reason when following a community.

I can think of a lot of examples here where a private community would want a reason for the follow. They might want screening questions, verification of identity, a "password" shared from another private platform to verify.

The only reason twitter / Masto doesn't have these cause they don't have private communities. FB has optional membership questions for their groups.

[sunaurus]

This would partly overlap with the existing setting community.posting_restricted_to_mods. Do you have a specific use case in mind that isnt covered by it already?

The use case is basically: a user wants to create a community which should be able to organically attract new members and grow (so the content should be visible to all Lemmy users to invite participation), BUT, the community creator wants to vet new members before they are able to post/comment/like stuff.

A few examples of where I think this would be useful:

• Any communities for minorities may want to use this option to show that they are active and welcome to new members, but still keep out potentially harmful content by requiring users to request to join first, perhaps by first requiring some application DM or introduction post in a separate community or something like this.
• There are entire instances which already more or less work like this (for example, Beehaw), except this model kind of breaks for them with federation (they can only vet local users currently, not remote users). If we had read-only private communities with follow requests to participate, then such instances could open up their communities to even wider federation, as they will still be able to control who participates in their communities.

[Nutomic]

@sunaurus Ive added that to the "Further work" section to not overcomplicate the initial implementation.

@dessalines Having a follow reason is just too much work considering that it isnt necessary for making private communities work. Lets keep it simple and we can consider adding more features once the initial implementation is working.

[dessalines]

Alright, as long as it can be extensibly added later.

[db0]

Another use case is in meta communities, in reddit /r/anarchism we had metanarchism which was meant to allow community org by known members, but we had to take it completely private because reddit wouldn't allow visibility without also votes and comments from anyone which we didn't want. A way to have a transparent decision-making community with only stakeholders allowed to vote and comment would be quite useful. I could hook up to bot into it for a some interesting automation