iiinova — where your digital self keeps evolving

fig (aka:[phil]) @bad-example.com · 22/09/2026

thanks! took two tries (needed the https:// prefix for it to think it was a url) but got it to work!

sifa.id's company input box with "microcosm.blue" in the input. under it:

"x not linked to a company page", then a results section with

- "MICROCOSME: Analyse, ingénierie et controle des micro-organismes / FR - part of Inria Grenoble-Rhone-Alpes researche centre"
- Wrong match, or not listed? Type the company's website to add it. How it works
- Use 'microcosm.blue' as typed

fig (aka:[phil]) @bad-example.com · 17/09/2026

@brookie.blog my habit of cramming multiple dense charts into a single image makes fitting in the pckt alt text limit hard :( (bsky alt limit is 2k fwiw)

screenshot of pckt's alt text editor, with a tiny preview of a dense three-chart image, some clipped alt text in the input field, and `2045/1000` characters used.

1140

fig (aka:[phil]) @bad-example.com · 14/09/2026

taking suggestions for a thumbnail image to go with this

050

fig (aka:[phil]) @bad-example.com · 10/09/2026

final count for the ufos-week: 25,277 broke 25k!

same chart as the replied-to-post, but the final pink bar (this just-finished week by ufos' intervals) is taller. it's now notably higher than all previous peaks.

090

fig (aka:[phil]) @bad-example.com · 06/09/2026

efficient network backfill is a scheduling problem, exhibit 3520 (power distributions rule everything around me)

two grafana line charts over a 2-day time window, both showing repo-export-requests and records-exported.

normally these series are tightly correlated, but i the screenshot they significantly diverge.

in both charts, requests is green and records exported is blue.

chart 1: rates. the action starts about 1/3 of the way in: records exported jumps way up, sustaining around 1.4M/sec around the peak, then drops way down. requests is almost the inverse: it rises slowly while records is soaring, and then jumps *way* up to ~600/sec when records drops to ~200k/sec. there's another short event near the end where request rate drops while record export rate briefly spikes.

chart 2: cumulative counts for each over the time period, showing the divergence-then-convergence: records exported accelerates to a steep slope while requests grows slowly, then both inflect oppositely with records becoming a shallow ramp and requests rising much more rapidly. by the end, there have been about 30M requests and about 60B records exported.

requests/sec and records exported/sec has two series displayed

y-axis-1: green series, 200 GET /xrpc/com.atproto.sync.getRepo:

y-axis-2, blue series, records exported (star-lite):
some noise at the start, then a period near zero, then some steady 20/sec time, then a jump to 250 req/sec, then around 500 req/sec, before falling rapidly to 100/sec nand slowly decaying to ~40/sec. there is one spike near the end to around 300/sec.

1330

fig (aka:[phil]) @bad-example.com · 06/09/2026

record: broken. 21.7K unique identities have published non-bluesky data so far this week, the most ever. (and we're less than halfway through the ufos-week)

weekly active non-bluesky users (with data updates)

same as the quoted chart, except the final pink bar (current week) is now the tallest, and its tooltip shows the count (21698 active excl bsky 2026-09-03)

69511

fig (aka:[phil]) @bad-example.com · 06/09/2026

oooooo ya we're only like three days into this ufos-week, and on track to blow past the non-bsky weekly-actives record

weekly active non-bluesky users (with data updates)

the first half (april 2025–jan 2026) is boring and low apart from a weird 14k spike near the end. mostly under 5k wau, dipping under 2.4k.

it then ramps up and settles around 10k wau, with the atmosphereconf 2026 week highlighted in orange (right around 10k).

things stay basically stable (/verrry slow growth) through much of 2026, with a few outlier weeks more recently, one of which finally exceeds 20k wau.

the final bar, highlighted in pink and labelled "bsky38" is almost at 20k, despite this "week" starting on sept 3rd.

1150

fig (aka:[phil]) @bad-example.com · 27/08/2026

huh, yikes at bsky's svg conversion original: upload.wikimedia.org/wikipedia/co...

same as the last image, but actually readable

1131

fig (aka:[phil]) @bad-example.com · 27/08/2026

some space things have good names. some space things are called - large zenith telescope - large binocular telescope - multiple mirrors telescope - thirty meter telescope - very large telescope - extremely large telescope - overwhelmingly large telescope - five hundred meter aperture telescope

$source (+ full description): https://en.wikipedia.org/wiki/File:Comparison_optical_telescope_primary_mirrors.svg Comparison of nominal sizes of primary mirrors of notable optical reflecting telescopes, and a few other objects. Largest refractors (for comparison): 1) Yerkes Observatory's 40-inch (1.02 m) refractor, 1893 2) Great Paris Exhibition Telescope, 49 inches (1.24 m), 1900 Ground-based reflectors: 3) Hooker Telescope, 100 inches (2.54 m), 1917 4) Multiple Mirror Telescope, 186 inches (4.72 m) effective, 1979–1998; 6.5 m, from 1998 5) LAMOST (Large Sky Area Multi-Object Fiber Spectroscopic Telescope), 4.9 m effective at best, 2009 6) Hale Telescope, 200 inches (5.1 m), 1949 7) BTA-6, 6 m, 1975 8) Large Zenith Telescope, 6 m, 2003 9) Magellan Telescopes, two 6.5‑m individual telescopes, 2000 and 2002; 10) Vera C. Rubin Observatory, 6.68 m effective (8.4‑m mirror, but with a big hole in the middle), planned 2025 11) Gemini Observatory, 8.1 m, 1999 and 2001 12) Subaru Telescope, 8.2 m, 1999; largest monolithic mirror in an optical telescope from 1999 to 2005 13) Southern African Large Telescope, 9.2 m effective, 2005 14) Hobby–Eberly Telescope, 10 m effective, 1996 15) Gran Telescopio Canarias, 10.4 m, 2007 16) Large Binocular Telescope, 11.8 m effective, 2005 and 2006 17) Keck Telescopes, 14 m effective, 1993 and 1996 18) Very Large Telescope, 16.4 m effective (four 8.2 m individual telescopes), 1998, 1999, 2000, and 2000 19) Giant Magellan Telescope, 22.0 m effective, planned for early 2030s 20) Thirty Meter Telescope, 30 m effective, planned 21) Extremely Large Telescope, 39.3 m effective, planned 2028 22) Overwhelmingly Large Telescope, 100 m, cancelled Space telescopes: 23) Gaia, 1.45 m × 0.5 m, 2013 24) Kepler, 1.4 m, 2009 25) Hubble Space Telescope, 2.4 m, 1990 26) James Webb Space Telescope, 6.5 m effective, 2022 Other objects for comparison: 29) Human height, 1.77 m on average 30) Tennis court, 23.77 × 10.97 m 31) Basketball court, 28.7 × 15.2 m$

5413

fig (aka:[phil]) @bad-example.com · 18/08/2026

wow fake news. (or, secrets revealed..)

photo of a tv with two characters walking by a car, subtitled:

> No way it’s a coincidence Hubble was a currency manager

1121

fig (aka:[phil]) @bad-example.com · 17/08/2026

u can tesselate these but i’m rusty

a three winged paper thing. spiralled ridges of curved folds. the most visible face kind of looks like a shark fin?

061

fig (aka:[phil]) @bad-example.com · 14/08/2026

the non-bsky atmosphere is still small but it's not shrinking orange bar: atmosphereconf 2026

weekly active non-bluesky users (with data updates)

a sad decay for the first half, then a very large short spike, then fast growth toward the atmosphereconf week. after that it's pretty steady and holds high with slight growth, with two recent outlier weeks much higher.

lexicon groups with >10 weekly active users

steady growth from ~30 to ~75 by atmosphereconf. post-conf it accelerated a bit: we're just shy of 150 now.

210019

fig (aka:[phil]) @bad-example.com · 12/08/2026

4h16m for full backfill but only storing `app.bsky.graph.*`, which is closer to the actual lower bound over gigabit. 150G on disk (lz4 not zstd stored, this machine could just barely keep up with gigabit download rate).

requests/sec and records exported/sec

both jump up to a steady rate and then drop -- 200 GET /xrpc/com.atproto.sync.getRepo to 2.6k req/sec, and records exported to 1.6M/sec.

4311

fig (aka:[phil]) @bad-example.com · 12/08/2026

to whom it may concern: if you want to send 1.5k req/sec at constellation, DM me! we can work something out, right now you're mostly getting 429s.

gateway total inbound request rate (stacked)

two series, both constellation (gateway / gateway2)

the baseline trend is a bit under 250 req/sec, but there are huge spikes: two around 1.5k/sec, two more around 1k/sec, and other two under 750/sec

graph covers around 3h

5391

fig (aka:[phil]) @bad-example.com · 12/08/2026

media time exporting a repo (under 1M records/sec export load): 2.7ms. under 50ms at 99th (star-lite format, sue me. zstd-6 on this box)

getRepo export seconds

p0.5: 2.71ms, very stable
p0.9: slightly more
p0.95: steady just under 10ms
p0.99: just over 40ms

0150

fig (aka:[phil]) @bad-example.com · 11/08/2026

u can just backfill the whole network from hubble to a cheap vps (plus block storage) in 7h6m

four line charts: imported records/sec hovers *just* below 1M, very steady; repos/sec is a bit over 1.5k/sec but under 1.75k/sec, in-flight is flat at 128, and "up" (missing title) is 1 for just over 7h then back to 0.

68610

fig (aka:[phil]) @bad-example.com · 08/08/2026

u can just backfill the network from scratch in 26h

8 charts over 26h. the charts have roughly three phases.

actors working: mostly ScheduledResync, though there's a steady bar of identity resolve work until the final phase. the resync work starts very noisy but kinda roughly decreasing in the first phase, then rises in the second, then drops ~linearly in the third

host registry lookup & actor resolve: pending and resolved are just big noisy spikes in the first phase. they stabilize in the second with `pending` holding steady high, and hit/resolved rising. in the third phase `pending` drops to zero and resolved/hit come down ~linearly toward zero.

records added: phase 1 is high volume, over 600k/sec, slightly reducing. phase two and three is a fast drop and exponential decay toward zero.

resync scheduler dispatches: noisy rise in phase 1, steady rise from a slightly reduced starting place reaching over 800/sec in phase 2, linear drop toward zero in phase three

resync outcomes: like the last one but for "synced" outcomes. there's a bit of visible noise near the bottom for "spurious" but not much.

block bytes resynced (stacked): starts over 192MB/sec, steady slow slight decrease in phase 1. phase 2 and three follow the same decay shape as records added. there are two series, ingest_sst starts as the dominant one, but the volume steadily shifts toward batched_put, which makes up most of the decay tail.

resync scheduler ready hosts: same shape as resync outcomes and resync scheduler dispatches, except that its first section is more steady at under 100 and level until the phase 3 linear drop toward zero.

resync phases: not very interesting (or obvious what it means). some "drain" at the start that goes to zero early. "request" starts higher and reduces without hitting zero but then stays steady near it. "limit wait" starts high, goes low, then goes higher and steady to the end.

31366

fig (aka:[phil]) @bad-example.com · 07/08/2026

going to *try* to get this out by the nyc community day (@kandake.africa idk if you still need this but it's happening)

screenshot of an offprint draft:

Build an atproto social graph: Mutuals
A hubble-sync data service tutorial

Hubble-sync is a new sync library for atproto in rust, made for making the kinds of Big Indexing services that microcosm builds and runs, like constellation, lightrail, and Hubble.

[construction icon]: hubble-sync is new as in new-new! its interfaces *will* change across releases as it approaches 1.0. right now, hubble itself is the only service actually _using_ hubble-sync so far, so by following this tutorial, you'll be among the first!

1230

fig (aka:[phil]) @bad-example.com · 05/08/2026

HANG ON we hit THREE THOUSAND pdses this week?? 3k pdses in the atmosphere!

pds connections line chart: relay 3 climbing slowly over 90 days, peaking at 3000 two days ago

514117

fig (aka:[phil]) @bad-example.com · 05/08/2026

@eurosky.social's exports are pretty fast and hubble only slightly beats it. but with a thumb on the scale hubble can *9x* it (hubble picks zstd vs eurosky's slow gzip, exports in STAR-lite instead of CAR)

code » curl -o /dev/null 'https://eurosky.social/xrpc/com.atproto.sync.getRepo?did=did:plc:[redacted]' -H 'Accept-Encoding: zstd, gzip'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 54.7M 0 54.7M 0 0 6188k 0 --:--:-- 0:00:09 --:--:-- 6714k
code » curl -o /dev/null 'https://hubble.microcosm.blue/xrpc/com.atproto.sync.getRepo?did=[redacted]' -H 'Accept-Encoding: zstd, gzip' -H 'Accept: application/x.microcosm.star-lite'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 20.7M 0 20.7M 0 0 10.8M 0 --:--:-- 0:00:01 --:--:-- 10.8M

180

fig (aka:[phil]) @bad-example.com · 05/08/2026

jerry is surprisingly quick from the bsky pds! (hubble still gets 2.3x on it though :) )

code » curl -o /dev/null 'https://shiitake.us-east.host.bsky.network/xrpc/com.atproto.sync.getRepo?did=did:plc:vc7f4oafdgxsihk4cry2xpze'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 178M 0 178M 0 0 8671k 0 --:--:-- 0:00:21 --:--:-- 9807k
code » curl -o /dev/null 'https://hubble.microcosm.blue/xrpc/com.atproto.sync.getRepo?did=did:plc:vc7f4oafdgxsihk4cry2xpze'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 178M 0 178M 0 0 19.5M 0 --:--:-- 0:00:09 --:--:-- 25.5M

160

fig (aka:[phil]) @bad-example.com · 05/08/2026

The KTP Test hubble exports @katie.bzky.team 3.1x faster than bluesky's reference pds deployment (bad wifi mostly caps how much faster hubble can be here. plus hubble is also an ocean away vs bsky's us-east geographic advantage to me)

same deal as the last post but with a different DID, different bsky pds host, and different timings

bsky pds: inkcap.us-east
bsky timing: 2m34s (3365k/s average)
hubble timing: 49s (10.1M/s average)

screenshotted text:

code » curl -o /dev/null 'https://inkcap.us-east.host.bsky.network/xrpc/com.atproto.sync.getRepo?did=did:plc:ywbm3iywnhzep3ckt6efhoh7'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 508M 0 508M 0 0 3365k 0 --:--:-- 0:02:34 --:--:-- 3115k
code » curl -o /dev/null 'https://hubble.microcosm.blue/xrpc/com.atproto.sync.getRepo?did=did:plc:ywbm3iywnhzep3ckt6efhoh7'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 508M 0 508M 0 0 10.1M 0 --:--:-- 0:00:49 --:--:-- 9.9M

2311

fig (aka:[phil]) @bad-example.com · 05/08/2026

The Paul Test hubble exports @pfrazee.com 2.4x faster than bluesky's reference pds deployment cold cache, no compression, bad laptop wifi

annotated terminal output: two curl commands, one to morel.us-east.host.bsky.network (bsky.network underlined), the other to hubble.microcosm.blue (also underlined), both making the same `com.atproto.sync.getRepo` request for pfrazee's DID

bsky's export took 22 seconds; hubble's 9s. a "2.4x" hand-written annotation is on the right.

raw terminal text:

code » curl -o /dev/null 'https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getRepo?did=did:plc:ragtjsm2j2vknwkz3zp4oxrd'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 75.5M 0 75.5M 0 0 3496k 0 --:--:-- 0:00:22 --:--:-- 3586k
code » curl -o /dev/null 'https://hubble.microcosm.blue/xrpc/com.atproto.sync.getRepo?did=did:plc:ragtjsm2j2vknwkz3zp4oxrd'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 75.5M 0 75.5M 0 0 8033k 0 --:--:-- 0:00:09 --:--:-- 9.8M

5673

fig (aka:[phil]) @bad-example.com · 31/07/2026

...i made a little tool to check the commit object signature in an atproto repository CAR microcosm.tngl.io/car-commit-o...

1370

fig (aka:[phil]) @bad-example.com · 30/07/2026

forgot i made metrics by record counts for this too: 1.33M records/sec exported to STAR-lite almost 700K/sec exported as CARs (again this is limited by 1gbit/sec network egress, though STAR-lite is also *much* cheaper to produce)

requests/sec and records exported/sec

the green series (req/sec) roughly traces the peaks of the two other series:

blue: car records exported. early peak around 700k/sec, some higher and lower, then back to zero (testing CARs finished)

orange: star-lite records exported. has starts after CARs, reaches 1.33M in the first high peak, and 1.3M in the second, then drops to zero (testing finished)

1140

fig (aka:[phil]) @bad-example.com · 29/07/2026

here is what hubble gets up to on a read-heavy workload sha256 is the mst reconstruction (we have to recompute all CIDs currently) to export a CAR miniz_oxide is gzipping CARs for the http response ZSTD is reading bottom-level SSTs

Samples: 322K
31.77%: hubble sha2::sha256::compress256
21.67%: hubble miniz_oxide::deflate::core::compress_inner
8.8%: hubble miniz_oxide::deflate::core::flush_block
4.07%: libc.so.6: some 0x000000... address??
2.85%: hubble ZSTD_decompressSequence_bmi2.constprop.0
1.92%: [kernel] kernel_init_pages
1.35% libc.so.6: another long unnamed address
1.04%: [kernel] do_user_addr_fault
0.96%: _raw_spin_unlock_irqrestore
0.79%: rep_movs_alternative
0.48%: hubble malloc

050

fig (aka:[phil]) @bad-example.com · 29/07/2026

ever wonder who's doing sync1.1 backfill retries on repos that haven't been available to export? (but now areeeeee muah ha ha)

1 Mozilla/5.0 (compatible; Infrawatch/1.0; +https://infrawat.ch/)
1 atproto-backfill-search/0.0.1
1 tap/v0.0.0-20260311160737-4f4
1 tap/v0.0tap/v0.0.0-20260311160737-4f47add43060-rev-4f47add
4 bluesky-modlist-research-target-snapshot/0.1
7 tap/v0.0.0-20260629160527-dfe5578fd537-rev-dfe5578
7 zig/0.16.0 (std.http)
206 go/atmos
780 microcosm lightrail/v0.1.2, https://tangled.org/microcosm.blue/lightrail
949 tap/devel
2499 tap/v0.0.0-20260311160737-4f47add43060-rev-4f47add

2100

fig (aka:[phil]) @bad-example.com · 28/07/2026

lil hint at halfway-ready... 19M currently-somewhat-special records from 32k somewhat-special accounts take only a few GB on disk with hubble so far...

screenshot of [redacted]-hubble.microcosm.blue/xrp/com.bad-ex[clipped]

JSON response, with some pink annotations:

"synchronized: 32160" annotated "DONE"

"desynchronized:" and "desynchronized_by_reason.first_seen" both 32111 and annotated "TODO"

all other fields are zero: out_of_scope, deactivated, gone; all other desynchronized-by-reason fields: app_requested, came_into_scope, firehose_account_desync, firehose_account_throttled, firehose_fail, firehose_sync, future_rev, sync11_lax, throttled, unresolvable_identity.

070

fig (aka:[phil]) @bad-example.com · 22/07/2026

waow 50% less memory for a mimalloc -> jemalloc swap (yes that is under-3G-rss while backfilling)

hubble memory rss

flat at 6G until just after 10:55, then a small gap, then it picks up at around 3G with an initial small rise, drop, and then probably stabilization at just under 3G

5600

fig (aka:[phil]) @bad-example.com · 21/07/2026

concurrency? yeah we got that (same machine)

actors working (stacked)

a very spiky busy chart, y-axis 0–over 1000 over 3 hours. a "ScheduledResync" (purple) task dominates, but a lot of "Firehose#commit" can be seen underneath. "Bootstrap#wake" makes up most of the rest, with some smaller things also happening but which are harder to make out.

0140

fig (aka:[phil]) @bad-example.com · 21/07/2026

hubble-sync doing full-network (full-content!) backfill on a lil 4 core 8GiB machine, using less than 4GiB 😌

hubble memory rss (line chart)

a slightly noisy line that initially has some peaks just over 4GiB, but tapers slightly to staying between 3 and less than 4GiB

over about 3 hours

3523

fig (aka:[phil]) @bad-example.com · 14/07/2026

nothin just watching the backfill go by (single pds upstream for chiller vibes)

3382

fig (aka:[phil]) @bad-example.com · 03/07/2026

i am assembling a team

$use jacquard_axum::{ExtractXrpc, XrpcErrorResponse}; use jacquard_common::xrpc::XrpcError; use hubble_sync::{AccountStatus, CommitObject, Did}; use rocksdb::{IteratorMode, ReadOptions}; use star_lite::{CarBuilder, ConvertOptions};$

2600

fig (aka:[phil]) @bad-example.com · 24/06/2026

OOOHHHHhoho today is my DAY!!! i have a mild obsession with this central word, because it as an ABSURD number of different meanings

1140

fig (aka:[phil]) @bad-example.com · 16/06/2026

the most anti-climactic code i've ever written

// 6. check the commit's prevData against ours
if commit.prev != self.prev {
return Sync11Outcome::Desync;
}

070

fig (aka:[phil]) @bad-example.com · 11/06/2026

ooohhhh yeah baby that's microcosm powering your mu.social verifications hehehe

screen crop of mu.social on a eurosky.social post with verification badge shown: the network tab is open, with details of a request:

Host: constellation.microcosm.blue
Filename: /xrpc/blue.microcosm.links.getBacklinks
--
source: app.bsky.graph.verification:subject
subject: did:plc:ooensn4mr5mhznzypvxelfa3

3807

fig (aka:[phil]) @bad-example.com · 11/06/2026

in my apply-for-things era 💅

not accepted
not accepted
not accepted
deadline missed
submitted

3460

fig (aka:[phil]) @bad-example.com · 08/06/2026

one neat thing about atproto’s merkle search trees with tid rkeys is that you get large, very stable subtrees. from some analysis i did on this last fall: more than 80% of layer-4 mst nodes tend to survive more than two months (active users) >90% for layer 3

sample 1: 20MB -> 21MB CAR snapshots

70-day survival rate

records (54,436): 99.97% (-14)
layer 0 (10,217): 99.82% (-18)
layer 1 ( 2,501): 99.32% (-17)
layer 2 ( 622): 97.75% (-14)
layer 3 ( 177): 94.92% (- 9)
layer 4 ( 39): 82.05% (- 7)
layer 5 ( 9): 66.67% (- 3)
layer 6 ( 2): 0.00%
layer 7 ( 1): 0.00%

ignored ( 888): 99.14% (- 4)

170