#atproto devs! have two new specification drafts up. first is "Data Synchronization", covering the firehose: [github.com/bluesky-soci...](
GitHub
specs: Sync (including firehose) by bnewbold · Pull Request #375 · bluesky-social/atproto-website
This finally puts the firehose (com.atproto.sync.subscribeRepos event stream) into the actual atproto specs, at least in current form. This documen...
 ) second is "Account Hosting", covering account migration and lifecycle: [github.com/bluesky-soci...](
GitHub
specs: Account Hosting by bnewbold · Pull Request #376 · bluesky-social/atproto-website
Describes account hosting lifecycle, and a short description of account migration. An earlier version of this document included additional detail o...
 )
bit of a bounce on public relay (rainbow), should be catching up now
we are looking in to problems with search indexing of some accounts. this impacts type-ahead search of handles, for example, and has been ongoing for a couple days. not any intentional suppression, just an operational bug.
#atproto devs and protocol folks! looking for feedback on options for Lexicon Resolution. we have a broad sketch, but still some open questions and truely not sure which way we are leaning [RFC: Lexicon Resolution · blue...](
GitHub
RFC: Lexicon Resolution · bluesky-social/atproto · Discussion #3074
UPDATE: Lexicon Resolution specification has been published: https://atproto.com/specs/lexicon#lexicon-publication-and-resolution One of the missin...
 )
bet a bunch of folks are curious, so a bit more transparency around firehose/relay woes: one top area of concern has been managing outbound bandwidth and noisy consumers. the rainbow system has basically solved this.
some more details on public firehose stuff: you can/should reconnect now! note that the sequence is different (lower, like 274908607-ish at the moment) if you scroll back to the start of this backfill window, consumers *should* see all events (aka, not miss anything)
it's been a rough couple hours for the firehose! it has been flapping around in volume and offset. the bsky app has been smoother because we are using an alternative internal relay (starting a couple days ago). 🧵
oh jeez, this was worse than thought. recommend folks just disconnect from firehose for a bit and we'll give the all clear soon RE:
Bluesky Social
bryan newbold (✈️ vacation/travel through mid-Jan) (@bnewbold.net)
folks consuming from firehose: we are debugging a few distinct issues caused by misconfigured rate-limits. 🧵 definitely some fraction of accoun...
 View quoted note →
folks consuming from firehose: we are debugging a few distinct issues caused by misconfigured rate-limits. 🧵 definitely some fraction of accounts created in the past 8 hours were not having events go though, or as tooBig (meaning no records on the firehose). roughly 20k accounts.
haven't tried this before, but offering a $150 bug bounty if anybody can fix this docusaurus build/deploy issue. donation to charity of choice, or via github sponsor. might need to set up a temp [render.com](
Render
Cloud Application Platform | Render
On Render, you can build, deploy, and scale your apps with unparalleled ease – from your first user to your billionth.
 ) account to debug the last issue [Docusaurus Build/Deploy Broken...](
GitHub
Docusaurus Build/Deploy Broken · Issue #246 · bluesky-social/bsky-docs
Building this site on main branch is very slow and not working at all in our deploy environment (render.com). There are at least two problems, both...
 )