jakebsky

Sorry about that. You definitely should have received a waitlist invite. We did invite everyone on the waitlist before launching. The deliverability of those emails was quite high but it's possible it went to the spam folder or something else went wrong.

Something like 1 million of the users that joined came from the waitlist.

Most users on HN are probably able to navigate using a domain handle, which is really the recommended and most decentralized option.

https://bsky.social/about/blog/4-28-2023-domain-handle-tutor...

Martin Kleppman is a technical advisor to Bluesky but his real job is as a researcher in distributed systems and security at the University of Cambridge. He also wrote Designing Data-Intensive Applications, which many of us on the team have been fans of for years.

Sorry about this. We've just made some changes to make this less likely of an issue going forward.

Nope, it's not a requirement for other PDS operators.

Netscape created the first highly usable web browser, which introduced most people to the web. They also created SSL (TLS), JavaScript, the first high performance web server, and much more that that made the web go.

The SMS verification requirement is only for the Bluesky operated PDS host. Soon (this month) it will be possible for others to self-host their own PDS hosts that do not have this requirement.

We've announced one business model and do intend to iterate and add others, but that's all we've announced for now. The plan is definitely to be sustainable over the long-term.

We'll see! The history of funded companies popularizing open protocols is not without precedent. I'm inspired by Netscape, which was the VC-backed company that made the web happen.

There has been some work by others already on this front: https://docs.bsky.app/blog/feature-bridgyfed

Yes, every part of the Bluesky (atproto) network is composable, including moderation (labeling).

Understandable! We hope to relax this but we felt it was necessary to maintain the quality of the network for now.

Bluesky is in good financial shape for quite some time based on existing funding. And we're also working hard to be sustainable, which we believe is entirely feasible given our small team. But we're also ensuring that everything required to make the network sustainable over time is completely open.

A Relay (we used to call it the BGS) crawls all of the PDS hosts on the network and aggregates the data. This makes it possible for services to subscribe to all events on the network without putting load on PDS hosts directly.

Anyone can run a Relay. They're somewhat comparable to Linux distribution FTP/HTTP mirrors.

Bluesky will always run a Relay, but other organizations will hopefully as well. We expect these might be organizations doing other things in the ecosystem, universities, and possibly open consortiums.

Threads has been promising to integrate with ActivityPub since it launched. To date they've done very little and their timeline extends until the end of 2024.

I'd personally be very happy if Threads gives up control over their users but it remains to be seen. ActivityPub also lacks the very strong account portability feature that made AT Protocol necessary.

AT Protocol is completely open source and the Bluesky network is completely open. The Bluesky network has had an open API for a year with full access to all public data (no auth required):

    websocat wss://bsky.network/xrpc/com.atproto.sync.subscribeRepos

More info on: https://atproto.com

1. "Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements."

https://atproto.com/guides/faq

2. Jack Dorsey is on the board but has no day-to-day role in the company. Jay Graber is the CEO of Bluesky and is in control. The protocol is also designed not to require trust. The network is being "locked open" in a way that would allow it to survive Bluesky becoming evil.

3. Bluesky has a different approach in many ways. One of the biggest differences is that Bluesky is (IMHO) the first decentralized social network that is highly usable by regular non-technical users.

There is some work by others to make this possible:

https://docs.bsky.app/blog/feature-bridgyfed

This is a big milestone for Bluesky!

We've had the federation sandbox running for over six months but we're now able to commit to open federation on the production network this month as well. There's also stackable moderation coming shortly, which enables other individuals/orgs to operate moderation labeling services that users can choose to use.

The technical challenges of setting up an (efficiently) scalable decentralized social network were quite interesting. The infrastructure itself is quite decentralized, with standalone PDS instances and two small shared-nothing datacenter PoPs. We're using SQLite with millions of individual databases for each user's repository and ScyllaDB for the global indexing service (AppView).

https://bsky.social/about/blog/5-5-2023-federation-architect...

If anyone has questions, technical or otherwise, some of the team should be around today to answer them.

Edit: HN'ers might also appreciate this paper written primarily by Martin Kleppman about Bluesky and AT Protocol

https://arxiv.org/pdf/2402.03239.pdf

Sorry about that. The team is very small and quite busy, and we've been doing everything manually. But as of last week we have someone that can dedicate time to recruiting using a proper applicant tracking system. Our process should be improving a lot.

Bluesky Social, PBC | Backend Developer | Full-time | Remote (US timezone overlap)

+ Scale our existing services to millions of users

+ Develop and maintain the AT Protocol implementation (See: atproto.com)

+ Create SDK and API tools for an ecosystem of protocol developers

+ Have experience with TypeScript and/or Go

+ Have a strong knowledge of data structures and software design principles

+ Have built scalable and high-performance server-side applications

Our tech stack includes TypeScript, Go, ScyllaDB, SQLite, Redis, memcached, Protobufs/gRPC.

To apply, email recruiting@blueskyweb.xyz with:

+ A resume or CV (link or PDF)

+ A cover letter that tells us why you care and how you can contribute (link or PDF)

+ A link to your GitHub, GitLab, or a portfolio of past work

More details: https://blueskyweb.xyz/join/backend-developer

(For HN users, optionally feel free to CC jake+recruiting@blueskyweb.xyz and I'll try to take a look.)

We're using SQLite in production with millions of databases with many millions of operations per day. It's been nothing but great, as has always been my experience using SQLite.

But we did run into some scariness around trying to use Litestream that put me off it for the time being. Litestream is really cool (and I'm a big fan of its author!) but it is also very much a cool hack in the way it works.

The scariness I ran into was related to this issue https://github.com/benbjohnson/litestream/issues/510

And after a bit more fiddling I came away nervous about the possibility of corruption, which is not something I want to worry about from my backup method.

So for now we're just doing regular snapshotting with remote backups and that seems sufficient with RAID1 storage. I would like something lower latency at some point but don't have the time at the moment to work on it.

Running this code on an "on-prem" AMD EPYC 9454P with 12 x 64 GB DIMMs:

  1 37.4
  2 73.3
  3 107.3
  4 141.4
  5 171.6
  6 199.5
  7 226.0
  8 251.1
  9 235.4
  10 243.0
  11 264.5
  12 281.9
  13 303.7
  14 323.0
  15 339.6
  16 354.4
  17 299.0
  18 286.3
  19 300.9
  20 310.6
  21 325.7
  22 339.2
  23 352.6
  24 364.3
  25 305.8
  26 309.0
  27 319.6
  28 326.5
  29 335.4
  30 345.5
  31 356.7
  32 364.9

And then it settles around there.

You definitely could but it's pretty technically involved and not as easy as it will be in the future. And it would have to be siloed off from the production Bluesky/atproto network at the moment.

Typically invites are used by people who are inviting people they know, in which case it's advantageous for them to be able to find each other.

But you're right that there's an argument that it could work differently. We're planning to get rid of invites shortly, otherwise we might consider enhancements to the invite system to e.g. make this optional.

Yup, you could. Although connecting your own PDS hosts to the Bluesky production network won't be possible for a little while longer. Creating custom algorithms (feeds) is already possible, as it participating in the developer sandbox network, including PDS hosting.

The architecture is explained briefly here: https://blueskyweb.xyz/blog/5-5-2023-federation-architecture

Code/docs are here:

1. AT Protocol (atproto) is documented here: https://atproto.com

2. App Web/Android/iOS app: https://github.com/bluesky-social/social-app

3. API (AppView) and PDS (Personal Data Server): https://github.com/bluesky-social/atproto

4. The Relay (formerly BGS) https://github.com/bluesky-social/indigo

5. Custom algorithm (Feed Generator): https://github.com/bluesky-social/feed-generator

6. Sandbox PDS distribution: https://github.com/bluesky-social/pds/blob/main/SANDBOX.md

Sent you an email, in case you're willing to give some info we can use to investigate this. We're always willing to look into any issues like this. Thanks!

Thank you! And yeah, the goal is to bring an open social media protocol to everyone in a way that feels familiar and easy. The social media problems we face are societal and most of society is non-technical.

The domain situation is unfortunate and confusing. We don't have any immediate solution but agree it's a problem.

Yeah, that's right. The production network's data layer (Personal Data Servers) are architecturally federated now (i.e. there are multiple PDS hosts) but still operated by a single organization (Bluesky Social, PBC), so it's still centralized.

The goal in early 2024 is to enable federation with other PDS hosts, so that users can choose where they keep their data (posts, likes, preferences, etc).

The protocol that the Bluesky app is built on, atproto[1], is designed to support other social modes. The Bluesky app is in some ways "just" a reference implementation of microblogging, created to ensure the protocol actually works for users and developers.

In early 2024, when the production network is federated, it will be possible to build new social apps on atproto that the millions of existing Bluesky users will be able to use (if they choose) without having to create a new account.

1. https://atproto.com

There is still a waitlist but we're working hard to open things up ASAP. Some people will never believe it, but the waitlist was never intended as a growth hack. It was purely an attempt to keep the network healthy and the servers from catching on fire as we iterated on the app itself.

For devs that want to experiment, we've had a special waitlist for a while: https://atproto.com/blog/call-for-developers

In the early days, Twitter used to have a very open and friendly API. It's a big part of why users and third-party devs (I was both) loved it. Same thing was true of Facebook and Reddit.

Over time, they shut down their APIs (or charged huge fees) in an effort to intentionally kill off third-party clients and services.

A key goal for Bluesky is to "lock open" the network and the API so that it's impossible to reverse the decision.