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

11–20 of 315 posts

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

#11

Post by verdverm »

VectorLock wrote: post #8
amazingamazing wrote: post #4

Earlier quoted context omitted.

I don’t understand the infatuation with blue sky. The minute they need money it’ll go the way of the Reddit and twitter.

People seem to lark on and on about how it has better "default moderation" than Mastodon.

It's not that it is "better" but that the choice is individual, not up to the mastodon server. In Mastodon, you trade Elon for some other group of individuals, so what happens if they make decision on moderation or content you do not agree with?

ATProto is designed around accounts that are independent of data host, application, and moderation, all in the name of giving users individual control over these things. It's like if every Mastodon user ran their own server, but without the overhead

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

#12

Post by verdverm »

xrisk wrote: post #3
nightpool wrote: post #2

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.

What reason does Bluesky give for not opening up their AppView code? Another notable component that is closed source is the discovery feed generator, where at least there is some reason.

The App View frontend is open source: https://github.com/bluesky-social/social-app

Much of the backend is open source as well: https://github.com/bluesky-social/atproto/tree/main/packages

What is not are the extra services they run to provide a better and faster UX. Even if it was open source, it likely costs 10s of thousands to run per month (they have moved largely to "onprem" hardware instead of the cloud aiui)

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

#14

Post by dingnuts »

xrisk wrote: post #3
nightpool wrote: post #2

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.

What reason does Bluesky give for not opening up their AppView code? Another notable component that is closed source is the discovery feed generator, where at least there is some reason.

when I read the spec it seemed like the operator of an AppView & Relay would be most in need of compensation for their hosting costs due to the amount of demand on those components so I believe the spec allows an operator to implement their own AppView & monetize it as that operator sees fit, so that they can afford to operate the service and maybe even make money off of it so that they can make it their full time jobs.

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

#15

Post by iameli »

xrisk wrote: post #3
nightpool wrote: post #2

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.

What reason does Bluesky give for not opening up their AppView code? Another notable component that is closed source is the discovery feed generator, where at least there is some reason.

I asked this and got

> We did a backend rewrite from postgres to scylla and it has a bunch of deployment specific stuff, but is functionally identical to the open source postgres version. Its not really a "v2" in terms of new features, we just made it make use of our hardware really well[1]

[1]: https://bsky.app/profile/iame.li/post/3l7e3jfqit22s

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

#16

Post by VectorLock »

verdverm wrote: post #11
VectorLock wrote: post #8

Earlier quoted context omitted.

People seem to lark on and on about how it has better "default moderation" than Mastodon.

It's not that it is "better" but that the choice is individual, not up to the mastodon server. In Mastodon, you trade Elon for some other group of individuals, so what happens if they make decision on moderation or content you do not agree with? ATProto is designed around accounts that are independent of data host, application, and moderation, all in the name of giving users individual control over these things. It's…

>It's like if every Mastodon user ran their own server

No, it's like every Mastodon user used the same server, and all the coordination is done by one server that nobody can replicate.

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

#17

Post by haileyok »

nightpool wrote: post #2

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.

This is not true. Third party PDSes are fully supported by our app view, and our app view generates timelines for all the users on those PDSes.

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

#18

Post by treyd »

Larrikin wrote: post #7
amazingamazing wrote: post #4

Earlier quoted context omitted.

I don’t understand the infatuation with blue sky. The minute they need money it’ll go the way of the Reddit and twitter.

If everything good is assumed to eventually become bad, why not use things while they are good and then immediately move on when it becomes bad?

Not everything good becomes bad. That premise is wrong.

Bluesky accepted VC money. For a social platform that means its death certificate has already been signed.

What you're ignoring with that framing is that we can use social media that operates outside the VC startup pipeline and doesn't have enshittification baked in from the start.

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

#19

Post by bitmasher9 »

It’s really impressive how well Bluesky is performing. It really feels like a throwback to older social media platforms with its simplicity and lack of dark-patterns. I’m concerned that all the great work on the platform, protocol, etc won’t shine in the long term as they eventually need to find a revenue source.

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

#20

Post by pfraze »

nightpool wrote: post #2

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.

As others have noted, the appview is open source. The dataplane has two implementations, one in postgres and another in scylla. The scylla dataplane is closed, the postgres one is open.

The interesting next stage for the postgres implementation is to create a sync engine for partial syncs of the network, so that an appview can run affordably. We ran some benches on the current state of the postgres implementation and found we could index 300k users on a $100/mo vps. I think with a couple of weeks of optimization that could reach 1mm users.

Post reply on HN