fig (aka:[phil])
@bad-example.com
art and transistors, they/them plant-mom building community infra
🌌 constellation.microcosm.blue
🚒 relay.fire.hose.cam jetstream.fire.hose.cam
🛸 UFOs.microcosm.blue
🎇 spacedust.microcosm.blue
📚 plc.wtf
🛰️ slingshot.microcosm.blue
🌌 constellation.microcosm.blue
🚒 relay.fire.hose.cam jetstream.fire.hose.cam
🛸 UFOs.microcosm.blue
🎇 spacedust.microcosm.blue
📚 plc.wtf
🛰️ slingshot.microcosm.blue
Pinned
fig (aka:[phil])
@bad-example.com
· Apr 21
…but for real, you can help keep this alive if you want:
github.com/sponsors/uni...
ko-fi.com/bad_example
github.com/sponsors/uni...
ko-fi.com/bad_example
Reposted by fig (aka:[phil])
hey we're really working on permissioned data! read the first in a series of posts i'll be doing about our design decisions along the way. this one is about our decision to not do an e2ee system
Permissioned Data Diary 1: To Encrypt or Not to Encrypt
The first in a series of posts about major design decisions along the way to a permissioned data protocol for atproto.
dholms.leaflet.pub
February 11, 2026 at 4:15 PM
hey we're really working on permissioned data! read the first in a series of posts i'll be doing about our design decisions along the way. this one is about our decision to not do an e2ee system
averaged a bit over 5 seconds per second (this is the old (slow) write path but on a ~fast box)
February 11, 2026 at 9:25 PM
averaged a bit over 5 seconds per second (this is the old (slow) write path but on a ~fast box)
those are a bit more common. prod constellation is still on jetstream, but indigo/cmd/relay uses the same websocket server library (gorilla)
February 11, 2026 at 8:13 PM
those are a bit more common. prod constellation is still on jetstream, but indigo/cmd/relay uses the same websocket server library (gorilla)
errors from tungstenite are handled but panics are not (since they're definitely not expected) which leaves constellation with a dead consumer. it takes down the no-events-received reconnect timeout with it.
...the bit that might be related is the need for that no-events-received reconnect though
...the bit that might be related is the need for that no-events-received reconnect though
February 11, 2026 at 8:11 PM
errors from tungstenite are handled but panics are not (since they're definitely not expected) which leaves constellation with a dead consumer. it takes down the no-events-received reconnect timeout with it.
...the bit that might be related is the need for that no-events-received reconnect though
...the bit that might be related is the need for that no-events-received reconnect though
feel you but it *might* have been something different here. there's a weird bug path in rust tungstenite around setting up the socket's blocking mode, which occurs very very rarely on reconnect.
zombie here is then due to a second-level constellation bug because/
zombie here is then due to a second-level constellation bug because/
February 11, 2026 at 8:09 PM
feel you but it *might* have been something different here. there's a weird bug path in rust tungstenite around setting up the socket's blocking mode, which occurs very very rarely on reconnect.
zombie here is then due to a second-level constellation bug because/
zombie here is then due to a second-level constellation bug because/
Reposted by fig (aka:[phil])
Service note: the primary constellation instance got stuck in a zombie websocket state around 1am EST, which caused it to stop indexing new content.
API calls are currently redirected to the secondary instance which is up-to-date.
(and the primary just finished catching up as I was writing this)
API calls are currently redirected to the secondary instance which is up-to-date.
(and the primary just finished catching up as I was writing this)
yeah sorry! i meant to fail-over and post an update but got distracted -- it is _nearly_ caught up already at this point though
February 11, 2026 at 4:39 PM
Service note: the primary constellation instance got stuck in a zombie websocket state around 1am EST, which caused it to stop indexing new content.
API calls are currently redirected to the secondary instance which is up-to-date.
(and the primary just finished catching up as I was writing this)
API calls are currently redirected to the secondary instance which is up-to-date.
(and the primary just finished catching up as I was writing this)
swapped the catching-up host to backup, calls should be up to date again
February 11, 2026 at 4:33 PM
swapped the catching-up host to backup, calls should be up to date again
yeah sorry! i meant to fail-over and post an update but got distracted -- it is _nearly_ caught up already at this point though
February 11, 2026 at 4:30 PM
yeah sorry! i meant to fail-over and post an update but got distracted -- it is _nearly_ caught up already at this point though
shipping this sooooooon
🚰 hydrate constellation XRPC endpoints (of course!!)
here: one single request(!) fetching all @tangled.org issue *records* (actual records! not just links!) with the "good-first-issue" label, via constellation's many-to-many xrpc
here: one single request(!) fetching all @tangled.org issue *records* (actual records! not just links!) with the "good-first-issue" label, via constellation's many-to-many xrpc
February 11, 2026 at 12:14 AM
shipping this sooooooon
Reposted by fig (aka:[phil])
Open Collections are here 🌱
A new way to collaboratively curate content in the Atmosphere 🎨
Read on to learn more about how they work 👇
A new way to collaboratively curate content in the Atmosphere 🎨
Read on to learn more about how they work 👇
February 10, 2026 at 9:06 PM
Open Collections are here 🌱
A new way to collaboratively curate content in the Atmosphere 🎨
Read on to learn more about how they work 👇
A new way to collaboratively curate content in the Atmosphere 🎨
Read on to learn more about how they work 👇
Reposted by fig (aka:[phil])
All details in leaflet: notes.cosmik.network/3mejtzath722t
Lab Notes #006: Open Collections and Community Stewardship - Cosmik Labs
Details on our first step towards supporting community stewardship and collaborative curation
notes.cosmik.network
February 10, 2026 at 9:06 PM
All details in leaflet: notes.cosmik.network/3mejtzath722t
thinking through the upcoming many-to-many (non-aggregated) constellation query
![fun case: multiple links from m2m records, like app.bsky.feed.post:facets[..].features[..#mention]
in quotes: "who was tagged in the replies?"
boxes and arrows with additional arrows added from path_to_other for m2m 1 (to other B) and m2m 3 (to a new other subject, C)
the output summary purple box-rows now have
m2m record 1 | other subject A
m2m record 1 | other subject B
m2m record 2 | other subject A
m2m record 3 | other subject B
m2m record 3 | other subject C](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:hdhoaan3xa3jiuq4fg4mefid/bafkreibxgbdq7h2alasx5efay6rbjwycthsgm7i5jjdhqozdso3sb74slu@jpeg)
![loopy case: same-source links, like app.bsky.feed.post:facets[..].features[..#mention] (again)
in quotes: "who am i tagged with in replies?"
instead of a stack of green "other subject" boxes on the right, two other subjects ("X" and "Y") are now in blue below the main subject
every m2m record now points back a second to the main subject from its path_to_other, while m2m records 2 and three also point to other subject X and Y, respectively
the output summary purple box-rows now have
m2m record 1 | subject
m2m record 2 | subject
m2m record 2 | other subject X
m2m record 3 | subject
m2m record 3 | other subject Y](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:hdhoaan3xa3jiuq4fg4mefid/bafkreie65mculhn4g6bqujgietc77ozdqyi4gs5nmmd6qwmac5hbmahbbi@jpeg)
February 10, 2026 at 9:09 PM
thinking through the upcoming many-to-many (non-aggregated) constellation query
bsky relay gets an advantage because i believe PDSs will auto-re-request-crawl if activity happens after a long time (maybe with some awareness of whether the relay stated connected? not sure)
anyway here's two days of the connected client decay over the 4h reconnect cycle on both microcosm relays
anyway here's two days of the connected client decay over the 4h reconnect cycle on both microcosm relays
February 10, 2026 at 5:40 PM
bsky relay gets an advantage because i believe PDSs will auto-re-request-crawl if activity happens after a long time (maybe with some awareness of whether the relay stated connected? not sure)
anyway here's two days of the connected client decay over the 4h reconnect cycle on both microcosm relays
anyway here's two days of the connected client decay over the 4h reconnect cycle on both microcosm relays
i'm not positive about it, but many hosts definitely drop off if i don't frequently drive the reconnects
February 10, 2026 at 5:35 PM
i'm not positive about it, but many hosts definitely drop off if i don't frequently drive the reconnects
pushed a tiny fix for tranquil pds on debug.hose.cam
the debugger now shows `version` from the pds `describeServer` if present, falling back on the `_health` endpoint (for bsky pds impl) and no longer failing if the response at _health is not a JSON object
the debugger now shows `version` from the pds `describeServer` if present, falling back on the `_health` endpoint (for bsky pds impl) and no longer failing if the response at _health is not a JSON object
atproto PDS & account debugger
Quick diagnostics for PDS hosts, handles, relay connections, handles, DIDs, ...
debug.hose.cam
February 10, 2026 at 4:35 PM
pushed a tiny fix for tranquil pds on debug.hose.cam
the debugger now shows `version` from the pds `describeServer` if present, falling back on the `_health` endpoint (for bsky pds impl) and no longer failing if the response at _health is not a JSON object
the debugger now shows `version` from the pds `describeServer` if present, falling back on the `_health` endpoint (for bsky pds impl) and no longer failing if the response at _health is not a JSON object
i still need to catch up on what other operators like sri and dane have already been setting up for new tooling, there have been some good discussions save initial work already :)
February 10, 2026 at 2:03 PM
i still need to catch up on what other operators like sri and dane have already been setting up for new tooling, there have been some good discussions save initial work already :)
so, with that as context for the original q:
- the relay dashboard is pretty good for keeping an eye on things at a granular level
- lots of useful prometheus metrics are exported to make high level dashboards and alerting off of
- mary’s scraping is load-bearing for microcosm’s pds discovery
- the relay dashboard is pretty good for keeping an eye on things at a granular level
- lots of useful prometheus metrics are exported to make high level dashboards and alerting off of
- mary’s scraping is load-bearing for microcosm’s pds discovery
February 10, 2026 at 2:01 PM
so, with that as context for the original q:
- the relay dashboard is pretty good for keeping an eye on things at a granular level
- lots of useful prometheus metrics are exported to make high level dashboards and alerting off of
- mary’s scraping is load-bearing for microcosm’s pds discovery
- the relay dashboard is pretty good for keeping an eye on things at a granular level
- lots of useful prometheus metrics are exported to make high level dashboards and alerting off of
- mary’s scraping is load-bearing for microcosm’s pds discovery
bsky only updated their prod relays to sync1.1 like a week or two ago, and there’s still more on that sync iteration to do. all that to say personally i expect changes, but not fast, and it’s still a good moment if you have ideas to share them.
February 10, 2026 at 1:58 PM
bsky only updated their prod relays to sync1.1 like a week or two ago, and there’s still more on that sync iteration to do. all that to say personally i expect changes, but not fast, and it’s still a good moment if you have ideas to share them.
i believe pds/relay discovery is a consciously underdeveloped part of the protocol, long term plan is to evolve it, but the specifics (and maybe even some of the direction?) aren’t set.
lots of good ideas have been discussed, many tradeoffs
lots of good ideas have been discussed, many tradeoffs
February 10, 2026 at 1:54 PM
i believe pds/relay discovery is a consciously underdeveloped part of the protocol, long term plan is to evolve it, but the specifics (and maybe even some of the direction?) aren’t set.
lots of good ideas have been discussed, many tradeoffs
lots of good ideas have been discussed, many tradeoffs
Reposted by fig (aka:[phil])
そろそろこっちでも晒しておくか。atproto.com和訳、感想募集中。 https://github.com/yamarten/atproto-website/pull/1
February 10, 2026 at 1:51 AM
そろそろこっちでも晒しておくか。atproto.com和訳、感想募集中。 https://github.com/yamarten/atproto-website/pull/1
(and i do not at all mean to trivialize that own-your-own-data is a huge and really really important thing in general)
February 9, 2026 at 4:26 PM
(and i do not at all mean to trivialize that own-your-own-data is a huge and really really important thing in general)
yep. and like, your content being community-bound is the *most* understandable thing imo because that’s how everything has always worked anyway.
i believe you can still do the other atproto tricks
- move your PDS around
- use an alt client
here
i believe you can still do the other atproto tricks
- move your PDS around
- use an alt client
here
February 9, 2026 at 4:24 PM
yep. and like, your content being community-bound is the *most* understandable thing imo because that’s how everything has always worked anyway.
i believe you can still do the other atproto tricks
- move your PDS around
- use an alt client
here
i believe you can still do the other atproto tricks
- move your PDS around
- use an alt client
here
i haven't gone deep into it yet but my assumption is that the public CID binds *some representation* of the private stored content. so when you get access to the private stuff, you can re-serialize + compute the same CID by following the same rules (may or may not be the same as normal record CID)
February 9, 2026 at 4:07 PM
i haven't gone deep into it yet but my assumption is that the public CID binds *some representation* of the private stored content. so when you get access to the private stuff, you can re-serialize + compute the same CID by following the same rules (may or may not be the same as normal record CID)
yeah that's my outsider feeling as well. it has trade-offs but it seems pragmatic, thoughtful with counter-balances, and works (like, works today)
February 9, 2026 at 4:05 PM
yeah that's my outsider feeling as well. it has trade-offs but it seems pragmatic, thoughtful with counter-balances, and works (like, works today)