WIP Implement downvote modes

[thepaperpilot]

This is a WIP PR, but I've been struggling to find time to complete it. Really it's down to just testing to make sure it works everywhere and that I didn't miss any API endpoints or anything. I'm also wondering if there's anything we should do to communicate to other servers if we support downvotes or not (I don't think AP has a standard for that though - perhaps something to discuss with the lemmy devs?)

I'd appreciate help from the community to get this PR ready to merge, if possible. I believe there was also an issue with it not loading the setting correctly from the DB, but my dev environment isn't playing nice so I can't even look at that right now (but I'll try to restore my dev environment when I do have time).

Closes #482

[asdfzdfj]

Can I get some description on what the problem is and what your plan/solution/goal for this is?

while I can sort of guess what it's supposed to do (add 3 modes of handling dislikes: process as normal, process but don't show, discards them entirely), but having a concrete description/spec/goal would help greatly in getting it working, and also avoids misunderstanding on what the goals are for other contributors

---

if there's anything we should do to communicate to other servers if we support downvotes or not

as for that, I think a good place to start would be to add this info as a nodeinfo metadata field, and discuss these new fields with lemmy and other threadiverse implementors that use dislikes for an agreement in field name and meaning/semantics

perhaps it could look like this:

{
  // ...
  "metadata": {
    // whether the instance process Dislikes (downvotes) at all
    "enableDislike": true,
    // whether the instance is willing to disclose/publish known dislikes, possibly optional
    "publishDislike": true,
  }
}

[e-five256]

Just for a bit of context, I had mentioned trying to assist with this (but think your clarifying questions are useful and don't want to answer in @thepaperpilot's place if there's time)

[thepaperpilot]

That metadata field looks reasonable to me 👍

And yes, that's the general idea behind this PR. I'll write some basic user stories to better define the goals with the PR:

• As an admin, I want to be able to, at will and without downtime, switch between downvote modes.
• As an admin, I want there to be a downvote mode where downvotes are enabled, counts are shown, and they affect relevant sorting algorithms.
• As an admin, I want there to be a downvote mode where downvotes are enabled and affect relevant algorithms, but hides counts. Users should have no way of accessing those counts, including using the API directly or by getting a combined score count or a list of users who've interacted with the post, since those can be used to calculate the downvotes score. (side note, this is what I plan on having my instance use)
• As an admin, I want there to be a downvote mode where downvotes are completely disabled.
• As an admin, I want federated servers to respect my site's downvotes mode - don't accept downvotes if they're disabled, and don't send downvote counts to other servers if they're not shown to local users.
• As a user, I do not want to see a downvote button if downvotes are disabled.
• As a user, I do not want to see a downvote count if those are hidden (e.g. don't show "missing info", question marks, or any other placeholder value - the text field should be completely gone)

And as for required work I'm hoping (and grateful) to get help with:

• Fixing the issue where the setting either isn't loading correctly (I've verified its saving correctly by checking the DB), instead just using the default value
• Testing the API endpoints to ensure there's no leaked counts anywhere when there shouldn't be

[thepaperpilot]

As for the inter-server communication about the handling, I just realized it'd probably make sense to keep it open enough for future implementations that are more finely grained to work. In theory, communities or even individual thread creators might want to disable downvotes without affecting the rest of the site. Regardless, I think dealing with that is OOS for this PR, and is something that should be discussed with input from other threadiverse apps, like you suggested.

[github-actions]

This PR is stale because it has been open 40 days with no activity.

[github-actions]

This PR is stale because it has been open 40 days with no activity.

[BentiGorlich]

I am guessing that I will close this PR, as I cannot push to the branch of thepaperpilots repo. So I'll create a new branch in our repo and make a PR for it

[thepaperpilot]

I am guessing that I will close this PR, as I cannot push to the branch of thepaperpilots repo. So I'll create a new branch in our repo and make a PR for it

When you do, can you mention this pr or link to the new one here? I'd like to follow it

[BentiGorlich]

Of course. I wouldn't use your code without linking back to you :)

[BentiGorlich]

Closed in favor of #1022