71–80 of 83 posts
Earlier quoted context omitted.
I at least am contrasting > [running a relay being cheap and easy] wasn't asserted anywhere With > I recall posts of people running their own relays on RPi4s with NVMe drives I would absolutely consider software I can host at home, on a RPi, cheap and easy to self-host. That's the assertion that's being called out here. Bluesky's relays do not scale down easily, and are difficult and expensive to host
> I would absolutely consider software I can host at home, on a RPi, cheap and easy to self-host. That's expensive and difficult compared to running a PDS or appview (either of which can run with a tiny fraction of even an RPi's resources), which is exactly what I said. And to reiterate: an RPi4 with an NVMe SSD is very far off from something that's production-ready and suitable for public use. You can run your own r…
- You don’t understand what a relay does in atproto given the rest of your reply and should look.
The genie is already out of the bottle for thirty years, and it's called the open web. Luckily I don't need half the world's population to agree upon and use something that already exists out there. Keep posting on your website and keep linking. It's called the 'web' for a reason.
And demanding everyone buy and own a domain name & figure out hosting seems unviable as requirements for the world's mass communication system.
The Bluesky PDS architecture is a lovely lovely modest & small iteration on the web, adds only a bit more. To make your vault of content still addressable, still a URL, but one tied to a cryptographic identifier. And to make the content all signed and secure.
Earlier quoted context omitted.
plainly, free our feeds are grifting. the relay at this point is non-archival and can be spun up trivially. with a small sliding history window for subscriber catchup u can use like 32gb of scratch disk space and keep a few hours, the relay is literally just a subscribeRepos forwarder from PDSes. the AppView is vastly more expensive to run since you need to handle the write volume of all bsky activity. if you build a…
Re: the relay, that depends on your needs. My impression from these sorts of "run a relay on an RPi" projects is that they're only dealing with a subset of the full firehose Bluesky's relay has to deal with - be it a shorter timeline (as you mention) or only concerning themselves with specific accounts (like the relay operator's own "following" feed, in the case of someone running a personal relay) or what have you.…
- bluesky's feed gen post-dropping is about internal operation of their appview and not anything to do with network sync semantics
- if you're running an AppView for the bsky data you are likely keeping a copy of all bsky posts in a database, since fetching from PDSes on-the-fly is network intensive over a relatively small pipe, which is what i mean by write volume requirements.
I used to not care about centralized or decentralized services, I just wanted to best product. Now I see how each of the major social media networks has been involved in censorship of Israel's genocide in Palestine (including btw HN), it makes me realize how important decentralization is. I think a lot of Americans (and other countries who have essentially handed over their media to US social media companies) are goi…
Facebook is censoring pro-Palestine views? My friends must not have gotten the news.
Haven't we learned by now that approximately no one cares? Centralised services are vastly more popular than federated ones, the main reason being that they reduce the paradox / paralysis of choice when you're signing up for them. (Solve that problem properly and you may be on to something.)
Yup. Mastodon has this issue. Can’t pick a big generic instance because it could get defederated for spam/being too normie; can’t pick a small instance because it could get defederated over some ridiculous drama [1][2]. Normal people (and even some not-normal people) don’t want to deal with that. “Instances” are a bad model. [1]: https://tootworld.social/@lilythelonelygirl/1143999833553083... [2]: https://tau-ceti.sp…
Nobody is going to defederate from mastodon.social, but otherwise, this is all true.
Earlier quoted context omitted.
> I would absolutely consider software I can host at home, on a RPi, cheap and easy to self-host. That's expensive and difficult compared to running a PDS or appview (either of which can run with a tiny fraction of even an RPi's resources), which is exactly what I said. And to reiterate: an RPi4 with an NVMe SSD is very far off from something that's production-ready and suitable for public use. You can run your own r…
- A raspberry pi with a nvme drive costs 200 dollars one time. Are you seriously going to assert that is expensive? - You don’t understand what a relay does in atproto given the rest of your reply and should look.
Compared to the hardware required to run a PDS, yes, absolutely. "Expensive" is relative.
And like I've said above, a Raspberry Pi with an NVMe drive is surely a long ways off from Bluesky's own relay. It's good enough for personal needs, not for any sort of production use.
> You don’t understand what a relay does in atproto given the rest of your reply and should look.
I'd appreciate specific corrections, so that I (and anyone else reading these comments) can be better-informed.
(EDIT: my apologies for the previous version of this comment, which might've come across a bit hostile. That ain't my intention.)
Earlier quoted context omitted.
Re: the relay, that depends on your needs. My impression from these sorts of "run a relay on an RPi" projects is that they're only dealing with a subset of the full firehose Bluesky's relay has to deal with - be it a shorter timeline (as you mention) or only concerning themselves with specific accounts (like the relay operator's own "following" feed, in the case of someone running a personal relay) or what have you.…
- the relay storage volume scales only with the backfill window for consumers that drop briefly - the bluesky pbc operated relays let you reconnect up to 24h later and not miss any events but that requires around 200gb of scratch disk space -- live tailing an rpi relay without dropping a connection can give you events from the full network span (ie the complete set of the firehose) without requiring any backfill wind…
Gotcha; thanks for the clarifications/corrections. Good to know that the firehose bandwidth is a lot less than I thought (though 20Mbps can certainly add up to some hefty pricetags depending on how you're billed for traffic).
> if you're running an AppView for the bsky data you are likely keeping a copy of all bsky posts in a database, since fetching from PDSes on-the-fly is network intensive over a relatively small pipe, which is what i mean by write volume requirements.
Right, but how much of that actually needs to hit the disk? I'd imagine most appviews can readily get away with just keeping posts in RAM, and even if disk storage is desired (e.g. to avoid needing to pull everything from the PDSes if an appview server reboots), it ain't like the writes need to be synchronous or low-latency. A full-blown ACID-compliant DBMS is probably overkill.
It'd also be overkill to cache all posts, rather than subsets (e.g. each users' "Discover" and "Following" feeds), so I reckon that'd also reduce the in-appview caching needs further.