Upcoming Relay Transition
In coming days we are finally going to transition the bsky.network firehose endpoint to a newer relay implementation. This should not have a significant impact on most consumers.
More specifically, we are tagetting the morning Tuesday, January 27th (US/Pacific timezone). The bsky.network firehose will be switched from the narelay.pop2.bsky.network relay instance to the relay1.us-west.bsky.network relay instance.
This transition was previously announced but postponed until now. The majority of Bluesky internal services transitioned to the new relay instances in the past week.
How will this impact relay consumers?
If you are connected to the bsky.network hostname, your websocket connection may drop, and the cursor sequence will jump forward by a significant delta. If your client implements auto-reconnection, no manual intervention should be necessary, and impact should be minimal.
It is likely that some events will be duplicated with new (higher) sequence numbers. The per-account revision (rev) field can be used to de-duplicate events at the account level. For many use-cases (such as bots, feed generators, etc), re-processing a small number of events should not be problematic.
The backfill window of the bsky.network instance should reflect what is seen on the firehose. That is, reconnecting with an "old" (lower) cursor value should not result in replaying the full "new relay" 72 hour backfill window. This is because an intermediate service (rainbow) is inserted between the relay backend and the public endpoint.
Operators can implement the transition on their own schedule by connecting directly to specific relay instances:
narelay.pop2.bsky.networkis the current relay behindbsky.network. It has been in operation since Fall 2024 and runs the older "bigsky" implementation. The current sequence is around17502400000(aka, 17 billion). This instance will be shut down a week or two after the transition.relay1.us-west.bsky.networkwill be the new relay behindbsky.network. The current sequence is around26653242499(aka, 26 billion).relay1.us-east.bsky.networkis an alternative relay running in a separate data center. The current sequence is around26653242087(aka, 26 billion).
Note that the east/west sequence numbers are similar (because they started at the same time), but are not identical. The content is very similar (they are both full-network relays), but are not seamlessly interchangeable.
What about Jetstream Consumers?
Jetstream uses timestamp cursors, so no observable cursor jump will happen. Consumers may see a small number of duplicate/replay events around the transition.
How will this impact PDS hosts?
There should not be any noticeable impact from this transition. The new relay instances have already been consuming from all PDS hosts for many months, "request crawl" messages are mirrored, and rate limits have been synchronized between old and new relay instances.
The new relay implementation does include support for string verification of "MST inversion proofs", part of the Sync 1.1 protocol changes. However, strict verificaiton will still be disabled for now.
We do intent to enable strict MST verification in the near future. The reference PDS implementation has included the required changes for some time. We will monitor which PDS instances and implementations might be impacted and work with developers and operators before making that change, and will make public announcements ahead of time.
Why are we doing this?
The new relay includes support for Sync 1.1 protocol features, such as the #sync message type and additional metadata supporting "MST inversion". It also fixes a handful of bugs that have caused operational problems with individual PDS implementations.
The new implementation also removes a huge amount of deprecated code related to "archival" relay operation and indexing of record data in the relay itself. It should be easier to maintain and develop new features for the relay going forward, including smarter rate-limiting and resolving connection issues with upstream PDS instances.