I would be against this. I feel like there's other ways to avert vote manipulation and most users generally upvote things more than downvote.

@MarkMoretto This is not meant for averting vote manipulation, this is primarily so that user who don't wish to view down-votes or partake in down-voting content at all, have the option to toggle this as they wish.

I think this is a good idea. It gives an option to those who don't want to be primed by vote counts in any way. Although I suspect the actual number of users who'd ever use this feature would be in an extreme minority.

Regarding the implementation, though, I think it's best to store the state of the preference server side (in the DB), instead of in localStorage, because those who'd use this feature would most likely use it on all the devices that they're using to access the site.

Sounds good, I'll make the required changes

@previnder now it make use of the DB for the user setting, also fixed feature not being used on comments

Is this a new field that will need to be added to the API documentation?

@previnder Is there versioning implemented for the platform so that every change like this won't impact packages that might utilize the API and have structured objects to do so?

I'll make a PR for updating the API docs once this gets deployed or merged. Also, the API is not versioned however this feature would be more like an addon to the UI rather than a breaking change and needing 3rd-party developers to update their application/software. However, I do think possibly preparing for versioning of the API would be nice to have, lastly on the structured objects it shouldn't break anything as those normally just map the response from the API to a struct or interface so if something was added to the API it shouldn't break something like that - just wanted to throw in my thoughts on it

@Codycody31 That was fast. This looks good for merging. (Though earlier I misunderstood the feature. I thought it hid all vote counts. But no matter; some users would find this useful as well.)

@MarkMoretto There's no versioning at the moment. In this case, though, I don't think it'd break anyone's code relying on the API, since the PR's only adding a field to an API object. Most (I think all) the JSON to structured object functions I've seen in the languages I've worked with ignore the extra fields not defined in the object.

That sounds good, also on what @MarkMoretto was talking about regarding the displaying of votes on posts and whether it should truly hide the downvotes I wanted to get your thoughts on it @previnder, you can find it here: 6367975, though someone could always make a PR or issue if they feel it should be displayed a different way

I'm curious to see how many users would use this feature. Because if anyone's dismayed by downvotes, then presumably they're dismayed by the fact that other people can and will downvote things they post sometimes. And they must know that hiding the downvotes doesn't really make them go away.

Same, I know we may have ~5-10 people who would use it (from looking at one of AW's posts), I personally would. I think it's more about them just not wanting to see it, as I know people can react strongly to negativity even if it's warranted, or whatever other reason they may have