One of the most important tools for trust and safety efforts is the “block” feature, allowing a user to entirely block someone else from following them. Yes, on Twitter you can get around this by g…
It’s interesting to me that they made the argument that blocking is increasing server costs.
How is that even possible, on a technical level?
If true, how is changing to a “stronger mute” going to reduce said costs?
I mean, it’s plainly clear that Musk has no idea what is going on at any of his companies and the narrative of him being a genius of some kind was simply that: a narrative.
In a way, I could imagine it increasing server costs by like 0.001%, if even that, because if the algorithm finds a post to recommend but then realises it’s from a blocked account, it would have to search again (ofc it’s probably optimised so that it realises that at an earlier stage).
But we’re talking about such small details it literally doesn’t matter and is outweighed by the functionality lost one hundredfold.
I expect it’s accurate to say; their architecture is not like a database where you can add an index on a blocked state and then join against it. You have to get a list of potential posts that the user might want to see and then eliminate any in the block list. There will be a few edge case users who have thousands of block entries and a multithreading strategy is likely required to swiftly filter it in a reasonable timeframe.
However, an architecture I’ve seen that works around this is to build this timeline in the background and present it to the user from a cache, I don’t know if this is what Twitter does as I never worked on that. However, if you want to not have a block feature but have some kind of mute feature anyway I don’t see how there is a meaningful difference.
It’s interesting to me that they made the argument that blocking is increasing server costs.
I mean, it’s plainly clear that Musk has no idea what is going on at any of his companies and the narrative of him being a genius of some kind was simply that: a narrative.
In a way, I could imagine it increasing server costs by like 0.001%, if even that, because if the algorithm finds a post to recommend but then realises it’s from a blocked account, it would have to search again (ofc it’s probably optimised so that it realises that at an earlier stage).
But we’re talking about such small details it literally doesn’t matter and is outweighed by the functionality lost one hundredfold.
I expect it’s accurate to say; their architecture is not like a database where you can add an index on a blocked state and then join against it. You have to get a list of potential posts that the user might want to see and then eliminate any in the block list. There will be a few edge case users who have thousands of block entries and a multithreading strategy is likely required to swiftly filter it in a reasonable timeframe.
However, an architecture I’ve seen that works around this is to build this timeline in the background and present it to the user from a cache, I don’t know if this is what Twitter does as I never worked on that. However, if you want to not have a block feature but have some kind of mute feature anyway I don’t see how there is a meaningful difference.
Yeah, sounds like that’s the case. Funny how flaws in system architecture gets exposed to the public through vapid excuses these days.
My guess is muting would likely result in a decrease of overall visibility. Every account gets a mute score.