Note that all of this reflects design decisions on Bluesky's closed-source "AppView" server—any federated servers interacting with Bluesky would need to construct their own timelines, and do not get the benefit of the work described here.
My thinking has evolved on this topic significantly as of late. My current thinking is we should create a secure gossip network on top of the Bluesky API, and forgot about all the DAG-CBOR stuff that gets stripped from the Jetstream. Hash the posts on the gossip layer and if posts change then diff them. This is all prep for when X billionaire buys out Bluesky then we just pop some signing key crypto on top of this go…
When imperfect systems are good: Bluesky's lossy timelines
101–110 of 315 posts
Re: When imperfect systems are good: Bluesky's lossy timelines
#102So the system design puts the burden on what seems to be synchronous, not queued, writes to get easy reads. I usually prefer simpler cheaper writes at the cost of more complicated reads as the reads scale and parallelize better.
Re: When imperfect systems are good: Bluesky's lossy timelines
#103Earlier quoted context omitted.
Does the fact that an airline booking system must be perfect explain why so many flights are overbooked or cancelled?
No, overbooking is a business decision justified by the fact that, statistically, not all passengers will actually show up for their flight, and lower load factors cost money.
Re: When imperfect systems are good: Bluesky's lossy timelines
#104When I go directly to a user's profile and see all their posts, sometimes one of their posts isn't in my timeline where it should be. I follow less than 100 users on Bluesky, but I guess this explains why I occasionally don't see a user's post in my timeline. Lossy indeed.
Various clients (I’m writing one) interpret the timeline differently, as a feed that shows literally everything includes could things that most people would find undesirable or irrelevant. (replies to strangers, replies to replies to replies, etc)
Re: When imperfect systems are good: Bluesky's lossy timelines
#105As a systems enthusiast I enjoy articles like this. It is really easy to get into the mindset of "this must be perfect". In the Blekko search engine back end we built an index that was 'eventually consistent' which allowed updates to the index to be propagated to the user facing index more quickly, at the expense that two users doing the exact same query would get slightly different results. If they kept doing those…
I guess I hadn’t considered that search engines could be reranking pages on the fly as I click them. I’ve been seeing my DuckDuckGo results shuffle around for a while now thinking it’s an awful bug. Like I click one page, don’t find what I want, and go back thinking “no, I want that other result that was below” and it’s an entirely different page with shuffled results, missing the one that I think might have been goo…
On top of that immediate frustration, the YouTube style interface here
https://marvelpresentssalo.com/wp-content/uploads/2015/09/id...
collects terrible data for recommendations because, even though it gives them information that you liked the thumbnail for a video, they can't come to any conclusion about whether or not you liked any of the other videos. TikTok, by focusing on one video at a time, collects much better information.
Re: When imperfect systems are good: Bluesky's lossy timelines
#106This design makes sense if you didn’t previously have any limit on the number of people an account could follow. But why not have a limit?
Re: When imperfect systems are good: Bluesky's lossy timelines
#107Earlier quoted context omitted.
My thinking has evolved on this topic significantly as of late. My current thinking is we should create a secure gossip network on top of the Bluesky API, and forgot about all the DAG-CBOR stuff that gets stripped from the Jetstream. Hash the posts on the gossip layer and if posts change then diff them. This is all prep for when X billionaire buys out Bluesky then we just pop some signing key crypto on top of this go…
isnt that ssb?
Re: When imperfect systems are good: Bluesky's lossy timelines
#108As a systems enthusiast I enjoy articles like this. It is really easy to get into the mindset of "this must be perfect". In the Blekko search engine back end we built an index that was 'eventually consistent' which allowed updates to the index to be propagated to the user facing index more quickly, at the expense that two users doing the exact same query would get slightly different results. If they kept doing those…
I guess I hadn’t considered that search engines could be reranking pages on the fly as I click them. I’ve been seeing my DuckDuckGo results shuffle around for a while now thinking it’s an awful bug. Like I click one page, don’t find what I want, and go back thinking “no, I want that other result that was below” and it’s an entirely different page with shuffled results, missing the one that I think might have been goo…
Re: When imperfect systems are good: Bluesky's lossy timelines
#109Anyone following hundreds of thousands of users is obviously a bot account scraping content. I'd ban them and call it a day. However, I do love reading about the technical challenge. I think Twitter has a special architecture for celebrities with millions of followers. Given Bluesky is a quasi-clone, I wonder why they did not follow in these footsteps.
Or just enforce a maximum number of followed accounts.