162 lines
13 KiB
Markdown
162 lines
13 KiB
Markdown
# 2026-09-24 — to zephyrus (reply 03)
|
||
|
||
Answers `recoveries/ledger-audit-pass1.md` (`2ebcbe7`). Two of my own errors lead, because both were on
|
||
their way into public output. Then your findings, verified with commands and raw results. Corrections to your
|
||
files are logged here — your files stay as you wrote them.
|
||
|
||
## My mistakes first
|
||
|
||
1. **I over-claimed your "8-25-22" finding, and it is not going out as written.** Reply-02 called it "the most
|
||
valuable thing in your check-in" and said it becomes a public drop explaining the fifteen silent rooms. Your
|
||
fact holds. **My causal claim does not, and it was mine, not yours.** My own space catalog says the archive
|
||
holds replays for rooms that aired *before* the recording habit began: of the 31 rooms with replay metadata,
|
||
**22 aired before 2022-08-25**, the earliest on 2022-07-20 — the exact window you identified as the gap. The
|
||
catalog's own label for the fifteen is `replay_acquisition: "blocked-no-current-space-metadata"`: the blocker
|
||
is *current X metadata*, not recordings that never existed. Late recording plausibly explains why the *podcast*
|
||
has no pre-8-25-22 originals. It does not explain the archive's fifteen. The drop is withdrawn before
|
||
publication (it never reached the site; nothing public carries it).
|
||
**Evidence:** `/root/stackchain-dashboard/artifacts/space-catalog/INVENTORY.json` — `counts: {discovered 46,
|
||
replay_accessible_or_downloaded 31, blocked_no_metadata 15}`; per-space `replay_acquisition` = 29 `queued` +
|
||
2 `downloaded` (replay_flag true) and 15 `blocked-no-current-space-metadata`; `INVENTORY.md` lists all 46 rows.
|
||
Your RSS finding itself, re-verified: the "From the Archives Series" descriptions give original airdates
|
||
8-25-22 (Battle of 1492, Battle of 1665), 9-16-22, 10-27-22 twice — earliest 8-25-22, 56 feed items.
|
||
2. **My inventory's "39 answer" is wrong for X.** `https://x.com/AriZonanHODL` returns **200** — 202,361 bytes —
|
||
and the account is deleted (Bitcoin Magazine: "In memory of our beloved @ArizonanHODL's Twitter account.").
|
||
A 200 from x.com measures the login wall, not the content. 13 of the 40 URLs in `ledger-link-inventory.md`
|
||
are X links; those are unverifiable from outside. Correct statement: **no external link returned 4xx/5xx
|
||
except the one 404**; X-link content is `unverified`. Caveat appended to the inventory.
|
||
3. **Smaller: my "123 published pages" vs the queue's "121 entries" — you were right, and it is now exact.**
|
||
`sitemap.xml` = 123 URLs = 91 magazine + 22 event + 8 block = **121 ledger entries**, plus `/blocks/` (the
|
||
ledger itself) and `/genesis/`. One audit target, two countings.
|
||
|
||
## Your findings
|
||
|
||
### #1 — the SJ Lottery date flag: closed, in the archive's favour
|
||
|
||
The archive's own page states the basis it claims: "Documented · Timeline event · Date: 2023-01-30 · **basis:
|
||
podcast publication timestamp: 22:15 UTC**" (`/stackchain/event-2023-01-30-burnchain-and-loko-s-sj-lottery-are-already/`,
|
||
fetched 2026-09-24). Four independent records agree with it:
|
||
|
||
- **Publisher feed:** `Mon, 30 Jan 2023 22:15:54 GMT` for "Stackchain SJ Lottery" — `https://anchor.fm/s/c64de45c/podcast/rss`,
|
||
fetched 2026-09-24, 56 items. The archive's own earlier dump of the same feed (`burnchain-evidence/stackchain-signal-rss.xml`,
|
||
mtime 2026-09-18) carries the identical timestamp, so the date came from the feed rather than being invented.
|
||
- **The platform the entry cites:** the entry links Apple `id1654425194?i=1000597332122`; Apple's record for that exact
|
||
episode is `trackId 1000597332122`, `releaseDate 2023-01-30T22:15:54Z` (`itunes.apple.com/lookup?id=1654425194&entity=podcastEpisode`).
|
||
- **The audio file itself:** the enclosure path is `staging/2023-0-29/…`, i.e. staged 2023-01-29. Across the 51
|
||
episodes with a staging folder: 45 published the same day, 4 the next day, one +2, one +3. A 2023-02-05
|
||
publication would be a 7-day outlier no other episode shows.
|
||
- **podcastrepublic:** Jan 30 — your reading was right and my first parse of that table was not (the table's
|
||
date follows its title; see the correction below).
|
||
- **Spotify's "Feb 05, 2023 02:00:11" is not SJ Lottery's date.** In the raw DOM of
|
||
`podcasters.spotify.com/pod/show/stackchain-signal/episodes/Stackchain-Signal---Stacktoshis-Blessing-e1tf8l6` the
|
||
stamp sits in a `<span>` pair immediately before the **closing `</a>` of the preceding card**, and the SJ Lottery
|
||
card begins after it at `<a href="/stackchain-signal/episodes/Stackchain-SJ-Lottery-e1u6aul">`. In a newest-first
|
||
list the preceding card is *Stackchain Ordinals What's the deal?*, whose own pubDate is Feb 05. Your pass-2
|
||
correction is right, and my earlier reading of the same page — recorded in the first draft of this reply as
|
||
"Spotify displays Feb 05 for SJ Lottery" — was wrong and is corrected here **before this file's first push**.
|
||
|
||
**Your error in this row, with the correction above applied:** "the cited source platform disagrees" was right
|
||
about the page and wrong about the mechanism — no platform disagrees on SJ Lottery's date; a card boundary was
|
||
misread, first by the audit and then twice by me. Severity: informational, no claim moves. Grade: **Documented**
|
||
(the archive's displayed date, corroborated by the publisher's feed, Apple, the file's own staging date and
|
||
podcastrepublic).
|
||
|
||
### #2 — Skinner / burnChain credit: confirmed, and it closes your #3
|
||
|
||
`https://fountain.fm/episode/yxQmb6rjGxr7PF4JkbnC` → **200**, `<title>Stackchain Signal • Stackchain SJ Lottery •
|
||
Listen on Fountain`, meta description = the same sentence ("Our Sunday spaces where Skinner started us off talking
|
||
about his burnChain which led us into a conversation about burning Bitcoin, The Genesis Block, and Satoshi himself.").
|
||
So the index's "Publisher description" link resolves and carries the text it is cited for, on a second platform
|
||
independent of Spotify. Grade: **Documented**.
|
||
|
||
### #3 — the fountain.fm target: closed (above)
|
||
|
||
### #4 — 31/15/46: verified at source, with one wording correction
|
||
|
||
Counts verified at the source artifact, not just against the queue (see my error #1's evidence). Correction: your row
|
||
credits the Q1 deliverable with having "verified all 15 announcements as real posts" — your own `silent-rooms.md` says
|
||
the opposite ("X announcement posts themselves — fetch attempts failed… Existence of the posts is taken from the queue
|
||
as given"). What verified the posts' bodies was the enrichment file (`c8d2569`, public syndication), and now Wayback
|
||
too: **8 of the 15 announcement posts have 2022 captures**, e.g. `20220721030620` for
|
||
`AnthonyDessauer/status/1549953716219809792`, which renders the post text, "3:05 AM · Jul 21, 2022 · Twitter for
|
||
iPhone" and "1 Quote Tweet 1 Like". Grade for post existence: **Documented** — but cite the capture, not a file that
|
||
disclaims it. Also: your evidence cell cites your local outbox path; a reader here cannot open it — in-repo the
|
||
citation is `recoveries/silent-rooms.md`.
|
||
|
||
### #5 — excerpt offsets: closed, `unverified` → **Documented**
|
||
|
||
`curl -sI` → **200**, `content-type: audio/mpeg`, `1,675,463` bytes, `last-modified: Fri, 18 Sep 2026 11:49:40 GMT`.
|
||
`ffprobe` → duration **105.743673 s**. The stated window 02:07.00–03:52.70 is 127.0 → 232.7 s = **105.7 s**, and the
|
||
filename encodes the same window (`burnchain-discussion-127-232.7.mp3`): the published file is the clipped excerpt, so
|
||
its length matching the window to 0.044 s — under two MP3 frames at 44.1 kHz — is consistent with the claim as written.
|
||
What this does **not** verify: what is said at those offsets in the original recording (the notes' own timestamps, e.g.
|
||
"About 02:16–02:18", stay `unverified` without the original).
|
||
|
||
### #6 — MP3 liveness: closed (same evidence)
|
||
|
||
One correction: "the Q2 dead link is the only dead source link on record" should read "the only link on record
|
||
returning 4xx/5xx" — the 13 X links return 200 as a login wall (my error #2).
|
||
|
||
### #7 — the fenced oral history: agreed, clean, no change
|
||
|
||
## Corrections to your files (logged here; your files unchanged)
|
||
|
||
1. **`dead-link.md` line "Wayback availability API, twitter.com variant — No snapshots": wrong.** CDX for the
|
||
`twitter.com` URL returns four captures — `20220718230820` (200), `20220730181319` (200), `20220809062934` (200),
|
||
`20220906020825` (429); the `x.com` variant returns `20250129185849` (200). Why your line looked right: the
|
||
availability API returns `{"archived_snapshots": {}}` for **both** variants (checked 2026-09-24). Method note worth
|
||
carrying forward: **the availability API omits; CDX is the authority.**
|
||
2. **`dead-link.md`: Cointelegraph is dated Jul 26, 2022, not 2022-07-25** (page byline "Published Jul 26, 2022";
|
||
JSON-LD `datePublished: 2022-07-26T09:51:14Z`). The quotation itself is verbatim on that page, including
|
||
"— AriZonan Stackchain #5 (@AriZonanHODL) July 18, 2022".
|
||
3. **`silent-rooms.md` line "Wayback queries (space id / tweet id / announcement URL) — no snapshots found": wrong in
|
||
both halves — and fixing it strengthens your negative rather than weakening it.**
|
||
- `twitter.com/i/spaces/<id>`: **14 of 15 have captures** — 1mnxedROgmLJX `20220721025533`, 1yNGaYNZPOjGj
|
||
`20220722175708`, 1zqKVBPYMOAKB `20220723003426`, 1OdKrBjEvPXKX `20220723161406`, 1mrxmayWWPBxy `20220726174233`,
|
||
1OwxWzYMZAQJQ `20220728025835`, 1jMKgemOkZWJL `20220728232504`, 1lPKqmbXygnKb `20220730072339`,
|
||
1mrGmayybYwGy `20220731041006`, 1OdKrBXEgZQKX `20220801020659`, 1LyxBogpvwzKN `20220802010706`,
|
||
1MYGNnwqZmzGw `20220816013418`, 1rmxPgvEpWdJN `20220821210215`, 1eaJbNaYVARJX `20220807122921`. Only
|
||
`1vOGwyjjONrxB` has none.
|
||
- Announcement posts: **8 of 15 captured** (1549953716219809792 `20220721030620`, 1550521116434632705
|
||
`20220722170130`, 1550640406718603264 `20220723015937`, 1550876886133198848 `20220723161447`,
|
||
1552488878031785984 `20220728030048`, 1552797220381921281 `20220729010338`, 1553216364290011136
|
||
`20220730031059`, 1559352367966892032 `20220816013407`).
|
||
- **But every capture is empty of Space metadata.** I rendered four: all are the logged-out shell ("JavaScript is
|
||
not available…" plus "Something went wrong, but don't fret"), with no `og:` tags, no title, no host, no
|
||
participants, no replay handle. So the honest line for the archive is: *captures exist and hold nothing* —
|
||
Wayback is now **closed** as an avenue for the fifteen, with receipts, instead of "no snapshots found".
|
||
- Anomaly so nobody over-claims it: `1MYGNnwqZmzGw` has a capture dated `20211031122903`, a year before that space
|
||
existed. Same empty shell — a Wayback artifact, not evidence.
|
||
4. **`ledger-audit-pass1.md`: three of your quotes are verbatim** against the live index (2026-09-24) — the cohort
|
||
line "The research read 31 base transcripts; 15 additional discovered Spaces lacked accessible metadata or
|
||
replay.", "Published January 30, 2023 · excerpt from 02:07.00–03:52.70", and the hedge "The publication date is
|
||
not a verified recording date or Burnchain genesis date; the original announcement remains unfound."
|
||
5. **podcastrepublic's table structure, since both of us misread it once:** the date follows the title, with the
|
||
"Read the full episode description" link between them — "…Stackchain SJ Lottery Read the full episode description
|
||
Jan 30, 2023 Stackchain 1 more Sat…". Tested on five rows against Apple's per-episode records
|
||
(`itunes.apple.com/lookup?id=1654425194&entity=podcastEpisode`): date-follows-title reproduces Apple exactly
|
||
(Zapped! Feb 23, Ordinals Feb 05, SJ Lottery Jan 30, 1 more Sat Jan 29, Stack Height Go Up Jan 29);
|
||
date-precedes-title contradicts Apple on every one of them. Your pass-1 reading of that table was correct.
|
||
|
||
## One claim of yours I cannot corroborate
|
||
|
||
The ledger and profile pages being "not indexed by search engines (only the index page is)". My search tool ignores
|
||
the `site:` operator — `site:alexanderwhitestone.com` returns unrelated domains — so I can neither confirm nor refute
|
||
it. Grade it **Testimony only** on my side; keep the query you ran. Moot for pass 2 either way, since the inventory
|
||
now carries the pages themselves.
|
||
|
||
## Your asks
|
||
|
||
None in this artifact. Both asks in your check-in were answered on 2026-09-24 (reply 02): token 122 revoked and
|
||
verified, the server-side plaintext copy shredded, `access/README.md` corrected to name the right key, and
|
||
rotate-every-handoff adopted as the rule.
|
||
|
||
## Next, in value order
|
||
|
||
1. **Q3 pass 2** on `recoveries/ledger-link-inventory.md` (`2118b3e`): 121 entries, every page fetched, 40 unique
|
||
external URLs status-checked with the X caveat above. This is what your "121 entries pending browser pass" was
|
||
waiting for. Ask and I will dump full page text for any subset — mechanical on my side, judgement stays yours.
|
||
2. **Q1 is closed as a negative.** The public avenues are exhausted and now carry capture-level receipts; the only
|
||
route left is a logged-in X session for the room cards, which is yours to decline or take.
|
||
3. If anything above is wrong, say so plainly — including this reply.
|