Add integration with returnyoutubedislike.com

[m00nwtchr]

Checklist

• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

What feature do you want?

Add integration with https://returnyoutubedislike.com/

Why do you want this feature?

To return YouTube dislikes

I may be able to implement this myself but I'll have to take a look at their API and get familiarised with NewPipe's codebase

[triallax]

We already fixed that, see TeamNewPipe/NewPipeExtractor#753.

[m00nwtchr]

No, the point is to still show a dislike count, not just fix parsing (and their method of doing that is much better than just calculating an estimate, especially with the planned features)

[triallax]

the point is to still show a dislike count

I don't get it, the PR does that too.

just calculating an estimate

It's actually pretty accurate.

especially with the planned features

Yeah, that's a good point.

Anyway, I was not dismissing your suggestion, just saying that the bug has been fixed for now.

[m00nwtchr]

ah, yeah i only realised that that PR also added an estimated amount after i wrote that (hence the edits)

[eternal-sorrow]

If such an integration is added, it should be disabled by default.

[Anarios]

Hi, I'm owner of returnyoutubedislike.com If there are plans for integration - I'd be happy to assist. Our database has over 200mil videos saved with stats before the dislikes were disabled, and a huge dataset (69tb) from Archive Team is coming as well.

Other than that we're collecting likes and dislikes from 1.5mil extension users - and using those to estimate actual dislike numbers (not perfect - but the more users we get - the closer it becomes to true numbers)

[pgamerx]

(69tb)

Nice

[Zoobdude]

Hi, I'm owner of returnyoutubedislike.com If there are plans for integration - I'd be happy to assist. Our database has over 200mil videos saved with stats before the dislikes were disabled, and a huge dataset (69tb) from Archive Team is coming as well.

Other than that we're collecting likes and dislikes from 1.5mil extension users - and using those to estimate actual dislike numbers (not perfect - but the more users we get - the closer it becomes to true numbers)

And surely another integration would make them more accurate.

[Anarios]

And surely another integration would make them more accurate.

yes, that's the point of integrations :)

[mcmurphy8097234789]

If such an integration is added, it should be disabled by default.

I am inclined to agree. No shade being thrown at @Anarios (thank you for your work), but currently the extension does rely on user interaction/data to generate accurate counts. Under the current security FAQ offered by the project, it is not clear for how long the hashed IP addresses or the user IDs are stored. Finally, the server backend code has not been open-sourced yet. Again, I appreciate the work Anarios has done (and he does have the tentative support by names such as LTT), and I think this type of solution is the fix needed for the dislike problem. However, until the concerns I mentioned are rectified, I would absolutely support the extension being disabled by default should it be included in NewPipe.

On that note, is the NewPipe team considering implementing it at this point? Or no?

[Anarios]

it is not clear for how long the hashed IP addresses or the user IDs are stored

Well, indefinitely. Once you cast your vote - the vote is stored forever.

However, until the concerns I mentioned are rectified

I honestly do not understand why you (and others) think that publishing backend code improves privacy concerns by any means. The code running on server could be different from the published code, there could be a reverse proxy between server and client doing any kind of things with data passed.

I think, by default, you should assume that none of the data sent to server is safe (and therefore we send as little data as possible).

I would absolutely support the extension being disabled by default should it be included in NewPipe.

As an in-between option - viewing dislikes can be enabled by default (since no userId is generated for this), and counting dislikes and likes could be an opt-in option. But the user has to see and be warned that his votes are not counted unless he enables is. (otherwise noone will even know that his votes do not affect anything).

[Midou36O]

I honestly do not understand why you (and others) think that publishing backend code improves privacy concerns by any means. The code running on server could be different from the published code, there could be a reverse proxy between server and client doing any kind of things with data passed.

It improves privacy concerns, say someone doesn't trust your server, they could run their own instance of that server, that they manage themselves, thus they can trust themselves and not some other party.

As an in-between option - viewing dislikes can be enabled by default (since no userId is generated for this), and counting dislikes and likes could be an opt-in option.

Enabling the ability to view dislikes by default sends the user's public IP to your server without their consent (not that it's such a big deal, but some people prefer to have the freedom to choose if they want to use this or not, thus the option of making it off by default being more logical)