Elon Musk buys Twitter for $44 billion

Not my particular stomping-ground, but I work in tech and I think you may be correct, as far as it goes.

Nevertheless, we have it from Musk himself that there is so much old censorship code buried in the Twitter codebase that they may never be able to remove it all and may just rewrite a fresh codebase from scratch (this was in his Bee interview on-campus at Twitter, IIRC). Even just the day before that interview, he said they found some ancient keyword-matching code that would de-boost conservative Tweets based on blind keyword-matches. Obviously, the blind keyword-matching caused a lot of collateral damage, which is how they found it.

Everything they do in automated censorship results in collateral damage and unintended consequences. It's terribly flawed. Boosting and deboosting itself is unfair by definition.

And as I said above, everything you do on Twitter results in boosting or deboosting. There's a snowball effect. You "like" something that is unapproved, you get deboosted. You "follow" someone who is out of favor, you get deboosted.
 
Those seem to be references to "right" and "left" database "join" (record merge) operations.

If so, then they are no more "socio-political" in nature than terms such as "master" and "slave", or "whitelist" and "blacklist" are when they are used in the context of computer programming. ("Breadcrumb" is also an idiomatic programming term - it's just a mechanism for tracking things that have been done.)

He responded to that possibility in another thread. He points out that there are plenty of left and right joins in the code, but that the references to left and right that he was pointing out were not joins, but calls to a counter.

Part of the thread: ;)


https://twitter.com/The1Parzival/status/1673157674505244674
 
Last edited:

https://twitter.com/USAB4L/status/1671999186655674369

I would point out that my Tweet about the Twitter Social Credit System was not based solely on that code segment. That code segment would be a single example of how it might be coded, and disguised in the code. The effects of this credit system is fairly obvious to users of Twitter, especially those who have suffered from some form of "freedom of reach" restriction, also known colloquially as "shadow banning".

Part of the reason this social credit system is so nefarious is the fact that it operates in the shadows, where no one fully understands how it works, where Twitter can not provide you with information on the ways in which you are limited, and there is absolutely no help or appeal process.
 
The "left" and "right" could mean 1,000 different things, but it's not a JOIN.

They are two discrete values with separate meanings and are being counted independent of each other, and the author of this code saw fit to label them "left" and "right".
 
Based on the way the counters are incremented, they are definitely labelled "left" and "right" because of how the data will be merged, and has nothing to do with political leaning:

private[this] def mergeDataRecord(
leftRecord: Event[DataRecord],
rightRecordOpt: Option[DataRecord],
leftDataRecordCounter: Counter,
rightDataRecordCounter: Counter,
mergeNumFeaturesCounter: Counter
): Event[DataRecord] = {
leftDataRecordCounter.incr()
rightRecordOpt.foreach { rightRecord =>
rightDataRecordCounter.incr()
DataRecordMerger.merge(leftRecord.event, rightRecord)
mergeNumFeaturesCounter.incr(new RichDataRecord(leftRecord.event).numFeatures())
}
leftRecord
}
 
Based on the way the counters are incremented, they are definitely labelled "left" and "right" because of how the data will be merged, and has nothing to do with political leaning:

private[this] def mergeDataRecord(
leftRecord: Event[DataRecord],
rightRecordOpt: Option[DataRecord],
leftDataRecordCounter: Counter,
rightDataRecordCounter: Counter,
mergeNumFeaturesCounter: Counter
): Event[DataRecord] = {
leftDataRecordCounter.incr()
rightRecordOpt.foreach { rightRecord =>
rightDataRecordCounter.incr()
DataRecordMerger.merge(leftRecord.event, rightRecord)
mergeNumFeaturesCounter.incr(new RichDataRecord(leftRecord.event).numFeatures())
}
leftRecord
}

I haven't looked through all the code, or traced it. Somebody has to pay me to do that. ;)

But if you look at his Twitter thread, he mentions that he is talking about the terms "AuthorRight" & "Author Left", not any other uses of right and left:

@The1Parzival

This is where you have to now understand the intent they took, which was to hide this nefarious code embedded in what would seem to be other normal code. SO, HOW HIDDEN WAS THIS CODE? The terms "AuthorRight" & "Author Left" come up JUST ONCE EACH THROUGHOUT THE ENTIRE ALGORITHM!

He also mentions a StatsReceiver command:

Notice how these Counters call the "StatsReceiver" command just like with the AuthorRight Code. Anytime you see the "StatsReceiver" you can be sure it is tracking SOME ATTRIBUTE to your account.
 
I haven't looked through all the code, or traced it. Somebody has to pay me to do that. ;)

But if you look at his Twitter thread, he mentions that he is talking about the terms "AuthorRight" & "Author Left", not any other uses of right and left:



He also mentions a StatsReceiver command:

The key part is this:

mergeRecord(leftRecord, rightRecordOpt) = {
...
leftDataRecordCounter.incr() // increment()
...
}

It's clear that the "leftDataRecordCounter" is being used to measure how many times it was used in the "mergeRecord" command.

So while he is right that these counters are not a JOIN, and not used as part of a JOIN, they are used to measure how many times a record is used in a merge operation, and incremented based on whether it was used as "left" or "right" side of the merge.
 
Last edited:
I haven't looked through all the code, or traced it. Somebody has to pay me to do that. ;)

But if you look at his Twitter thread, he mentions that he is talking about the terms "AuthorRight" & "Author Left", not any other uses of right and left:

He also mentions a StatsReceiver command:

I sense there could be something here, but I think it's still at the level of smoke, not fire. To make it fire, we need to understand what differentiates "AuthorLeft" versus "AuthorRight" (how those stats are differentiated within any given account). If the code can be located where these stats are filtered based on whatever pattern-match/neural-net/whatever, that will be fire, not smoke. But I have a sneaking suspicion that all of that machinery was some kind of black-box API running on three-letter agency hardware and all of that was physically ripped out of Twitter HQ months before Elon arrived with his sink.
 
I sense there could be something here, but I think it's still at the level of smoke, not fire. To make it fire, we need to understand what differentiates "AuthorLeft" versus "AuthorRight" (how those stats are differentiated within any given account). If the code can be located where these stats are filtered based on whatever pattern-match/neural-net/whatever, that will be fire, not smoke. But I have a sneaking suspicion that all of that machinery was some kind of black-box API running on three-letter agency hardware and all of that was physically ripped out of Twitter HQ months before Elon arrived with his sink.

There is zero to this. You can tell based on the immediate context of where the counter is incremented on line 184:
https://github.com/twitter/the-algo...eal_time/StormAggregateSourceUtils.scala#L240
 
There is zero to this. You can tell based on the immediate context of where the counter is incremented on line 184:
https://github.com/twitter/the-algo...eal_time/StormAggregateSourceUtils.scala#L240

That certainly seems to be superficially the case, nevertheless, we already know for a fact that Twitter was overflowing with all kinds of "sneakiness", so sneakiness is a very likely hypothesis here. Left/right join is not commonly-used terminology outside of very specific database domains (most applications are simply going to call it a "join"), so this is an ideal place to camouflage a politically-differentiated stats counter. We're missing a smoking-gun, but that doesn't mean that the OP isn't on to something. I encourage people to keep sniffing around, because no matter how good of a job the three-letter agencies did on white-gloving Twitter HQ before they left... they may have left a single fingerprint somewhere, and that's all we really need.

PS: This is not my stomping-ground but if someone with spare cash and an abundance of curiosity would like me to look through the code, I am available on contract and would do it for $40/hr. I am able to script and use pattern-matching and machine-learning filters to move through large volumes of code quickly to sift for items of interest. Choose your own level of analysis/cost.
 
Last edited:
That certainly seems to be superficially the case, nevertheless, we already know for a fact that Twitter was overflowing with all kinds of "sneakiness", so sneakiness is a very likely hypothesis here.

No amount of sneakiness is going to change the way the code works. The "left" counter is incremented when the record is used on the left side of the merge, and the "right" counter is incremented when the record is used on the right side of the merge. Every time the function is run, a counter on the left side is incremented - and if a right side is provided, a counter on the right side is incremented. (the right side is optional, as the arguments provided to the function are a byproduct of an earlier left join)


Left/right join is not commonly-used terminology outside of very specific database domains (most applications are simply going to call it a "join"), so this is an ideal place to camouflage a politically-differentiated stats counter.

To clarify, Left/right join is extremely commonly used terminology within any data domain. (not limited to just databases)

The file that I posted very much falls within the "data" domain. Left Join terminology is very much a normal thing to expect in a context like this, and if you wanted to hide the purpose of a political counter, you wouldn't build a file with 250 lines of fake joins and merges to hide the purpose of your counter suspiciously named "leftCounter", you just wouldn't call it "leftCounter" to begin with.

This thing has exactly 0 substance behind it.

PS: This is not my stomping-ground

This is my stomping ground and has been for decades
 
Last edited:
This thing has exactly 0 substance behind it.

You can't know that because we don't know what stats are going into each of these counters, meaning, we don't know from this code what is causing data keys to be kept in the left or right structures, respectively. That condition is somewhere else. Possibly kept behind a black-box API that was running on a three-letter agency server. Since that is possible, we simply don't have enough context to rule it out.

This is my stomping ground and has been for decades

Fine. I'm not in databases but I am conversant in all of this (that's why I'm talking about it), so don't mistake my disclaimer to mean that I am ignorant. Stomping-ground or not, it is a mistake to underestimate the amount of sneakiness that was going on at Twitter. The idea that you can just eyeball it and verify there is nothing spurious here, doesn't hold up. I heartily encourage popular investigators to KEEP DIGGING. I don't yet see a smoking-gun, but there could be one, so people interested in this should keep digging. And no, I'm not going to do that unless paid because, like B4L, I have other work I can do so my time=$$$. Volunteers who are interested should absolutely continue to dig.
 
You can't know that because we don't know what stats are going into each of these counters, meaning, we don't know from this code what is causing data keys to be kept in the left or right structures, respectively. That condition is somewhere else. Possibly kept behind a black-box API that was running on a three-letter agency server. Since that is possible, we simply don't have enough context to rule it out.

What I can say with certainty, is that none of what has been presented so far, gives any reason at all to come to the conclusion that these counters are tracking political alignment.

They used the word "left" and "right" in a variable name, in a context where it makes sense to use those variable names. That's it. That's the extent of the evidence.

Is Twitter tracking left/right leaning? I would bet the farm on it that they are tracking those stats and more. But I would also bet the farm that the code that actually tracks that has literally nothing with the code that is in this thread.


Fine. I'm not in databases but I am conversant in all of this (that's why I'm talking about it), so don't mistake my disclaimer to mean that I am ignorant. Stomping-ground or not, it is a mistake to underestimate the amount of sneakiness that was going on at Twitter. The idea that you can just eyeball it and verify there is nothing spurious here, doesn't hold up.

Trust me, I'm not underestimating their sneakiness. You're simply underestimating my experience. Which is fine. I don't trust "experts" and you shouldn't trust me on the basis of my claimed expertise, but with that said, yea - I can fuckin eye ball this because I do have the experience.

I heartily encourage popular investigators to KEEP DIGGING. I don't yet see a smoking-gun, but there could be one

If there is, it's not gonna be related at all to this "discovery".
 
Last edited:
I haven't looked through all the code, or traced it. Somebody has to pay me to do that. ;)

But if you look at his Twitter thread, he mentions that he is talking about the terms "AuthorRight" & "Author Left", not any other uses of right and left:

He also mentions a StatsReceiver command:

I sense there could be something here, but I think it's still at the level of smoke, not fire. To make it fire, we need to understand what differentiates "AuthorLeft" versus "AuthorRight" (how those stats are differentiated within any given account). ...

What I can say with certainty, is that none of what has been presented so far, gives any reason at all to come to the conclusion that these counters are tracking political alignment.
...

Based on the link to the code you posted, this seems to be the code segment that he based his "AuthorRight" and "AuthorLeft" hypothesis. I have no idea what this code does.

private[real_time] object StormAggregateSourceUtils {
type UserId = Long
type AuthorId = Long
type TweetId = Long

/**
* Attaches a [[FeatureStoreClient]] to the underyling [[Producer]]. The FeatureStoreClient
* hydrates additional user features.
*
* @param underlyingProducer converts a stream of [[com.twitter.clientapp.thriftscala.LogEvent]]
* to a stream of [[DataRecord]].
*/
def wrapByFeatureStoreClient(
underlyingProducer: Producer[Storm, Event[DataRecord]],
jobConfig: RealTimeAggregatesJobConfig,
scopedStatsReceiver: StatsReceiver
): Producer[Storm, Event[DataRecord]] = {
lazy val keyDataRecordCounter = scopedStatsReceiver.counter("keyDataRecord")
lazy val keyFeatureCounter = scopedStatsReceiver.counter("keyFeature")
lazy val leftDataRecordCounter = scopedStatsReceiver.counter("leftDataRecord")
lazy val rightDataRecordCounter = scopedStatsReceiver.counter("rightDataRecord")
lazy val mergeNumFeaturesCounter = scopedStatsReceiver.counter("mergeNumFeatures")
lazy val authorKeyDataRecordCounter = scopedStatsReceiver.counter("authorKeyDataRecord")
lazy val authorKeyFeatureCounter = scopedStatsReceiver.counter("authorKeyFeature")
lazy val authorLeftDataRecordCounter = scopedStatsReceiver.counter("authorLeftDataRecord")
lazy val authorRightDataRecordCounter = scopedStatsReceiver.counter("authorRightDataRecord")

lazy val authorMergeNumFeaturesCounter = scopedStatsReceiver.counter("authorMergeNumFeatures")
lazy val tweetKeyDataRecordCounter =
scopedStatsReceiver.counter("tweetKeyDataRecord")
lazy val tweetKeyFeatureCounter = scopedStatsReceiver.counter("tweetKeyFeature")
lazy val tweetLeftDataRecordCounter =
scopedStatsReceiver.counter("tweetLeftDataRecord")
lazy val tweetRightDataRecordCounter =
scopedStatsReceiver.counter("tweetRightDataRecord")
lazy val tweetMergeNumFeaturesCounter =
scopedStatsReceiver.counter("tweetMergeNumFeatures")

@transient lazy val featureStoreClient: FeatureStoreClient =
FeatureStoreUtils.mkFeatureStoreClient(
serviceIdentifier = jobConfig.serviceIdentifier,
statsReceiver = scopedStatsReceiver
)

Is Twitter tracking left/right leaning? I would bet the farm on it that they are tracking those stats and more.

And that is my point, regardless of what this specific code segment does.
 
Based on the link to the code you posted, this seems to be the code segment that he based his "AuthorRight" and "AuthorLeft" hypothesis. I have no idea what this code does.

I can tell you what it doesn't do: it doesn't track left/right political leaning.


And that is my point, regardless of what this specific code segment does.

Twitter basically without a doubt is tracking political leaning. It's just not doing it in the code segments posted here.
 
[h=1]Twitter Abandons Free Speech, Folds to New European Union Censorship Regulations[/h]

https://bigleaguepolitics.com/twitt...to-new-european-union-censorship-regulations/

Twitter allowed EU goons into its company headquarters last week to train their staff on how to restrict free speech under the guise of preventing Russian propaganda, fake news and criminal activity..

Nothing says Democracy and Free Speech while they are trying censor the other side..


The EU has being doing both of those things mentioned in the article.
Restricting Speech for EU users wont be good for twitter.
 
Last edited:
Is it possible that the day after his acquisition with an apparently plummeting audience that there was already an all time high? Was there not a huge number of Bot accounts? If half the users were not real users and you turned them off and added one new member wouldn't you have an all time high?


With EU's push for European Union Censorship Regulations on twitter i would expect that twitter will be facing plummeting audience again.

The EU is becoming a regime.
 
Back
Top