> Unfortunately the extension requires quite a large database (~15TB) - and it costs money.
> The ad\changelog was supposed to show only on browser restart - i.e. be much less intrusive
> The idea behind paid features was also to cover the costs (since donations became smaller than the hosting costs).
> I messed up with implementation though.
> Sorry.
I do feel for the developer, and I am not anti asking for donations, and the full page pop up on browser restart I don't think is terrible, but it would have been better to maybe have a changelog and have a donation button. The ads injected directly into youtube make me lose a lot of trust
It's basically an echo chamber extension.
Not sure what you mean by "fight back", either. Google 100% could not care less if you install this extension. They aren't bringing it back unless the division's leadership has a change of heart on whatever internal goals they wanted to achieve by removing it.
Maybe I am missing something but how does a database which just needs to store video ID and a number become 15TB in size?
But even then, the database could not get that big, you'd only need a few simple tables, one that tracks every plugin users like/dislike on the video they stored it on, and then a table that does the aggregations. 15TB sounds crazy.
I'm not a youtuber so idk what content creators could see, but it would have been smarter for them to go after the content creators that have the plugin installed instead of youtube users, not sure why we would care about those kinds of analytics
E.g. a plumbing video for fixing a tap with a bad rating is unlikely to actually tell you how to do so.
Round up to 500 raw bytes per row (perhaps including time/ip and other random garbage, plus indexes), 3x replication/redundancy or something, for 6 million users each having voted on 500 videos, and you're at 6TB; still some ways off from 15TB, but not insurmountably far.
(votes/user is rather tricky to get; but, as a bit of random garbage statistics math: YT gets ~5B views/day and has ~3B users; 6M downloads of the extension means ~0.2% of users use it, so 10M extension-user views/day = 15B over 4 years, or 2.5K/user; assuming 20% vote rate (rather high but lets say extension users care more for voting and/or watch YT more than an average person), that's 500 votes/user)
I already mentioned that the user IDs are 36 base64 chars, or 27 bytes if you store them max-packed; YT video IDs are 11 base64 chars, so 66 bits, doesn't quite fit in 8 bytes (not to mention that trying to pack the video IDs would mean your db becomes useless if youtube suddenly added a new video ID format). IP needs another bit somewhere for ipv4 vs ipv6, so likely 24 bytes (or just a string could be used).
Then you have some overhead for padding and string field lengths, and whatever overhead for packing the data for the disk storage (padding for all entires to stay within a page? maintaining a percentage of free space to ensure the B-tree property?). Then you have a copy of the fields in indexes, with whatever overhead those come with.
Granted, even that's probably around 200 bytes, not 500, in a reasonable db, but who's to say that the db used used is a reasonable & well-configured one; of course it's possible that a bunch more metadata is stored for user trustworthiness statistics or something, or duplicated tables where relations would work.
Stupid. You aren't going to have 2^288 users, why do you need that many user IDs? A 64-bit integer is already overkill.
>YT video IDs are 11 base64 chars, so 66 bits, doesn't quite fit in 8 bytes (not to mention that trying to pack the video IDs would mean your db becomes useless if youtube suddenly added a new video ID format)
Your video table has a 64-bit integral row ID. You have a column that is a foreign key to it. Join on them.
>IP needs another bit somewhere for ipv4 vs ipv6, so likely 24 bytes (or just a string could be used).
All IPv4 addresses can be encoded as IPv6 addresses so this only requires 16 bytes.
>Then you have some overhead for padding and string field lengths,
None of these things are strings.
>and whatever overhead for packing the data for the disk storage (padding for all entires to stay within a page? maintaining a percentage of free space to ensure the B-tree property?).
This is pretty low overhead. It won't take you to hundreds of bytes per row.
>Granted, even that's probably around 200 bytes, not 500, in a reasonable db, but who's to say that the db used used is a reasonable & well-configured one; of course it's possible that a bunch more metadata is stored for user trustworthiness statistics or something, or duplicated tables where relations would work.
If it stores IDs as strings then the DB probably won't be set up correctly either. That would be clearly wrong and wrong people are usually wrong about other things too.
It would bring the size down to under a 1T and allow the developer to go ad free. Hope this message reaches him.
Especially if the extension just sends the vote status instead of only reacting on a press (which'd allow it to send forward a vote done originally on, say, mobile; don't know if it does this, but it seems like a useful thing to do).
On the other hand, you also have to be a bit short sighted to be installed gargabage like "an extension so you can downvote" lol.
Also if I remember correctly, the extension was created before youtube completely removed the count, and it scraped the actual value from youtube to add it to the db while the count still was available
Yes but the corollary is that the dislikes you see are an estimate extrapolated from dislikes from people who use the extension.
In other words if people want their dislike to be seen, they need the extension.
Do you really think they're gonna financially support an entire video hosting platform?
https://github.com/Anarios/return-youtube-dislike/issues/123...
snug•3mo ago
I added some photos on this reddit post
https://www.reddit.com/r/youtube/comments/1of2k7s/return_you...