Add support for incoming dislikes #513
Conversation
BentiGorlich
added
enhancement
|
do you feel like this should have been blocked by #482 and should be reverted? CC: @e-five256 @nobodyatroot @asdfzdfj @andrewmoise @thepaperpilot @TheVillageGuy |
|
#515 will hide the dislikes, which is good enough for @e-five256 |
my personal opinion is slightly in favor of (temporary) of reverting this patch, but not because it should be blocked by #482: sure, the instance operator will be always able to see who voted what, anyone who's crazed and persistent enough on wanting to see this information will try to find a way to do it, and with the way software and AP works you will need to store that action one way or another, but combined that with this patch will turn mbin instance (especially active ones) into a looking glass for dislikes that's far easier to use to see that information, rather than having to setup their own instance, get it to federate and then muck around in the instance database in order to get the same information. granted, from what I could see the handling of dislikes in fediverse is a little bit of an uncharted territory, and the only example of serious use of it as of now seems to be lemmy, and they opted to expose likes/dislikes as just a simple counter value. with us suddenly exposing this data in a more detailed manner and easier to access will definitely results in some repercussions with all that said, removing the detailed user dislike listing from the activity page everywhere is good enough for me, just displays it as a simple counter and leave it at that, no need to remove the entire reduces section from the activity bar (so you'd still have |
|
agree with @asdfzdfj, or another possible solution: just remove the activity bar entirely and keep the counts, no idea why we need to see who is upvoting, boosting, or downvoting anything.... just make them counters. |
my main motivation to still keep the likes/boosts listing is because other fediverse software (at least the microblog section) is often capable of showing those listings (even briefly), and so I'l like to keep it for consistency with other softwares |
|
My 2c is that security through obscurity in terms of showing likes / dislikes is a bad idea. I would actually vote for going the other way, having a dialog box that pops up the first time someone likes or dislikes something that warns them that all votes are public, that they have to explicitly choose not to show again. The disconnect in terms of people's expectations of privacy on voting is definitely a bad thing, but the solution is to make sure people know their votes aren't private, not to feed into the pretense that they are. They're not. It's only a matter of time before someone constructs an easily available see-who-downvoted-you tool similar to the see-deleted-content-on-reddit tool or the who-unfriended-you-on-Facebook tool. |
|
I agree about the "someone will make a tool that displays this anyway" part, however I think the accessibility of this data is something to consider. Just because there is a tool that can do it (or in our case: there will be a tool) doesn't mean that people will use that tool or know about it. I think I like the "show the numbers, don't show who explicitly" way. I would actually agree with @nobodyatroot and just don't show who did what at all, but I'd do the minimum change for this |
Agreed as well. However I don't know how to get that into peoples' mind. Showing a popup every time anyone does anything is certainly not a good option 😅 |
I do agree on the "security through obscurity in terms of showing likes / dislikes is a bad idea" part, and actually your suggestion isn't mutually exclusive with what I personally wanted to see (why not both?), it's that I feel like just because this data is public it doesn't mean it needs to be laid bare for everyone to easily see, if some crazed nutjobs want to have a dislike looking glass I at least want them to go out of their way dig it up, instead of just simply switching to maybe fedia and simply looked it up from fedia's copy of the post. don't make it easy, as I said. |
|
Wanted to make sure to include some opinions publicly and not just in matrix There has been a lot of discussion around this, some from the past can be found here https://codeberg.org/Kbin/kbin-core/issues/455 My opinion is that people have raised valid concerns over safety and privacy that warrant taking these measures for the time being. Personally, I didn't mind the idea of my own being public, but I'm not going to ignore the concerns put forth by community members That's why, for a first pass, my opinion was to just match what everyone (the vast majority of the threadiverse) has accepted as normal, federated and not shown to the public. Looking ahead, I'd rather decide what the valid use cases are. To be very specific, the reason why I would've liked to see them isn't because I want individual names, but due to down vote brigading (as a means to empower the user to take that info to an instance admin and say, look, this is what another instance is doing). However, there might be ways to have that without names. I had brainstormed, well what if we just showed a rollup of instance name sources rather than individual names. But of course, that unfairly punishes small, and specifically single-user, instances to where it becomes obvious who is doing it, so I threw that idea out. It sort of seems like a lose-lose to me, I'm definitely seeing people say they want all info to be public, and as you can see in that kbin issue, there are those who are vehemently against it. I think going with this is the safest approach for now as it seems to have been accepted by people, but if there are ideas in the future to improve it, I know we've discussed things like encrypted voting, if we could get something like that in ActivityPub, perhaps the concerns could be addressed. |
|
I think it's important to note if they are federated non anonymously, bad actors can and absolutely will expose that information publicly. That's something to keep in mind. Personally I'm of the opinion of keeping downvotes fully anonymous. Showing the downvotes per instance to admins sounds fine because that information would already be visible to bad actors anyways, so the fact it de-anonymizes small instances' downvoters to admins is not much of a concern to me |
|
Well that is not possible. We removed the option to view who disliked a post, but you cannot just accept anonymous dislikes from a remote instance... |
|
How do y'all feel about the popup to warn people that their votes are not private, whether or not mbin specifically is exposing them? That being a good idea is pretty much the only part of the debate that I think is an obvious right answer. I'm happy to do the PR for it. My feeling would be for it to show until dismissed ("don't show again") -- not for the sake that we need to pop it up every single time, but it's worth making fairly sure that the user actually has seen and read it to give the best chance of letting them know successfully what's going on. |
|
Might be worth spinning up another issue or discussing some quick ideas in matrix for that (I know Benti has mentioned it might be a bit early to do tutorials if we end up reorganizing a lot, I especially feel bad it we add translations that people contribute to and they end up being removed. But maybe there's other options like linking to pages that have this information (I just checked fedi tips, for instance, goes over lack of E2EE for DMs but not for likes/boosts, but maybe there's info elsewhere)) Didn't mean to completely bump this issue, but saw it was being linked and discussed a lot and that I hadn't made my position clear |
|
Haven't been following this discussion at all so this has probably already
been suggested. Place a warning on the privacy policy page
…On Thu, 7 Mar 2024, 23:44 andrewmoise, ***@***.***> wrote:
How do y'all feel about the popup to warn people that their votes are not
private, whether or not mbin specifically is exposing them?
That being a good idea is pretty much the only part of the debate that I
think is an obvious right answer. I'm happy to do the PR for it. My feeling
would be for it to show until dismissed ("don't show again") -- not for the
sake that we need to pop it up every single time, but it's worth making
fairly sure that the user actually has seen and read it to give the best
chance of letting them know successfully what's going on.
—
Reply to this email directly, view it on GitHub
<#513 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALKLYOB2TAL4WVWHVMLXOXLYXDUVVAVCNFSM6AAAAABDR4CW6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBUGY4TCNJSHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No description provided.