And no mention of what happens to their API but knowing google it either goes away entirely or totally changes with significant rework required.

Related, the reason I no longer use any google API: https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc

I don’t see a problem so long as they do so in good faith - for example publishing full event contents to ActivityPub instead of adding a link back to the Facebook Threads app, which is basically what a lot of news sites do with their RSS feeds to get advertising money.

So long as they do that, it’s not really possible to do a rug-pull. There are far more Facebook users than Fediverse users after all, so it’s going to be advertising for the Fediverse for as long as this lasts and if users would like to remain part of it they’ll have to move to another server. That is, assuming it ends.

To answer the question though, I don’t care for microblogging personally and I don’t like Meta as a company so I won’t use it. I appreciate the scepticism but I feel optimistic.

Well, they want to do something and he wants them to not do it so he is the enemy and must be destroyed. I’ve seen this in many companies over the years.

What frustrates me is that nobody from that side is telling the truth: Third party developers were once useful but are now a liability and they have to go because a future buyer or investor will not understand the value of a vibrant development community and see something that cannot be controlled. The timeline for the IPO is ticking down and there is no time to come up with a way to formally integrate these clients, either by buyout or agreeing some sort of advertisement or subscription SDK. It’s unpleasant but I’d have more respect for the truth than lying and slandering the character of a good guy in the process.

Thank goodness he had recordings or this could have been career limiting for him, not that this occurred to the people with dollar signs in their eyes.

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.

Haha, that’s a throwback to the days when I helped to manage a phpBB board and there were a few members that would just continuously get into arguments so I edited the database so both of them had each other on their block list. It was very telling when I discovered they unblocked each other a few weeks later and got back to arguing and derailing thread topics.