ajayyy / SponsorBlock

Skip YouTube video sponsors (browser extension)
https://sponsor.ajay.app
GNU General Public License v3.0
9.78k stars 316 forks source link

Let's make Dislikes visible (Crowd sourced rating system) #1039

Closed WeslyG closed 2 years ago

WeslyG commented 2 years ago

https://www.theverge.com/2021/11/10/22773299/youtube-dislike-button-hide-public-count-numbers-small-creator-protection

Today I found out that YouTube is going to disable the public display of dislikes. I think this is an unfair and destructive decision. It seems to me that I am not the only one judging by many videos (most often educational) by the number of dislikes on them. The sponsorblock community is huge, and it seems to be the best place today to add a dislike button right here.

Yes, I understand that this is not the direct functionality of sponsorblock, but it seems unjustified to make another application for these purposes.

What do you think about it?

ajayyy commented 2 years ago

Still not really sure about it as it might attract abuse to the anonymous userID system

ajayyy commented 2 years ago

I think if this were to be a serious feature, it would need to be more powerful than like/dislike. We would need to define some categories of content to label it as. I feel that would actually be useful and be more inline with the extension

ajayyy commented 2 years ago

It could be combined with full video sponsor/self promo reporting as another category

usermyname12 commented 2 years ago

Maybe we can add an estimation. ((likes+views/100)/views1500) i've tested it and it works ok* on videos with average views. It overvalues the good ones but it definitely catches the bad ones (unless it is very popular or small). If we can tweak the 100 above so more views=smaller that number then it can be useful to big videos as well.

ShadowTheAge commented 2 years ago

This is not the functionality of this app, but the app for likes/dislikes must be popular to work, so this one seems appropriate. Maybe show in-app likes/dislikes for everyone but require authentication to post a like/dislike. (A non-binary "like/dislike" will be better but not a priority)

ajayyy commented 2 years ago

I've thought about this more, and think this should be split off to a separate but connected project. It can use the same backend (SponsorBlockServer), but have different extension front-ends.

SponsorBlock: Fixing the experience of watching videos on YouTube (things with clear answers)

New Extension: Finding and labeling the things you actually want to see (the vote-based multiple-answer stuff)

I think SponsorBlock should remain only with things that have one answer, and not things where a voting % is more useful. This new project is much more risky, and I don't want it to drag down SponsorBlock.

There are other advantages to launching it as a new extension such as being able to work on all sites instead of just YouTube, which doesn't work with the permissions SponsorBlock has.

It is still possible get the advantage of SponsorBlock's userbase by telling people about it if they click the dislike button.

Thoughts?

(More discussion also on #dislikes on Discord and Matrix)

CarrotIsACarrot commented 2 years ago

it good 👍‍

mat926 commented 2 years ago

Someone should create an independent dislike database + browser extension that will work on the same principle as SponsorBlock. It might be even possible to fetch and archive the current dislike counts, since API should remain working till December 13th.

TheMajor-GitHub commented 2 years ago

I've thought about this more, and think this should be split off to a separate but connected project. It can use the same backend (SponsorBlockServer), but have different extension front-ends.

SponsorBlock: Fixing the experience of watching videos on YouTube (things with clear answers)

* Removing as much advertisement from videos as possible

* Skipping to the part of the video you want to see

* Labeling entire videos as ads/self promo (that still should be in SponsorBlock)

* (Coming very soon) crowdsourced chapters

* (Potential Future) relabeling titles and thumbnails to more useful information

* (Potential Future) tl;dr and other one-answer crowd-sourced things

New Extension: Finding and labeling the things you actually want to see (the vote-based multiple-answer stuff)

* A custom like/dislike system

* A system to report videos as containing specific categories of subjecting information (incorrect info, misleading, etc.)

* (Potential future) filtering for the videos you actually will care about based off crowdsourced data

I think SponsorBlock should remain only with things that have one answer, and not things where a voting % is more useful. This new project is much more risky, and I don't want it to drag down SponsorBlock.

There are other advantages to launching it as a new extension such as being able to work on all sites instead of just YouTube, which doesn't work with the permissions SponsorBlock has.

It is still possible get the advantage of SponsorBlock's userbase by telling people about it if they click the dislike button.

Thoughts?

(More discussion also on #dislikes on Discord and Matrix)

This seems to make the most sense. A seperate extention that somehow still makes use of the SponsorBlock platform and it's popularity without directly affecting it.

I also really like the idea of being able to "label" a video, this would be exceptionally useful for labeling videos that are clickbait, fake news, toxic. I don't know how the ui would look, but perhaps you could click a drop down menu with a selection of buttons, each one representing what the content of the video might contain, then have the most clicked buttons appear under the video, or something like that.

Ultimately I'm not a software designer so you will know the best way to implement these features, but I do think these features are very useful and an extention like this could be very popular, especially if it's somehow able to piggyback off SponsorBlock and it's popularity somehow.

BlackSails7 commented 2 years ago

In my opinion, If it works with SponsorBlock, I'd say add it there with an option to disable it. If it doesn't work properly, (because users would be able to login with multiple accounts and add tons of fake likes/dislikes) then create a new add-on which requires more permissions to prevent that.

Edit: however consider the possibility that mozilla will remove your add-on. So probably best to create a new separate one!

"A system to report videos as containing specific categories of subjecting information (incorrect info, misleading, etc.)"

but this is based on each person's (objective) opinion. You can literally label incorrect info/misleading ANYTHING you disagree with. So is it really useful? Most people are not rational. They are religious in so many ways. Anything that threatens their beliefs they automatically label as misinformation or misleading.

Another thing I should add is that we should be able to see the likes/dislikes bar from the thumbnails of the videos BEFORE clicking to watch them. There are scripts and add-ons which did this (until now).

https://greasyfork.org/en/scripts/30254-youtube-ratingbars-like-dislike-rating https://addons.mozilla.org/en-US/firefox/addon/youtube-thumbnail-rating-bar

I think adding the likes/dislikes right NOW is what needs to be done(because everyone is thinking about it now) The add-on can be updated later to add other features.

The like/dislike button-icons must be both dark and white theme friendly. Should be the same as the ones youtube uses probably, so that people are already used to them!

Rjevski commented 2 years ago

Fixing the experience of watching videos on YouTube (things with clear answers)

I'd argue that being able to dislike and see dislikes is a "fix" for the experience.

Whether those dislikes are accurate or not shouldn't really be SponsorBlock's responsibility (the YT ones aren't either; Google is absolutely incompetent at filtering out spam/bots and even then, human click farms can be hired for cheap).

I don't think "diluting" the SponsorBlock userbase is a good idea with two extensions. The extension needs network effects to work so the more users have it installed the better. It's also good for the user experience; I'd argue that seeing dislikes and blocking sponsored trash is both in the interests of the user and if they want one they'd like appreciate the other, so having both in a single & easy to install extension would be my preference.

TheMajor-GitHub commented 2 years ago

Fixing the experience of watching videos on YouTube (things with clear answers)

I'd argue that being able to dislike and see dislikes is a "fix" for the experience.

Whether those dislikes are accurate or not shouldn't really be SponsorBlock's responsibility (the YT ones aren't either; Google is absolutely incompetent at filtering out spam/bots and even then, human click farms can be hired for cheap).

I don't think "diluting" the SponsorBlock userbase is a good idea with two extensions. The extension needs network effects to work so the more users have it installed the better. It's also good for the user experience; I'd argue that seeing dislikes and blocking sponsored trash is both in the interests of the user and if they want one they'd like appreciate the other, so having both in a single & easy to install extension would be my preference.

I somewhat agree with this. But then it becomes a matter of trying to merge these two features in a way that doesn't detract from the core aspect of sponsorblock and what it is primarily used for as a tool.

BlackSails7 commented 2 years ago

apparently dislikes are visible if you are not logged in?!

dubesor commented 2 years ago

Maybe we can add an estimation. ((likes+views/100)/views*1500) i've tested it and it works ok on videos with average views. It overvalues the good ones but it definitely catches the bad ones (unless it is very popular or small). If we can tweak the 100 above so more views=smaller that number then it can be useful to big videos as well.

spits out completely false and random results. I checked on my videos and 98% liked videos became 14% etc with your formula. Engagement needs to be included for that you only have comments, which can get deleted. So, there is no way with the accessible data to determine like/dislike ratio.

As for including an own upvote/downvote system I disagree because it's not within scope of the extension, nor the extension name. I can already see an endless set of youtube related features being added over time totally alienating what the extension set out to do initially (feature creep).

TheMajor-GitHub commented 2 years ago

but this is based on each person's (objective) opinion. You can literally label incorrect info/misleading ANYTHING you disagree with. So is it really useful? Most people are not rational. They are religious in so many ways. Anything that threatens their beliefs they automatically label as misinformation or misleading.

One way we can avoid potential bias is by having the most clicked on labels appear higher on the list with greater percentages. For example; Clickbait: 98%, fake news 89% Misleading 80% etc. Then a viewer can decide for themselves if they want to trust those figures or keep watching.

mat926 commented 2 years ago

but this is based on each person's (objective) opinion. You can literally label incorrect info/misleading ANYTHING you disagree with. So is it really useful? Most people are not rational. They are religious in so many ways. Anything that threatens their beliefs they automatically label as misinformation or misleading.

One way we can avoid potential bias is by having the most clicked on labels appear higher on the list with greater percentages. For example; Clickbait: 98%, fake news 89% Misleading 80% etc. Then a viewer can decide for themselves if they want to trust those figures or keep watching.

How would this work if it were political commercials and rallies? The viewer would just watch it anyway and not care for the labels.

TheMajor-GitHub commented 2 years ago

How would this work if it were political commercials and rallies? The viewer would just watch it anyway and not care for the labels.

What's the problem here?

ajayyy commented 2 years ago

Non-binding name brainstorm (No sneed please): https://pollunit.com/en/polls/bx80e7zrqfanagkhr2sl5w (you can add options)

Anarios commented 2 years ago

Someone should create an independent dislike database + browser extension that will work on the same principle as SponsorBlock. It might be even possible to fetch and archive the current dislike counts, since API should remain working till December 13th.

That's the idea behind my project - http://returnyoutubedislike.com/

Chrome\Firefox extension, and a DB behind it (currently scraping youtube API to save as much data as possible)

Volunteer creators could log in into extension to disclose their channel's dislike counts.

Integration with SponsorBlock and\or YoutubeVanced, and any other related project would be awesome.

BlackSails7 commented 2 years ago

Someone should create an independent dislike database + browser extension that will work on the same principle as SponsorBlock. It might be even possible to fetch and archive the current dislike counts, since API should remain working till December 13th.

That's the idea behind my project - http://returnyoutubedislike.com/

Chrome\Firefox extension, and a DB behind it (currently scraping youtube API to save as much data as possible)

Volunteer creators could log in into extension to disclose their channel's dislike counts.

Integration with SponsorBlock and\or YoutubeVanced, and any other related project would be awesome.

Yeah, it's good to have both. Thanks for your work, but could you bring the like/dislike ratio bar back, and also make it visible from the thumbnails? There are some scripts/addons which used to work (I linked* them before on my other comment) https://greasyfork.org/en/scripts/30254-youtube-ratingbars-like-dislike-rating https://addons.mozilla.org/en-US/firefox/addon/youtube-thumbnail-rating-bar

But who knows for how long your addon/script will work. Especially if it got popular.. youtube would find a way to disable it.

We absolutely need an independent system. This way channels will no longer have the power to hide their video ratings.

We also need independent comments tbh. Too many people have begun disabling comments sections. And deleting comments that hurts them and exposes them.

ajayyy commented 2 years ago

An idea brought about in discussion in Discord:

Instead of having upvote and downvote, have positive and negative report options. Then, these options can be displayed in a bar with colours, similar to GitHub languages. There can be a seperator in the middle to seperate the "positive" side from the "negative" side.

image

I think this will be a lot more flexible, while still giving us the positive/negative ratio for quick glances.

GitHub UI for reference: image

TheMajor-GitHub commented 2 years ago

An idea brought about in discussion in Discord:

Instead of having upvote and downvote, have positive and negative report options. Then, these options can be displayed in a bar with colours, similar to GitHub languages. There can be a seperator in the middle to seperate the "positive" side from the "negative" side.

image

I think this will be a lot more flexible, while still giving us the positive/negative ratio for quick glances.

GitHub UI for reference: image

I'm on the fence about this one. Do you mean a sliding scale with multiple options such as "slightly dislike", "dislike", "slightly like", and "like"? As someone who doesn't use Github for pretty much anything other than what I'm doing now, and the fact that most add-on users are probably the same, I'm not really sure how much of a hit this would be aesthetically.

BlackSails7 commented 2 years ago

An idea brought about in discussion in Discord:

Instead of having upvote and downvote, have positive and negative report options. Then, these options can be displayed in a bar with colours, similar to GitHub languages. There can be a seperator in the middle to seperate the "positive" side from the "negative" side.

image

I think this will be a lot more flexible, while still giving us the positive/negative ratio for quick glances.

GitHub UI for reference: image

I think you could add this as an option (in addon settings) for anyone who wants it. But by default it should be the basic like/dislike in my opinion. So I think we can have both. Most people want the simple like/dislike, this is what we are all used to. For the rest of users who want more details, they can enable that bar in settings, and also this would give them more flexibility when they rate videos.

But it depends on what the options in that bar would be. If it's just "partially dislike", "dislike", "partially like", "like" then you can sum all the negative ones into the dislikes, and all the positives into the likes. (for those who don't use the bar)

If the bar has options for labels (scam/misleading/useful/etc)... then can you have both? I guess maybe if you sum all the negative ones into the "dislike" and the positives into the like (for those who don't use the bar)

Its a good idea, my only problem is that it's probably not convenient. Because when you only have like/dislike it's just 1 click. When you have too many options you cant even decide what to choose, because most of the time it's multiple of them.

I simply don't know. It's just something we need to test out first. Like/dislikes we already know how it works.

ajayyy commented 2 years ago

No, not slightly dislike. It would be positive and negative reasons (misleading, scam, useful, etc.) since like/dislike is can be pretty meaningless

TheMajor-GitHub commented 2 years ago

No, not slightly dislike. It would be positive and negative reasons (misleading, scam, useful, etc.) since like/dislike is can be pretty meaningless

That does make more sense, and I see what you mean now. Like or disliking something based on a reason. That sounds pretty smart. My only suggestion there would be to keep the feature as simple as possible so that it doesn't use much memory.

BlackSails7 commented 2 years ago

What about a simple like/dislike system, but when you click like or dislike, it would require a reason by popping up a small panel above the buttons.

Then when people hover the bar under these 2 buttons (like/dislike) it would show the labels with different colors and when you hover them it would display the text.

But what if you simply like a video because you agree with it (a video that you wouldn't necessarily call "useful" or "interesting") Or what if the video is simply "funny"? I guess we would need many labels to choose from.

Labels I can think of for the like button : [like, useful, interesting, unreal, exciting, funny] Labels for the dislike button: [dislike, misleading title, scam, annoying, harmful, propaganda]

So the buttons would be a simple like/dislike, but when you click each, it would popup a horizontal panel above with these options (like a context menu, same as it is on 'messenger reactions' but with text not emojis) and these would appear in a ratio bar bellow the like/dislike buttons like it is on Github like you said. So that's a possible idea.

btw the addon should not be removing youtube's likes/dislikes (or at least have the option to keep them)

TrashAccount3424 commented 2 years ago

Someone is trying to do this here https://github.com/pgamerx/yt-dislikes-viewer/issues/6 Maybe join forces?

pgamerx commented 2 years ago

Someone is trying to do this here https://github.com/pgamerx/yt-dislikes-viewer/issues/6 Maybe join forces?

Hi, I have been working on the API for this that will allow us to make a POST request that adds certain data to the database. For eg- ?video_id=69&action=dislike/like. If SponsorBlock actually is ready to integrate with the api, I will change the API as per the above comments. The API will also be able to get the data using GET request which will return a JSON object.

As far as storage is concerned, this API is currently on replit and I am using sqlite,but I do have a VPS where I decided to host it once it's fully complete. We can try to store data in the shortest form possible instead of strings.

pgamerx commented 2 years ago

The main problem for me was Oauth because I cannot just allow the endpoint to be always accessed and restrict it to signed-in users only.

ajayyy commented 2 years ago

@pgamerx The basic API should be working https://wiki.sponsor.ajay.app/w/API_Docs/Ratings

I haven't added the voting reasons (misleading, educational, funny, etc.) I talked about earlier, but those changes will be backwards compatible.

SponsorBlock doesn't use Oauth, but instead uses a randomly generated userID (https://wiki.sponsor.ajay.app/w/API_Docs#Local_userID_vs_Public_userID).

pgamerx commented 2 years ago

@pgamerx The basic API should be working https://wiki.sponsor.ajay.app/w/API_Docs/Ratings

I haven't added the voting reasons (misleading, educational, funny, etc.) I talked about earlier, but those changes will be backwards compatible.

SponsorBlock doesn't use OAuth but instead uses a randomly generated userID (https://wiki.sponsor.ajay.app/w/API_Docs#Local_userID_vs_Public_userID).

That's amazing, one more question - What if someone writes a script that keeps on generating random userIDs and spams the API for a targeted dislike/like (downvote/upvote) attack on a certain video?

I have another idea, What if we use the Google Oauth string thingy that is returned to us when we use Google API to make someone sign in to anything? This will increase the work and extra preventive measures would be required to safeguard users because the String can give anyone access to the account.

pgamerx commented 2 years ago

Or am I interpreting this wrongly and the user ID can only be generated locally from the "SponsorBlock" extension and not anywhere else?

TrashAccount3424 commented 2 years ago

@pgamerx If the end-user has to sign-in its rendered useless for a huge portion of user. People dont want a public database that shows what they liked/disliked and a lot also dont want to login to google.

ajayyy commented 2 years ago

I don't want to use Google accounts for privacy reasons.

The current protection is via IP-based ratelimiting.

There are many ways to still have our own filtering system though. In future, there could be a reputation value calculated with how many reports align with older users to not display votes from new users until they reach that threshold. Would be tricky to figure out the right balance for it, but I highly doubt this will be a needed since voting does not affect someone's discoverability (unlike social media), so there is little incentive to abuse it.

SponsorBlock has never had a problem with bot users abusing the API.

TrashAccount3424 commented 2 years ago

Or am I interpreting this wrongly and the user ID can only be generated locally from the "SponsorBlock" extension and not anywhere else?

I think different user ID from the same IP are simply discarded

pgamerx commented 2 years ago

@pgamerx If the end-user has to sign in it's rendered useless for a huge portion of users. People don't want a public database that shows what they liked/disliked and a lot also don't want to log in to google.

Then maybe we should add a preventive measure for this, like go generate A Public User ID, you need to use an Authorization key to make sure we know if the script sending the request is a spam script or a legit one.

The Authorization key should not be provided to everyone but only those who applied through a form and got accepted.

pgamerx commented 2 years ago

Or am I interpreting this wrongly and the user ID can only be generated locally from the "SponsorBlock" extension and not anywhere else?

I think different user ID from the same IP are simply discarded

What if they use multiple proxies?

TrashAccount3424 commented 2 years ago

@pgamerx If the end-user has to sign in it's rendered useless for a huge portion of users. People don't want a public database that shows what they liked/disliked and a lot also don't want to log in to google.

Then maybe we should add a preventive measure for this, like go generate A Public User ID, you need to use an Authorization key to make sure we know if the script sending the request is a spam script or a legit one.

The Authorization key should not be provided to everyone but only those who applied through a form and got accepted.

Would need manual review of thousands of users that's not really practical and a spammer could submit the from automated anyway.

pgamerx commented 2 years ago

@pgamerx If the end-user has to sign in it's rendered useless for a huge portion of users. People don't want a public database that shows what they liked/disliked and a lot also don't want to log in to google.

Then maybe we should add a preventive measure for this, like go generate A Public User ID, you need to use an Authorization key to make sure we know if the script sending the request is a spam script or a legit one.

The Authorization key should not be provided to everyone but only those who applied through a form and got accepted.

Would need manual review of thousands of users that's not really practical and a spammer could submit the from automated anyway.

We would only accept their request if they have a project they want to integrate with Sponsorblock like an extension, an application or etc. But this is just my suggestion and I know it's not the best, but I couldn't think of anything else.

pgamerx commented 2 years ago

I don't want to use Google accounts for privacy reasons.

The current protection is via IP-based ratelimiting.

There are many ways to still have our own filtering system though. In future, there could be a reputation value calculated with how many reports align with older users to not display votes from new users until they reach that threshold. Would be tricky to figure out the right balance for it, but I highly doubt bots will be a large problem since voting does not affect someone's discoverability (unlike social media), so there is little incentive to abuse it.

SponsorBlock has never had a problem with bot users abusing the API.

Oh I missed your message, this is okay and makes sense.

But there is a high chance that Sponsorblock almost triples the number of the users within few weeks because if youtube doesn't add dislikes back, people will find alternatives and SponsorBlock is the best option by far, because it's used by a lot of people and can already kickstart the rating system.

But either way, I think your filtering system is fine for now and that we can leave as it is for now.

TrashAccount3424 commented 2 years ago

We would only accept their request if they have a project they want to integrate with Sponsorblock like an extension, an application or etc. But this is just my suggestion and I know it's not the best, but I couldn't think of anything else.

A spammer could just use someone elses app then wire-shark the key or de-compile the app and use it to spam.

I dont think any of that is needed. The only people who would have an incentive to spam likes/dislikes(?) would be the creator of a video which at the same time make so bad videos that he need the fake likes. Sounds kinda niche to me.

pgamerx commented 2 years ago

Makes sense, kindly ignore whatever I said above.

fourteen-1 commented 2 years ago

@ajayyy How about taking the YouTube Like-Dislike data from the YouTube API and storing it in the SponsorBlock API? (Just make the dislike number show instead of the word "DISLIKE"). This way a still frame of the Like-Dislike ratio will be preserved (for all videos posted before YT removes the data from their API) and we can determine the value/quality of a video from this archived like-dislike ratio?

pgamerx commented 2 years ago

@ajayyy How about taking the YouTube Like-Dislike data from the YouTube API and storing it in the SponsorBlock API? (Just make the dislike number show instead of the word "DISLIKE"). This way a still frame of the Like-Dislike ratio will be preserved (for all videos posted before YT removes the data from their API) and we can determine the value/quality of a video from this archived like-dislike ratio?

This is what I was doing, but I realised that this isn't like possible because almost 40k videos are posted every hour and this would only work for videos posted before 13th (and that too not all). Maybe @ajayyy can figure out a way to use WayBack machine's API to fetch dislikes?

ajayyy commented 2 years ago

Jopik, who runs https://filmot.com/, has a datadump that they are preparing.

pgamerx commented 2 years ago

That's amazing, we can utilise that data.

fourteen-1 commented 2 years ago

@pgamerx

This is what I was doing, but I realised that this isn't like possible because almost 40k videos are posted every hour

What is the primary issue/obstacle in doing this?

only work for videos posted before 13th

As someone who uses youtube mainly for learning, the best tutorials on youtube are mostly the older ones. There's innumerable videos of great value already posted and there's still a chance of preserving the best identifier of these great videos in the form of the like/dislike ratio. Without the L/D ratio, finding useful content will be like searching a needle in a haystack.

If there are any financial difficulties in retrieving the like/dislike data from youtube then please by all means set up a crowdfunding system. If you do it right, thousands like me would gladly help to get this very crucial thing done.

TheMajor-GitHub commented 2 years ago

What is the use of cataloging the old like to dislike ratio data from the API? There are literally billions of videos on YouTube already, and even if you had the ability to retain all that data, this data would not include “reasoning”, which can only be added after the fact. This seems like potentially a lot of work for something that isn't necessary. We were discussing disliking or liking the video based on a reason, we were not focusing on simply preserving existing data.

BlackSails7 commented 2 years ago

@OpeningCredits the reasons(labels) should include "like" and "dislike" imo, if so - this way we could use that data. However it would create "unfair" ratios for the rest of the labels. Therefor they should not be used like that.

On the other hand if they were used for setting youtube's dislike count (replace the 'DISLIKE' text with the number of archived dislikes), the problem with that is that the likes* would continue to increase, whereas the dislikes would stay the same. So it would create inaccurate ratings eventually.

Therefor the only way they could be used, is by showing a tooltip with the archived likes/dislikes somewhere. (perhaps when you hover the like/dislike buttons) And this tooltip could be an optional feature in settings.

Edit: OR! It could be shown bellow youtube's likes/dislikes with a ratio bar, and when you hover that, it would display the archived number of likes/dislikes!

ajayyy commented 2 years ago

I think multiple ratio bars would make most sense. With hovering showing you raw numbers. Could be configurable too