Google is definitely rigged in certain ways, but this looks like a bug, which you'd realize if you knew how modern web apps work. The way modern web applications work is that frontend updates are made optimistically in real time (for speed) and simultaneously hit an API in the background and rely on that as the source of the current application state which takes maybe 0.25 to a few seconds on average.
What it looks like is the user submitted a comment and the frontend added it to the comment list. In the background, it hits the API to submit the comment and the frontend returned a new list of comments for that view. That's where the error occurred: they probably mixed up the comment IDs somewhere in the code. When the new application state was returned, the view layer rendered that out. That's what you're seeing, they're not rewriting your comments in a quarter of a second.
People made posts here a few months back about "twitter unchecked all of my favorites right in front of my eyes" and it was the same issue.
Trust me, if Google wanted to alter comments, they could do so in a way that wouldn't be detectable to you.
That's where the error occurred: they probably mixed up the comment IDs somewhere in the code
Ok so you draft a comment and click submit, and instead of taking the text of your comment (which your local machine already has) and displaying it in the new location (posted comments instead of the box you draft in), they... post the comment, poll the API to get the ID of your comment, then poll the API to get the text of that comment, then display that where your comment should be?
How does that even remotely mesh with you saying
frontend updates are made optimistically in real time
Wouldn't an "optimistic real time update" just be taking the text you entered, formatting it to look like all the other posted comments and then displaying it on top of the other posted comments?
How in the world does "frontend updates are made optimistically in real time" mean your local machine pulls a "comment ID" from the API, then gets the text of that comment?
Learn more about the things you babble about before you babble about them, lowberg.
Every app is different, especially ones that operate at a larger scale like YouTube.
But in a typical modern app, say you make a comment like "I like puppies". The frontend would make that show up in the comment list basically instantly (as fast as the DOM could be altered, probably faster than .1 seconds) so it looks like it's working super fast. At this point, it is NOT yet saved to Google's database.
It's done this way assuming the request succeeds (probably around 99.9999% of the time it does) so that it has the appearance of the App being lightning quick. This is done for good user experience because making a network request is slower than instantaneous and companies don't want people waiting around for actions to submit. Even half second delays here and there waiting for HTTP request responses add up and annoy people.
In the background at the same time, the JS would make a network request to Google telling them you said "I like puppies" and the API would respond, maybe a quarter second or maybe several seconds later. Because most requests succeed, this setup works great for good user experience most of the time.
Different APIs return different types of data when data is submitted. But typically the backend is the ultimate source of truth. In many APIs, when you make a POST to add new content, they return the new current state of the data for the view layer to re-render.
Many companies use a view layer like React to take the current app state and render it. That's likely close to what you're seeing half second after the submit. The API responded with some data about the current application state and the view layer is rendering what it believes to be the current state of the data. We don't have enough info to know whether the bug was on the backend or frontend, but my guess is that they messed up a comment ID somewhere, possibly with an off by one error.
Most Apps work something like this and around 99.9999% of the time, nothing goes wrong with a network request so you don't notice any issues.
There are some things in life I know little about and am open to learning more: but I guarantee you I know what I'm talking about in this domain, so fuck off niggerfaggot.
You are correct in the way you explain how the web app works with the API, but you fail to explain how it would be possible to "smartly" modify the sentences people are posting. If it were a bug the output with most likely be garbled text.
It is illogical for the content to come out as garbled text in the event of a bug. The more likely bug would have the wrong content being rendered by the view library.
Modern view libraries (React is probably the most well-known, but there are dozens of them) in and of themselves just render out the current state of the content they're given.
The error could be on the backend (wrong data being returned) or frontend (explained below)
As efforts such as GraphQL and others are still not super widely used technologies, this state is often built up and cached from the API return values from multiple endpoints. You might have an API endpoint for a video, you might have one to get user information, you might have one for comments and one for replies. Etc. Ultimately, these are built up together, processed, and cached for the frontend and the view library renders the content the instant it has changed. (this is why you saw the content change about the time you would expect the API return value to come in)
This data from these APIs often come in multiple nested formats, sometimes with references to other data. This can be very complicated and is not always a super simple problem. See here for example.
It is very easy to see how there might have been an off by one error or something else where an API value was processed wrong and the IDs were mangled and the wrong text was rendered in the box. Or maybe in some loop, some value wasn't being cleared. That would cause the same issue too. A bug could not cause the content to be garbled. At worst you'd see something like an empty box if the content couldn't be found.
I'm not trying to carry water for Google or YouTube. I'd love to clearly catch them in an act of outright censorship and fucking bury them. But I know this field, and it seems almost certain that this is what the user noticed based on my knowledge.
Please note that I'm not saying this definitively. I don't know what happened in this specific case. I just gave a description of how modern web apps typically work.
Yeah, I'm pretty sure that's not what's going on. I don't admit to know what is going on, but I'm certain that youtube isn't accidentally grabbing the wrong ID for his comment multiple times. Especially looking at the weird generic text and relation to what he was trying to type. It's also a bit suspect that we're seeing this on a big firearms channel... But as with all of this that's just speculation. I, for one, have seen enough from google to not trust their platform in any way/shape/form.
Your first two paragraphs describe what I said happens, not what you said happens.
when you make a POST to add new content, they return the new current state of the data for the view layer to re-render.
Why. It already updated client side. When the user clicked "submit". What's backing the assumption that something changed between when you hit "submit" and when the server processed that request?
Furthermore, why would refreshing the document be bundled in with post requests? That removes the ability do to things like make a bunch of post requests, and then poll once to update the page instead of updating the page after each of fifty post requests.
That's where the error occurred: they probably mixed up the comment IDs somewhere in the code
This is still extremely stupid. A comment has text, a username, and an avatar. All of those things are contained in a single data structure some people like to call an "object". Is the code pulling the text in a completely different way than it's getting the username and avatar? Is it not fetching a comment from an array and then just pulling member variables for the comment.text, comment.username, and comment.avatar ? Are they just running getComment(lol_idk_whichever).text ?
Your appeal to authority busted. We can write this off as a big clumsy error by a programmer at one of the biggest tech companies in the world, not caught by anyone in the release process including their QA team, and yet YOU are some infallible authority on what's happening in code you can't even see? Because you can make guesses based on how you think "most apps work something like this"?
I guarantee you I know what I'm talking about in this domain
Okay pal that guarantee and a dollar will buy you fifty cents.
Your first two paragraphs describe what I said happens, not what you said happens.
No, I gave a further description of what I've been saying all along. It's not my fault if you didn't understand it.
Why. It already updated client side.
The backend, not the many frontends that consume the backend's content, is the ultimate arbiter of application state. Because the state of some type of data changed and the request is happening anyway, that's viewed as a good time to update the state in some types of applications because a request is happening anyway.
There are many ways to handle the timing of updating web content. You can poll periodically. You can piggyback off of some other requests (what I described and what you seem to view as incomprehensible). You can use web sockets and other techniques for real-time updating. You can just wait for a page refresh.
What's backing the assumption that something changed between when you hit "submit" and when the server processed that request?
2 simple points.
In a popular application, some types of state can indeed change in a few seconds until the server responds.
But, we're not necessarily talking about that brief time window, but about the time window between arriving at a page and fetching the list of comments, watching a video, writing a comment, and submitting. The comments might be loaded when you arrive at that URL, but might not be refreshed until you submit a new comment. Again, it depends on application design. Doing it this way might or might not make sense for some Apps, for some API requests.
APIs return different types of data depending on App design. Some APIs might want to keep things very simple and basically just return a 201 response code for some types of POST requests. Some APIs might want to make things more elaborate and also return the current state of some type of data. There's a bunch of valid ways to do it.
Furthermore, why would refreshing the document be bundled in with post requests?
Answered above.
That removes the ability do to things like make a bunch of post requests, and then poll once to update the page instead of updating the page after each of fifty post requests.
It doesn't remove the ability to make a bunch of POST requests. There's nothing stopping you from making as you want. Your argument might be closer to valid if you said something like "It might be inefficient and hit the backend too hard to fetch all of the data and send that back to user on every post request." However, that is not the case in many applications.
Caching is a thing.
Certain API actions, such as a user posting a comment, are not typically going to happen in a rapid fire series. One way to design an application is you might update the application state when a user makes a comment, but might not do the same thing when more common POST requests like upvotes/downvotes are done. Again, there's a 100 ways to design an App and API based on the specific problem domain. Not all API requests in an App have to return state. Some might just need to return a success message. This is a valid way of designing an API.
Many APIs have rate limiting and other functionality to protect them on top of that.
This is still extremely stupid. A comment has text, a username, and an avatar. All of those things are contained in a single data structure some people like to call an "object". Is the code pulling the text in a completely different way than it's getting the username and avatar? Is it not fetching a comment from an array and then just pulling member variables for the comment.text, comment.username, and comment.avatar ? Are they just running getComment(lol_idk_whichever).text ?
You kind of make a point here, but every programmer has created some bugs. Maybe the bug was in the frontend, maybe in the backend. Maybe the view library they use fucked up somewhere. It's easy to say "this shouldn't happen" when bugs are common in any software.
Your appeal to authority busted. We can write this off as a big clumsy error by a programmer at one of the biggest tech companies in the world, not caught by anyone in the release process including their QA team, and yet YOU are some infallible authority on what's happening in code you can't even see? Because you can make guesses based on how you think "most apps work something like this"?
I didn't make any absolute claim about YouTube in this instance. I described how a typical modern Application works and what the likely issue was. I can see this based on my experience as well as observing the timing of the video. The UI updated optimistically, but the comment changed in about the time that it would take for it to hit the backend and receive the response. Just seeing that alone is a huge clue about what happened.
Okay pal that guarantee and a dollar will buy you fifty cents.
It's clear you have some type of technology knowledge, but I don't think you have quite as much experience in how modern web apps generally work.
Do you have a different logical explanation for what's observed in the video? I've made my case. What's your explanation?
It's categorically stupid to update the client's browser
when posting the message, and then again
when done posting the message.
You can say the backend is the ultimate source of truth, and that's right, but if you write sloppy code that pulls from it twice per comment (and god knows how many times how many other places) it's going to cause a lot of load on that server(farm), and moreover someone's going to notice and make a name for themselves by fixing it.
In a popular application, some types of state can indeed change in a few seconds until the server responds.
Again, don't constantly poll whatever database holds the comments or you're going to destroy that server.
we're ... talking about ... the time window between arriving at a page ... and submitting(a comment).
In my experience, you don't get a full refresh of the comments when you write your own. you just see your own at the top of the pre-existing list. That's anecdotal but we're looking at a black box so anecdotal's all we've got.
might be closer to valid if you said something like "It might be inefficient and hit the backend too hard to fetch all of the data and send that back to user on every post request."
That is what I'm saying. If every post request from every user comes with a full dump of the page content, it becomes inefficient to make more than one. Inefficiency isn't just inherently wrong, it costs shekels. They're not spending shekels so you can get up-to-the-second comment feeds in situations where they probably haven't changed anyway.
Caching is a thing.
We're talking about updating the client with client-generated content that was created a negligible amount of time ago. There's no need to cache it, it's in the post request. Make a post request with the comment object and then shove the same comment object into the top of the comment feed.
typically
one way
might
might not
Do you get fresh comments when you post one? If so then they're pulling new content. If not it starts stacking evidence that they're not.
It's easy to say "this shouldn't happen" when bugs are common in any software.
The structures here are simple enough that "whoopsie doodle" doesn't really produce a reasonable explanation.
What's your explanation?
Either the guy's got a script to fuck with the content like so https://files.catbox.moe/gcrgew.png in real time and is using it to troll people, or they're fucking with his comment. First one's a simpler explanation. Why would they let the client update with the content they saved to the backend if their intent was to fuck with it.
It's categorically stupid to update the client's browser
when posting the message, and then again
when done posting the message.
Optimistic updates in some fashion are considered current modern best practice and are logical when considering user experience.
Even a delay of a couple of seconds puts off users and gets them to use your App less or even stop using your App which reduces the amount of money you make. The UI has to appear to be as close to instantaneous as possible, even though sending a network request and receiving and processing a response might take a few seconds or even slower on a bad connection. You don't want the user to click "submit a comment" and then see a loading spinner for a while. You want the comment to instantly be added (even if it's not yet permanently saved) while it does its thing invisibly in the background. Somewhere over 99+% of the time, this works as intended, and you don't even notice that a large number of websites work somewhat along these lines. The UI is often updated instantly while requests happen in the background and sometimes new data is fetched in the response.
I already wrote a novel on what I think likely happened.
We're also quibbling over a few minor things like caching at this point. The fact that a comment was added a thousandth of a millisecond ago doesn't mean caching the new state of the content is necessarily illogical, especially at the scale that Google operates. Caching isn't done for the first user in line: it's for the dozens/hundreds/thousands of subsequent requests that come afterwards.
To me personally, it looks like you're technically knowledgable but you don't have a large amount of experience with modern web development or we're talking in circles somewhat.
I will say this in conclusion.
I think what I explained is likely the issue and just seeing the timing of the update is probably the biggest clue. It is explainable perfectly if you understand how modern view layers generally work and just render out the current state of the content.
This doesn't mean that I can prove definitively what happened. The user could be fucking with people with some kind of manipulated content. I have no idea who that person is and how credible he is.
I think Google is a pile of shit, but I really doubt this is evidence of them rewriting content as many believe. If Google wanted to rewrite content, couldn't they do so in a way that wasn't as easily detectable by the user? Wouldn't the scores of pro-Hitler and pro-white and other thought-crimes be cleaned up rather than random nothing comments? I'm not saying it's impossible, but Google deliberately changing content doesn't seem anywhere near likely.
view the rest of the comments →
cdglow ago
Google is definitely rigged in certain ways, but this looks like a bug, which you'd realize if you knew how modern web apps work. The way modern web applications work is that frontend updates are made optimistically in real time (for speed) and simultaneously hit an API in the background and rely on that as the source of the current application state which takes maybe 0.25 to a few seconds on average.
What it looks like is the user submitted a comment and the frontend added it to the comment list. In the background, it hits the API to submit the comment and the frontend returned a new list of comments for that view. That's where the error occurred: they probably mixed up the comment IDs somewhere in the code. When the new application state was returned, the view layer rendered that out. That's what you're seeing, they're not rewriting your comments in a quarter of a second.
People made posts here a few months back about "twitter unchecked all of my favorites right in front of my eyes" and it was the same issue.
Trust me, if Google wanted to alter comments, they could do so in a way that wouldn't be detectable to you.
6cd6beb ago
This is stupid.
Ok so you draft a comment and click submit, and instead of taking the text of your comment (which your local machine already has) and displaying it in the new location (posted comments instead of the box you draft in), they... post the comment, poll the API to get the ID of your comment, then poll the API to get the text of that comment, then display that where your comment should be?
How does that even remotely mesh with you saying
Wouldn't an "optimistic real time update" just be taking the text you entered, formatting it to look like all the other posted comments and then displaying it on top of the other posted comments?
How in the world does "frontend updates are made optimistically in real time" mean your local machine pulls a "comment ID" from the API, then gets the text of that comment?
Learn more about the things you babble about before you babble about them, lowberg.
cdglow ago
Every app is different, especially ones that operate at a larger scale like YouTube.
But in a typical modern app, say you make a comment like "I like puppies". The frontend would make that show up in the comment list basically instantly (as fast as the DOM could be altered, probably faster than .1 seconds) so it looks like it's working super fast. At this point, it is NOT yet saved to Google's database.
It's done this way assuming the request succeeds (probably around 99.9999% of the time it does) so that it has the appearance of the App being lightning quick. This is done for good user experience because making a network request is slower than instantaneous and companies don't want people waiting around for actions to submit. Even half second delays here and there waiting for HTTP request responses add up and annoy people.
In the background at the same time, the JS would make a network request to Google telling them you said "I like puppies" and the API would respond, maybe a quarter second or maybe several seconds later. Because most requests succeed, this setup works great for good user experience most of the time.
Different APIs return different types of data when data is submitted. But typically the backend is the ultimate source of truth. In many APIs, when you make a POST to add new content, they return the new current state of the data for the view layer to re-render.
Many companies use a view layer like React to take the current app state and render it. That's likely close to what you're seeing half second after the submit. The API responded with some data about the current application state and the view layer is rendering what it believes to be the current state of the data. We don't have enough info to know whether the bug was on the backend or frontend, but my guess is that they messed up a comment ID somewhere, possibly with an off by one error.
Most Apps work something like this and around 99.9999% of the time, nothing goes wrong with a network request so you don't notice any issues.
There are some things in life I know little about and am open to learning more: but I guarantee you I know what I'm talking about in this domain, so fuck off niggerfaggot.
Abillionelectrons ago
You are correct in the way you explain how the web app works with the API, but you fail to explain how it would be possible to "smartly" modify the sentences people are posting. If it were a bug the output with most likely be garbled text.
cdglow ago
It is illogical for the content to come out as garbled text in the event of a bug. The more likely bug would have the wrong content being rendered by the view library.
Modern view libraries (React is probably the most well-known, but there are dozens of them) in and of themselves just render out the current state of the content they're given.
The error could be on the backend (wrong data being returned) or frontend (explained below)
As efforts such as GraphQL and others are still not super widely used technologies, this state is often built up and cached from the API return values from multiple endpoints. You might have an API endpoint for a video, you might have one to get user information, you might have one for comments and one for replies. Etc. Ultimately, these are built up together, processed, and cached for the frontend and the view library renders the content the instant it has changed. (this is why you saw the content change about the time you would expect the API return value to come in)
This data from these APIs often come in multiple nested formats, sometimes with references to other data. This can be very complicated and is not always a super simple problem. See here for example.
https://tonyhb.gitbooks.io/redux-without-profanity/content/normalizer.html
It is very easy to see how there might have been an off by one error or something else where an API value was processed wrong and the IDs were mangled and the wrong text was rendered in the box. Or maybe in some loop, some value wasn't being cleared. That would cause the same issue too. A bug could not cause the content to be garbled. At worst you'd see something like an empty box if the content couldn't be found.
I'm not trying to carry water for Google or YouTube. I'd love to clearly catch them in an act of outright censorship and fucking bury them. But I know this field, and it seems almost certain that this is what the user noticed based on my knowledge.
Please note that I'm not saying this definitively. I don't know what happened in this specific case. I just gave a description of how modern web apps typically work.
rootbeervloat ago
Yeah, I'm pretty sure that's not what's going on. I don't admit to know what is going on, but I'm certain that youtube isn't accidentally grabbing the wrong ID for his comment multiple times. Especially looking at the weird generic text and relation to what he was trying to type. It's also a bit suspect that we're seeing this on a big firearms channel... But as with all of this that's just speculation. I, for one, have seen enough from google to not trust their platform in any way/shape/form.
6cd6beb ago
Your first two paragraphs describe what I said happens, not what you said happens.
Why. It already updated client side. When the user clicked "submit". What's backing the assumption that something changed between when you hit "submit" and when the server processed that request?
Furthermore, why would refreshing the document be bundled in with post requests? That removes the ability do to things like make a bunch of post requests, and then poll once to update the page instead of updating the page after each of fifty post requests.
This is still extremely stupid. A comment has text, a username, and an avatar. All of those things are contained in a single data structure some people like to call an "object". Is the code pulling the text in a completely different way than it's getting the username and avatar? Is it not fetching a comment from an array and then just pulling member variables for the comment.text, comment.username, and comment.avatar ? Are they just running getComment(lol_idk_whichever).text ?
Your appeal to authority busted. We can write this off as a big clumsy error by a programmer at one of the biggest tech companies in the world, not caught by anyone in the release process including their QA team, and yet YOU are some infallible authority on what's happening in code you can't even see? Because you can make guesses based on how you think "most apps work something like this"?
Okay pal that guarantee and a dollar will buy you fifty cents.
cdglow ago
No, I gave a further description of what I've been saying all along. It's not my fault if you didn't understand it.
The backend, not the many frontends that consume the backend's content, is the ultimate arbiter of application state. Because the state of some type of data changed and the request is happening anyway, that's viewed as a good time to update the state in some types of applications because a request is happening anyway.
There are many ways to handle the timing of updating web content. You can poll periodically. You can piggyback off of some other requests (what I described and what you seem to view as incomprehensible). You can use web sockets and other techniques for real-time updating. You can just wait for a page refresh.
2 simple points.
APIs return different types of data depending on App design. Some APIs might want to keep things very simple and basically just return a 201 response code for some types of POST requests. Some APIs might want to make things more elaborate and also return the current state of some type of data. There's a bunch of valid ways to do it.
Answered above.
It doesn't remove the ability to make a bunch of POST requests. There's nothing stopping you from making as you want. Your argument might be closer to valid if you said something like "It might be inefficient and hit the backend too hard to fetch all of the data and send that back to user on every post request." However, that is not the case in many applications.
You kind of make a point here, but every programmer has created some bugs. Maybe the bug was in the frontend, maybe in the backend. Maybe the view library they use fucked up somewhere. It's easy to say "this shouldn't happen" when bugs are common in any software.
I didn't make any absolute claim about YouTube in this instance. I described how a typical modern Application works and what the likely issue was. I can see this based on my experience as well as observing the timing of the video. The UI updated optimistically, but the comment changed in about the time that it would take for it to hit the backend and receive the response. Just seeing that alone is a huge clue about what happened.
It's clear you have some type of technology knowledge, but I don't think you have quite as much experience in how modern web apps generally work.
Do you have a different logical explanation for what's observed in the video? I've made my case. What's your explanation?
6cd6beb ago
It's categorically stupid to update the client's browser
You can say the backend is the ultimate source of truth, and that's right, but if you write sloppy code that pulls from it twice per comment (and god knows how many times how many other places) it's going to cause a lot of load on that server(farm), and moreover someone's going to notice and make a name for themselves by fixing it.
Again, don't constantly poll whatever database holds the comments or you're going to destroy that server.
In my experience, you don't get a full refresh of the comments when you write your own. you just see your own at the top of the pre-existing list. That's anecdotal but we're looking at a black box so anecdotal's all we've got.
That is what I'm saying. If every post request from every user comes with a full dump of the page content, it becomes inefficient to make more than one. Inefficiency isn't just inherently wrong, it costs shekels. They're not spending shekels so you can get up-to-the-second comment feeds in situations where they probably haven't changed anyway.
We're talking about updating the client with client-generated content that was created a negligible amount of time ago. There's no need to cache it, it's in the post request. Make a post request with the comment object and then shove the same comment object into the top of the comment feed.
Do you get fresh comments when you post one? If so then they're pulling new content. If not it starts stacking evidence that they're not.
The structures here are simple enough that "whoopsie doodle" doesn't really produce a reasonable explanation.
Either the guy's got a script to fuck with the content like so https://files.catbox.moe/gcrgew.png in real time and is using it to troll people, or they're fucking with his comment. First one's a simpler explanation. Why would they let the client update with the content they saved to the backend if their intent was to fuck with it.
cdglow ago
Optimistic updates in some fashion are considered current modern best practice and are logical when considering user experience.
Even a delay of a couple of seconds puts off users and gets them to use your App less or even stop using your App which reduces the amount of money you make. The UI has to appear to be as close to instantaneous as possible, even though sending a network request and receiving and processing a response might take a few seconds or even slower on a bad connection. You don't want the user to click "submit a comment" and then see a loading spinner for a while. You want the comment to instantly be added (even if it's not yet permanently saved) while it does its thing invisibly in the background. Somewhere over 99+% of the time, this works as intended, and you don't even notice that a large number of websites work somewhat along these lines. The UI is often updated instantly while requests happen in the background and sometimes new data is fetched in the response.
I already wrote a novel on what I think likely happened.
We're also quibbling over a few minor things like caching at this point. The fact that a comment was added a thousandth of a millisecond ago doesn't mean caching the new state of the content is necessarily illogical, especially at the scale that Google operates. Caching isn't done for the first user in line: it's for the dozens/hundreds/thousands of subsequent requests that come afterwards.
To me personally, it looks like you're technically knowledgable but you don't have a large amount of experience with modern web development or we're talking in circles somewhat.
I will say this in conclusion.