Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When imperfect systems are good: Bluesky's lossy timelines

jazco.dev

Post reply on HN
Print view View original

231–240 of 315 posts

Re: When imperfect systems are good: Bluesky's lossy timelines

#231

Post by genewitch »

VWWHFSfQ wrote: post #175
pornel wrote: post #146

I wonder why timelines aren't implemented as a hybrid gather-scatter choosing strategy depending on account popularity (a combination of fan-out to followers and a lazy fetch of popular followed accounts when follower's timeline is served). When you have a celebrity account, instead of fanning out every message to millions of followers' timelines, it would be cheaper to do nothing when the celebrity posts, and later…

At some point they'll end up just doing the Bieber rack [1]. It's when a shard becomes so hot that it just has to be its own thing entirely. [1] - https://www.themarysue.com/twitter-justin-bieber-servers/ @bluesky devs, don't feel ashamed for doing this. It's exactly how to scale these kinds of extreme cases.

I've stood up machines for this before I did not know they had a name, and I worked at the mouse company and my parking spot was two over from a J. Beibe'rs spot.

So now we have Slashdot effect, HN hug, and its not Clarkson its... Stephen Fry effect? Maybe can be Cross-Discipline - there's a term for when lots of UK turns their kettles on at the same time.

I should make a blog post to record all the ones I can remember.

Re: When imperfect systems are good: Bluesky's lossy timelines

#232

Post by rsynnott »

pornel wrote: post #146

I wonder why timelines aren't implemented as a hybrid gather-scatter choosing strategy depending on account popularity (a combination of fan-out to followers and a lazy fetch of popular followed accounts when follower's timeline is served). When you have a celebrity account, instead of fanning out every message to millions of followers' timelines, it would be cheaper to do nothing when the celebrity posts, and later…

> and later when serving each follower's timeline, fetch the celebrity's posts and merge them into the timeline

I think then you still have the 'weird user who follows hundreds of thousands of people' problem, just at read time instead of write time. It's unclear that this is _better_, though, yeah, caching might help. But if you follow every celeb on Bluesky (and I guarantee you this user exists) you'd be looking at fetching and merging _thousands_ of timelines (again, I suppose you could just throw up your hands and say "not doing that", and just skip most or all of the celebs for problem users).

Given the nature of the service, making read predictably cheap and writes potentially expensive (which seems to be the way they've gone) seems like a defensible practice.

Re: When imperfect systems are good: Bluesky's lossy timelines

#233

Post by immibis »

NetOpWibby wrote: post #198
ChuckMcM wrote: post #135

Earlier quoted context omitted.

That's the correct answer, IBM wanted the crawler mostly to feed Watson. Building a full search engine (crawler, indexer, ranker, API, web application) for the English language was a hell of an accomplishment but by the time Blekko was acquired Google was paying out tens of billions of dollars to people to send them and only them their search queries. For a service that nominally has to live on advertising revenue ge…

Blekko was gone by the time I learned about it. Recently (past few years) I emailed someone who worked on Blekko to get his opinion on a search engine concept I still have yet to start. His advice was to not bother competing with Google (obviously) LOL! I don’t know if anyone’s embarked on a P2P search engine but that’s essentially my concept. Anyhoo, thanks for the inspiration!

Darknet Lantern is a decentralized searchable directory. It's probably not going to take off, but it could inspire something else. Servers spider other servers with the same software, and synchronized their data.

Re: When imperfect systems are good: Bluesky's lossy timelines

#234

Post by bitbckt »

Brystephor wrote: post #205
rubslopes wrote: post #155

Earlier quoted context omitted.

This problem is discussed in the beginning of the Designing Data-Intensive Applications book. It's worth a read!

Do you know the name of the problem or strategy used for solving the problem? I'd be interested in looking it up! I own DDIA but after a few chapters of how database work behind the scenes, I begin to fall asleep. I have trouble understanding how to apply the knowledge to my work but this seems like a useful thing with a more clear application.

Yes, we used the Yahoo! “Feeding Frenzy” paper as the basis for the design of Haplocheirus (the timeline service).

Re: When imperfect systems are good: Bluesky's lossy timelines

#235

Post by christkv »

rsynnott wrote: post #232
pornel wrote: post #146

I wonder why timelines aren't implemented as a hybrid gather-scatter choosing strategy depending on account popularity (a combination of fan-out to followers and a lazy fetch of popular followed accounts when follower's timeline is served). When you have a celebrity account, instead of fanning out every message to millions of followers' timelines, it would be cheaper to do nothing when the celebrity posts, and later…

> and later when serving each follower's timeline, fetch the celebrity's posts and merge them into the timeline I think then you still have the 'weird user who follows hundreds of thousands of people' problem, just at read time instead of write time. It's unclear that this is _better_, though, yeah, caching might help. But if you follow every celeb on Bluesky (and I guarantee you this user exists) you'd be looking at…

You might mix the approaches based on some cut off point

Re: When imperfect systems are good: Bluesky's lossy timelines

#236

Post by immibis »

jarjoura wrote: post #79
autobodie wrote: post #24

Earlier quoted context omitted.

Absolutely. The profit motive is the root of most evil. It is a shame that so many are trained to believe it is the only motive available.

There's no reason Bluesky has emulate what FB Newsfeed and Twitter/X did to solve engagement by promoting certain items over others. At the very least, they do have hindsight to learn from.

There's the profit motive. It's funded by venture capital, so it has to grow at all costs (check) and then cash out.

Re: When imperfect systems are good: Bluesky's lossy timelines

#237

Post by bitbckt »

VWWHFSfQ wrote: post #175
pornel wrote: post #146

I wonder why timelines aren't implemented as a hybrid gather-scatter choosing strategy depending on account popularity (a combination of fan-out to followers and a lazy fetch of popular followed accounts when follower's timeline is served). When you have a celebrity account, instead of fanning out every message to millions of followers' timelines, it would be cheaper to do nothing when the celebrity posts, and later…

At some point they'll end up just doing the Bieber rack [1]. It's when a shard becomes so hot that it just has to be its own thing entirely. [1] - https://www.themarysue.com/twitter-justin-bieber-servers/ @bluesky devs, don't feel ashamed for doing this. It's exactly how to scale these kinds of extreme cases.

We never actually had a literal “Bieber Box”, but the joke took off.

Hot shards were definitely an issue, though.

Re: When imperfect systems are good: Bluesky's lossy timelines

#238

Post by immibis »

bbor wrote: post #68
cyberax wrote: post #60

Earlier quoted context omitted.

On the other hand, running something like BlueSky is not terribly expensive. A foundation with a reasonable endowment can do that indefinitely. Initially, it can be funded by selling tools that do analytics or by donations (like Wikipedia).

Yes! If the venture capitalists that are already involved stick to their stated principles and don't demand eternal growth (which... fingers crossed?), I think bsky has an extremely feasible, promising future. They've intentionally kept a low footprint to keep expenses down, and while income via donation is out of the picture (unless AT Proto grows into a full ecosystem, I suppose?), cosmetics are a tried-and-true mo…

This is hardly the first instance of "if only venture capitalists light their money on fire, we can have nice things."

Spoiler: Venture capitalists don't light their money on fire, and we can't have nice things.

Re: When imperfect systems are good: Bluesky's lossy timelines

#239

Post by mapt »

Beretta_Vexee wrote: post #227
dsauerbrun wrote: post #213

I'm a bit confused. The lossy timeline solution basically means you skip updating the feed for some people who are above the number of reasonable followers. I get that Seeing them get 96% improvements is insane, does that mean they have a ton of users following an unreasonable number of people or do they just have a very low number for reasonable followers. I doubt it's the latter since that would mean a lot of peopl…

> does that mean they have a ton of users following an unreasonable number of people Look at the accounts of OnlyFans models, crypto influencers, etc. They follow thousands or even tens of thousands of accounts in the hope that we will follow them in return.

I don't see that accommodating this behavior is prosocial or technically desirable.

Can you think of a use case?

All sorts of bots want this sort of access, but whether there are legitimate reasons to grant it to them on a non-sharded basis is another question since a lot of these queries do not scale resources with O(n) even on a centralized server architecture.

Re: When imperfect systems are good: Bluesky's lossy timelines

#240

Post by immibis »

verdverm wrote: post #185
immibis wrote: post #123

Earlier quoted context omitted.

So after you're banned from Bluesky you create another account on a different server and hope the admins of your original server, which still hosts all the people you want to follow, don't block your new account from interacting with their server? You said it was different from Mastodon, but how is this different from Mastodon?

I have my own domain already attached, I can point it at any server and my identity on the network remains the same. When you use a *.bsky.social handle, you have not made yourself independent and resilient to arbitrary decision by the org that manages that service

So that's the same as on Mastodon. What's the difference again?
Post reply on HN