Add community vote settings (fixes #5360)

[Nutomic]

TODO:

• Adjust create/edit site forms
• Make the setting federate
• Add comments

[dessalines]

All the logical changes in here, especially removing the item type, and vote type, need to be reverted.

The original reason for this functionality, was that some sites might want to disable all voting entirely, or only disable votes for posts (or comments), or only allow them under certain federation modes. This removes the ability for instances to do that.

There's also good reasons why a site (or community) might only want to allow upvotes to a certain mode (IE local).

I think the best way forward might just be to dupe the existing site vote settings over to community, and on making new communities, copy the existing site vote settings over initially, but let communities tweak them. And maybe rename the site settings default_post_... . This would let communities override the site settings, but still use them as a default / suggestion.

[Nutomic]

As these settings dont need to be federated, they can actually be implemented as a plugin which is very much preferable. A plugin is much more flexible, for example it can be configured to allow downvotes only from a specific set of instances, or reject votes from users that havent posted before. Additionally plugins are much easier to change and its not necessary to make a new Lemmy release each time.

Have a look at the example plugin here: https://github.com/LemmyNet/lemmy-plugins/blob/master/plugins/rust_allowed_voters/src/lib.rs

[dessalines]

I don't like the idea of moving what should be core functionality (whether to allow upvotes and downvotes on certain items), to plugins. There are some pretty large existing lemmy sites who like the ability to disable downvotes, and I'd rather not try to move that to a plugin people have to add and configure.

We should of course keep those plugin abilities, but it shouldn't replace these settings IMO.

If we did my suggestion above : copy the local site vote settings for any new communities created, it would solve the federation issue.

[Nutomic]

This is by no means a core feature because it can be implemented very easily in a plugin. Core features are things that cant be implemented as plugins, for example things that federate or new API endpoints. I have updated the existing allowed_votes plugin to add these same voting modes (LemmyNet/lemmy-plugins#11). As you can see it can even do much more, like rejecting votes from users who made less than x posts in total.

Whether the functionality is implemented as a plugin or directly in Lemmy, it always needs to be configured. For now the plugin config may be a bit difficult because its done in the config file, but it will be much easier when #6487 is implemented. And then we can easily have a page in lemmy-ui to add plugins and set parameters. That way not every little thing has to become a core feature, plus it will be much more flexible. For example you could easily implement a downvote allowlist, so that only users from specific instances can downvote posts. And then deploy it immediately, without waiting for a new Lemmy release.

[dessalines]

We should always prefer integrating things into lemmy's core over plugins. Plugins might be more configurable, but they're a power user feature.

Admins are just going to want to click a button to set their voting modes, whether ppl can upvote or downvote, and on what items. This should be a core part of lemmy, as I already did the work for this already.

Your plugin should account for the 4 settings: post upvote, post downvote, comment upvote, comment downvote.

[dessalines]

Another thing I realized: these vote settings must come back with GetSite anyway, because UI elements have to be hidden based on them. I already did all the work for this in the front end.

[Nutomic]

Okay I restored the LocalSite settings in order to avoid breaking changes. Still, if people ask for more vote settings in the future (or settings for post/comment permissions), these should be implemented in plugins. Not everything related to votes or posts can be a core feature, and we cant support hundreds of LocalSite settings.

It is absolutely possible to return plugin settings from LocalSite by adding a plugin hook there, and changing the frontend behaviour based on that. Doing that will require some extra work, but also result in more flexibility.

[dessalines]

I don't think its a good idea to add a new and conflicting enum.

I'd recommend:

• Adding a Subscribed option to the existing FederationMode enum.
• Rename the 4 local site vote federation mode columns to default_...
• Copy those 4 local site vote federation mode columns, to the community table.
• On new community creation, copy the defaults from the local site settings, to the community.
• Allow community mods to save those settings for their communities.
• In front ends, we'll then use the community vote settings.

[Nutomic]

Using the same enum for both makes sense, I'm changing that now.

But adding these 4 separate vote settings for communities does not make much sense. No one will disable post upvotes, because then community posts wont show in any feeds, so it becomes undiscoverable and dead. For comment upvotes its similar. If someone doesnt want any votes, they should use NodeBB instead. We can make it possible to disable comment downvotes, either with a single setting that covers both posts and comments, or separate settings for each.

Regarding LocalSite columns, I reverted those changes to avoid breaking API changes. If we do change them, it should reflect the expected usage. Specifically that disabling upvotes is pointless, so these two settings should go then.

[dessalines]

Specifically that disabling upvotes is pointless, so these two settings should go then.

There's some other possibilies for the upvote settings:

• A given site or community might only want to allow upvotes from subscribers or local users only. For example, a poll-type community might only want their own users to be able to upvote posts or comments within that community.
• A lemmy instance might want to be run like a forum / NodeBB, and not have any voting. IMO it should be possible to disable them, because lemmy might have features that other platforms don't.

[Nutomic]

Is there any issue for these requests? I dont see any reason to implement features that someone might want. Because then we can implement thousands of new features that no one will actually use.

For using Lemmy as a forum there was https://github.com/LemmyNet/lemmyBB and no one was interested in using it. So lets focus on the core use case for Lemmy, not on niches that no one actually cares about.

[dessalines]

Oh BTW if possible please avoid force pushing. It makes it so that I have to re-review every file I already have, and I can't see specifically what changed.

[dessalines]

In addition to adding the 4 settings, I'd also recommend changing the local_site vote setting names to default_...

[dessalines]

I don't see where these are being copied over from the local site vote settings, which is critical. See here

[Nutomic]

Fixed. Also renamed to community.post_downvote_mode to clarify it, and potentially add other settings later.