Feels like there should be great things possible with the firehose; there’s just so much there and there have to be some more ways to discover, say, people and posts with some niche interest you share.
Also—and maybe the comment about building appviews at the end is pointing in the same direction—it’s just an impossibly tempting puzzle, sorting out how to scale an app like this. Just recently learned that Bluesky pushes posts to followers’ timelines when they’re posted, after they were pulled on read during its early days. Later there could be some hybrid where pull is used for, say, posts from the most-followed accounts, or maybe the first timeline load when a long-offline user comes back.
It’s been neat to see how, with all the growth, a smallish team has managed to keep the thing working!
Granted, but I have mixed emotions about it. The ActivityPub ecosystem has the best of intentions, but some of it’s technical foundations were a bit shaky initially. The atproto stuff has some quality engineering, but the folks running the company have every incentive to enshittify.
i truly hate to be the one to say “not really federated yet” but bluesky literally just passed one year since opening to public signup. 31M users talking to a single backend is such a tremendous read load (feedgen, push or pull, is on read side) that IMO it’s almost unrelated to atproto-vs-activitypub architecture.
Bluesky PBC’s appview is built for this load, so it’s not easy to stand up a copy to self-host, but also that wouldn’t make sense because any alternative host isn’t going to have 31M-user read load to deal with.
edit (i hit “post” too soon): honestly you might be right, i just think it takes a while to build things, and it’s been like only a few months since bluesky got major traction.
Feels like there should be great things possible with the firehose; there’s just so much there and there have to be some more ways to discover, say, people and posts with some niche interest you share.
Also—and maybe the comment about building appviews at the end is pointing in the same direction—it’s just an impossibly tempting puzzle, sorting out how to scale an app like this. Just recently learned that Bluesky pushes posts to followers’ timelines when they’re posted, after they were pulled on read during its early days. Later there could be some hybrid where pull is used for, say, posts from the most-followed accounts, or maybe the first timeline load when a long-offline user comes back.
It’s been neat to see how, with all the growth, a smallish team has managed to keep the thing working!
I feel that people having this feeling actually betrays the fact that BlueSky is not really a federated platform.
Granted, but I have mixed emotions about it. The ActivityPub ecosystem has the best of intentions, but some of it’s technical foundations were a bit shaky initially. The atproto stuff has some quality engineering, but the folks running the company have every incentive to enshittify.
i truly hate to be the one to say “not really federated yet” but bluesky literally just passed one year since opening to public signup. 31M users talking to a single backend is such a tremendous read load (feedgen, push or pull, is on read side) that IMO it’s almost unrelated to atproto-vs-activitypub architecture.
Bluesky PBC’s appview is built for this load, so it’s not easy to stand up a copy to self-host, but also that wouldn’t make sense because any alternative host isn’t going to have 31M-user read load to deal with.
edit (i hit “post” too soon): honestly you might be right, i just think it takes a while to build things, and it’s been like only a few months since bluesky got major traction.