How Far Did My Post Go on the Fediverse?  🔗 **Source:** [How Far Did My Post Go on the Fediverse?](https://shkspr.mobi/blog/2023/09/how-far-did-my-post-go-on-the-fediverse/) > [!note]+ Document Notes > tags: [fediverse, mastodon-api, activitypub, social-graph-privacy, rate-limiting] > author: "[MISSING]" > source: shkspr.mobi > reference: https://shkspr.mobi/blog/2023/09/how-far-did-my-post-go-on-the-fediverse/ > date created: 2026-09-08 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: How far did my post go on the Fediverse? > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] - [[#🔄 Refactor Appendix — How far did my post go on the Fediverse?]] ## 🔗 References - Source: shkspr.mobi (subtitled "Terence Eden's Blog" in the captured site field — the byline itself is not present in the captured content, so author is [MISSING] rather than asserted from the domain), "How far did my post go on the Fediverse?", published 2023-09-26 — https://shkspr.mobi/blog/2023/09/how-far-did-my-post-go-on-the-fediverse/ - 3 real outbound citations confirmed via `paras2.py --links` (an additional 3 link entries — "A note on privacy," "The Result," "The Code" — are internal anchors to this post's own sections, not outbound sources, and are excluded): a linked Mastodon post used as an example of the phenomenon being explained (m.fa.gl/@joshbal4/...), the specific Mastodon status the code in this post analyzes (mastodon.social/@Edent/111040801202691232 — the post's own worked example, linked by the source itself; this analysis does not infer any author identity from that handle), and the Mastodon.py library docs (mastodonpy.readthedocs.io) used to build the crawler. - This post is the older half of a pair with the 2026-09-08 post "ActivityPub - Is it worth defending against replay attacks and message/signature time skew?", which links back to this one (see Refactor Appendix). ## 📝 Summary - **What happened:** The post explains how to trace how far a single Mastodon post spread across the Fediverse — followers' instances, reposters' instances, and (partially) reposters' followers' instances and favouriters' instances — using the Mastodon API and a Python script built on Mastodon.py, and reports one worked example that reached 2,547 distinct instances. - **Why it matters:** It's a concrete demonstration of federation's actual shape (a multi-hop "chain-mail" fan-out across independently operated servers) and of what's structurally knowable vs. unknowable about that spread given Mastodon's API and privacy model. - **Key stakeholders:** anyone building fediverse analytics or crawling tooling, and Mastodon/ActivityPub users curious how far their own posts travel. - **Risks and tradeoffs:** the API rate limit (80 results/request, 1 request/second) makes a full crawl slow at scale; privacy controls (opt-out of showing followers, no cross-instance follower API access without a key for that instance) mean the resulting instance count is a floor, not a complete picture — and the post's own example script contains a scoping bug that would corrupt part of that count (see Logical Validity). - **Bottom line:** the method surfaces a real, non-trivial number (2,547 instances from one popular post) while being explicit that it's necessarily incomplete, bounded by both API limits and by other users' privacy choices, which the post treats as a feature, not a gap to route around. ## 📖 Main Content The post starts from a simple question — can a Mastodon user find out how far one of their posts traveled across the Fediverse — and answers by walking through both the federation mechanism and a script to measure it. **The mechanism.** A post is created on the author's home instance, becomes visible to everyone on that instance, then is delivered to the instances of the author's followers. If any of those followers repost ("reshare" / "boost") it, the post fans out again to that reposter's own followers' instances — a multi-hop spread the post calls "one big chain mail." The post is explicit this framing isn't pejorative, just descriptive of the delivery mechanism. **The privacy boundary.** The post is careful to separate what's technically knowable from what should stay private. Users can opt out of exposing their follower/following lists ("social graph"), and the post frames this as the user remaining in control, not as an obstacle to work around. It also notes a structural limit distinct from opt-outs: notification of a reshare only reaches the original poster, not intermediate reposters, so if someone reshares a reshare, the person whose post was reshared a second time typically has no way to know about it. The Mastodon API itself compounds this: getting a list of followers for an account on a different instance requires an API key for that specific instance, which the post calls impractical at scale — so the crawl described is structurally partial even before privacy opt-outs are counted. **The rate limit.** Mastodon's API caps requests at 80 results per call and roughly one request per second, which the post says makes crawling thousands of results "long and tedious" — a hard practical ceiling on how fast or how completely any instance count can be gathered, independent of the privacy limits above. **The worked example.** Applied to one of the author's own posts (reposted over 100 times), the crawl found the post reached 2,547 distinct instances, "ranging from 0ab.uk to թութ.հայ via godforsaken.website and many more" — the post uses this range of names to illustrate how widely distributed and independently named federated instances are. > [!quote] ID:rw_01m20ga30xakrcwhs6x8xckwjh > "It eventually found its way to… 2,547 instances!" **The method (code).** The included Python script uses Mastodon.py to: (1) fetch all of the author's own followers and record their instances; (2) fetch everyone who reblogged the target status and record their instances; (3) for reblogged accounts on other instances, attempt to also fetch and record the instances of that reposter's own followers (explicitly caveated as slow); and (4) fetch everyone who favourited the status and record their instances. Each step accumulates into a shared `instances_all` set plus a per-category set, then prints per-category totals. The post frames the code candidly rather than as a polished tool: > [!quote] ID:rw_01m20ga30xakrcwhs6x8xckwjh > "This is not very efficient code - nor well written. It was designed to scratch an itch. It uses Mastodon.py to interact with the API." That self-assessment is accurate in a specific, checkable way: the favourites-counting step has a variable-scoping bug (see Logical Validity) that would make its reported total wrong, not merely inefficient. ## 🗒️ Notes - **Federation topology, as described:** post → home instance → followers' instances → (on reshare) reposters' own followers' instances. Two hops are the practical ceiling the post's own script reaches; a third hop (followers of reposters' followers) isn't attempted at all. - **Four data sources crawled by the script:** own followers, status reblogs, reposters' followers (partial, opt-in-key-limited), status favourites. Results accumulate into a combined "all instances" set plus four category-specific sets. - **API constraint:** 80 results/request, ~1 request/second (Mastodon API), which the post gives as the reason a full crawl of a widely-shared post is slow. - **Privacy constraints, distinct from the API limit:** (1) users can opt out of exposing their social graph; (2) reshare notifications only reach the original poster, not the whole chain, so multi-hop reshares are often invisible even to a fully cooperative crawl; (3) cross-instance follower listing needs a per-instance API key, which the post treats as impractical to obtain at the scale a crawl would need. - **Worked result:** 2,547 distinct instances reached from a single post reposted 100+ times, cited as a concrete, if partial, measurement of federation's actual reach. - **Code caveat, self-stated and independently confirmed:** the script's own comment ("not very efficient code — nor well written... designed to scratch an itch") matches what the code shows — see the scoping bug noted under Logical Validity. ## 📚 References - [Mastodon.py documentation](https://mastodonpy.readthedocs.io) — the library the crawl script is built on. - [The Mastodon status analyzed in the worked example](https://mastodon.social/@Edent/111040801202691232) — linked directly by the source as "this post of mine"; the post's own primary data point. - [An example Mastodon post](https://m.fa.gl/@joshbal4/111048499514776098) — linked early in the post to illustrate the fan-out phenomenon before the worked example. - [ActivityPub - Is it worth defending against replay attacks and message/signature time skew?](https://shkspr.mobi/blog/2026/09/activitypub-is-it-worth-defending-against-replay-attacks-and-message-signature-time-skew/) — the same author's later (2026-09-08) post, which links back to this one; see Refactor Appendix. ## 🗣️ Paraphrase A Mastodon user wanted to know how far one popular post of theirs actually spread across the Fediverse, given that federation is essentially chain-mail — your instance sends the post to your followers' instances, and if they reshare it, it goes out again to their followers' instances. Privacy controls limit what's measurable: some users hide their follower lists, reshare notifications only reach the original poster (so a reshare-of-a-reshare is often invisible), and Mastodon's API won't hand over another instance's follower list without a key for that instance. Within those limits, and slowed by an 80-results-per-second API rate cap, a Python script using Mastodon.py crawled the author's followers, the post's reposters, some of those reposters' followers, and the post's favouriters — landing on 2,547 distinct instances for one post that had been reposted over 100 times. The author is upfront that the script itself is rough, not a polished tool. ## 📰 Newsletter **One post, 2,547 servers — a hands-on look at how federation actually spreads.** This 2023 shkspr.mobi post walks through crawling Mastodon's API to measure how far one popular post traveled across the Fediverse, landing on 2,547 distinct instances. What makes it useful beyond the number: it's explicit about what's structurally unknowable — opted-out social graphs, reshare-of-a-reshare notifications that never reach the original poster, and per-instance API keys needed for cross-instance follower data — so the count is presented as a floor, not a census. It's the companion piece to a newer (2026-09-08) post from the same site on ActivityPub replay-attack defenses, and worth reading together if you're touching federated delivery in an IndieWeb or Post Kinds context. ## ✅ Action Items #### DevRel Not applicable to this source. No developer-advocacy, talks, or education-program content. #### OSPO Not applicable to this source. No licensing, governance, or SBOM content. #### Community Not applicable to this source. Personal, single-author technical curiosity post; no maintainer/contributor/sponsor dimension. #### WordPress - **Concrete, source-supported:** if any Post Kinds / IndieWeb tooling ever needs to report "how far did this post spread" across a federated or webmention-linked network, the source's category split (direct followers vs. reposters vs. reposters' followers vs. favouriters, each tracked separately before merging into a total) is a directly reusable data model, and its stated limits (opt-out privacy, notification-visibility gaps, per-source API-key requirements) are the right caveats to surface in any such report rather than presenting a crawled count as complete. - **Concrete, source-supported:** the source's API-rate-limit handling (80 results/request, ~1 req/sec, "long and tedious to crawl thousands of results") is a reminder to budget crawl time and add pagination/backoff whenever building similar reach-measurement tooling against Mastodon's or another fediverse server's API. - Core / Core Performance / Core AI / Mobile / Playground / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins / Training / Marketing / Support / Design / Documentation / Photos / TV / Polyglots / Accessibility: not applicable — the source doesn't touch WordPress core or its contributor teams. #### The WPOCC Not applicable to this source. No governance, fellowship, or funding content. ### FAIR Not applicable to this source. ## 🧪 Hypotheses 1. Federation reach (distinct instances a post lands on) scales with the number of reshares more than with the number of direct followers, since the post's own example credits "reposted over 100 times" as the driver of reaching 2,547 instances. 2. The gap between "measured instance count" and "true instance count" for a given post grows with the number of reshare hops involved, because the post identifies notification visibility as limited to the original poster and cross-instance follower access as requiring a per-instance key — both constraints that compound with each additional hop. 3. Users who opt out of exposing their social graph make a measurably larger dent in reach-crawling completeness on instances with privacy-conscious user bases than on more casual/mainstream ones, per the post's framing of Mastodon/Fediverse users as generally "privacy conscious." 4. A crawl script using the pattern in this post (accumulate instance names into a shared set across four separately-tracked categories) will undercount the favourites category specifically if it reuses a loop variable from an earlier loop without reinitializing it — the exact bug present in this post's own example code (see Logical Validity). ## 📊 Methodology The post reports one first-person case study (a single popular post, reposted 100+ times) analyzed with a purpose-built Python script using the Mastodon.py library against the live Mastodon API. There's no comparison across multiple posts, no statistical treatment, and no attempt to estimate the undercounting caused by privacy opt-outs or the unreachable third-hop (favouriters'/reposters'-followers'-followers). The 2,547 figure is a single-sample, admittedly-partial measurement, not a study result generalizable beyond this one post. ## ❓ Questions - How much does the reported 2,547-instance figure undercount the true reach, given the post's own admission that reshare-of-a-reshare notifications don't reach the original poster and that cross-instance follower listing needs a key the crawl doesn't have? - Does the favourites-counting bug in the example script (adding the wrong variable to the results set — see Logical Validity) affect the 2,547 headline number, or only the separately-reported favourites subtotal? - How does this crawl approach handle instance renames or shutdowns, both of which the post mentions in passing ("some servers may no longer exist, or might have changed names") without saying how the script accounts for them? - Would a similarly-shaped crawl against ActivityPub servers other than Mastodon (which may not implement the same reshare-notification or rate-limit behavior) produce comparably shaped results, or does the method depend on Mastodon-specific API behavior? ## 🔮 Future Research - A corrected version of the crawl script (fixing the favourites-loop variable bug) re-run against the same post, to see how much the reported instance count changes. - A methodology for estimating the undercounting gap itself — e.g., comparing crawled counts against instances' own federation/relay logs where operators are willing to share them — rather than only naming the gap qualitatively. - Running the same method across multiple posts of varying popularity to see whether the two-hop measurable ceiling this post reaches (followers, reposters, partial reposters'-followers, favouriters) scales linearly or non-linearly with repost count. ## 💡 Implications - **Practice:** anyone building or consuming a "how far did this spread" tool for a federated network should present the result as a lower bound with named causes of undercounting, following this post's own framing, rather than as a definitive reach number. - **Privacy/policy:** the post models a defensible stance — federation reach is measurable from data the platform already surfaces to the user, and the crawl deliberately doesn't attempt to route around social-graph opt-outs or unavailable cross-instance data. - **Security:** not directly addressed, though the described API-key requirement for cross-instance follower access functions as an access-control boundary the post respects rather than tries to bypass. - **Education:** the post is a clear, reproducible teaching example of federation's actual multi-hop shape for readers who only think of "the Fediverse" as a single network rather than a mesh of independently operated servers. - **Funding/community:** not addressed in the source. ## 🧠 Learning Styles Assessment - **Reading level estimate:** approximately Flesch-Kincaid grade 8–9 — short, conversational sentences, first-person narration, and directly stated numbers, though fediverse-specific vocabulary (instance, boost/reblog, social graph) adds domain-specific difficulty. #### 👀 Visual learners - Present: none in the captured content — no diagrams despite a topic (multi-hop post fan-out across instances) that's inherently graph-shaped. - Improve: a simple node-and-edge diagram of the post → followers → reposters → reposters'-followers fan-out (the post gestures at this with "as an example" language that the plain-text capture stripped of its original illustration) would make the federation topology immediately legible. #### 🔊 Aural learners - Present: none. - Improve: a short narrated walkthrough of the crawl script's four data-gathering steps. #### 🗣️ Verbal learners - Present: well served — conversational tone, terms explained in plain language ("that's a fancy word for..." style asides appear in the companion post, and this one similarly glosses "instance" and "social graph" on first use). - Improve: none needed. #### 🧩 Kinesthetic learners - Present: the full Python script is included and directly runnable against a reader's own Mastodon account and post. - Improve: none needed — this is the post's strongest kinesthetic feature, though a corrected version (fixing the favourites-loop bug) would make it more reliably reproducible. #### 🧠 Logical learners - Present: the post is structured as a clear constraint-then-method sequence (what's private → what's rate-limited → what's crawlable → what was found). - Improve: an explicit table of the four data-source categories against their known completeness caveats would sharpen the already-logical structure. #### 🧑‍🤝‍🧑 Social learners - Present: minimal — a solo first-person account ending in a rhetorical "My head hurts... Got it? Here we go!" that invites the reader along rather than a discussion. - Improve: an invitation for readers to run the script against their own posts and report back would turn this into a shared measurement exercise. #### 🧘‍♀️ Solitary learners - Present: well served — a self-contained script and explanation a reader can work through alone. - Improve: none needed. #### 🌿 Naturalistic learners - Not applicable to this source. ## 📊 Accessibility Assessment #### Screen reader semantics - Not assessable from the captured plain-text content; the source's own section headings ("A note on privacy," "The Result," "The Code") were stripped by the `<p>`-only extraction that produced this file, but their presence as internal anchor links (confirmed via `--links`) suggests the live page uses structural headings for these sections. #### Keyboard navigation - Not assessable from the captured plain-text content. #### Contrast and readability - Not assessable from the captured plain-text content. #### Text resizing and reflow - Not assessable from the captured plain-text content. #### Media and captions - Present: none in the captured content beyond the code block. - Improve: not applicable — text/code-only piece. #### Forms and interactions - Not applicable to this source. #### Standards reference - Cannot map to WCAG 2.2 AA criteria beyond structural heading use (2.4.6) without access to the live page's DOM. ## 🌍 DEIB Assessment #### Cultural breadth - Narrow by design — a personal technical case study with no cultural, regional, or demographic dimension beyond the incidental illustration that instance names span multiple scripts and languages (0ab.uk, թութ.հայ, godforsaken.website). #### Inclusive language - Neutral throughout; the captured content contains no gendered language and states no pronouns for the author, so none are used here. #### Neurodiversity support - Reasonably strong: short paragraphs, explicit numbered/sequential reasoning (mechanism → privacy limits → rate limits → result → code), and a fully worked concrete example support low-effort scanning. - Improve: the four data-source categories (followers, reposters, reposters'-followers, favouriters) would benefit from an explicit list or table rather than being introduced sequentially across separate paragraphs. #### Representation - No individuals are named by the post beyond the linked Mastodon handle in its own worked example ("this post of mine," linked to a specific account); this analysis does not name or infer any author identity beyond what the source itself links. #### Psychological safety - Low-stakes, self-deprecating tone throughout (the code is "not very efficient... nor well written," ending in "My head hurts"), which frames the post as a shared, approachable exploration rather than an authoritative technical statement. ## ✅ Logical Validity #### Strong reasoning - The privacy-boundary reasoning is sound and internally consistent: the post identifies three independent, correctly-distinguished constraints on measurement completeness (opt-out social graphs, notification-visibility limits, per-instance API-key requirements) rather than conflating them into one vague "privacy" caveat. - The worked example (2,547 instances from one post) is a specific, falsifiable number tied to a named, linked source post, not a rounded or invented illustration. #### Fallacies - **Unverified self-assessment, mostly correct but incomplete.** The post's disclaimer ("not very efficient code — nor well written") reads as a general hedge, but the actual code contains a specific, checkable bug: in the favourites-counting loop, `instances_favourites.add( r )` adds `r` — a variable left over in scope from the earlier, separate reposters'-followers loop — instead of `f`, the favouriter's own instance name computed two lines above it. This means the reported favourites-instance count reflects stale reposter-instance data, not favouriters' actual instances. The self-deprecating framing is accurate in spirit but understates that this specific bug would produce a wrong number, not just an inefficient one. Fix: rerun with `f` substituted for `r` on that line before trusting the favourites subtotal. `#fallacy/hasty-generalization` - **Incompleteness stated but not quantified.** The post is honest that the crawl can't reach every instance (opt-outs, notification gaps, API-key requirements) but doesn't estimate how large that gap might be relative to 2,547 — the number is presented with appropriate hedging in prose but without a confidence range. Fix: even a rough bound ("likely undercounts by X%") would let readers weigh the figure more precisely. #### Tone of voice Casual, self-deprecating, and enthusiastic — the post treats the diversity of instance names ("0ab.uk to թութ.հայ") as evidence supporting a broader hope about decentralization succeeding, closing on a note of genuine surprise at its own result ("My head hurts"). ## 🛡️ DARVO Analysis Not applicable to this source. There is no accusation, denial, or victim/offender framing — the piece is a personal technical exploration with no interpersonal conflict content. ## 🎯 Conclusion The durable finding is methodological, not just the headline number: federation reach is measurable, but only partially, and the specific reasons it's partial (privacy opt-outs, one-way reshare notifications, per-instance API-key gating, plus this crawl's own two-hop practical ceiling) are each independently real constraints rather than one vague limitation. The 2,547-instance result for a single reposted-100+-times post is a concrete demonstration that the Fediverse's "chain-mail" framing is not just a metaphor. Practical next step for a reader adapting this method: fix the favourites-loop variable-scoping bug before trusting that specific subtotal, and present any resulting instance count as a floor with its known undercounting causes stated alongside it, as this post itself does. ## 🔄 Refactor Appendix — How far did my post go on the Fediverse? ### 📚 Literature Atoms (H3) #### [H1] Federation reach is structurally partial, not just practically incomplete > [!quote] ID:rw_01m20ga30xakrcwhs6x8xckwjh > "Some people don't share their \"social graph\". That is, it is impossible to see who follows them or who they follow." Establishes that the crawl's incompleteness isn't only a rate-limit or effort problem — some of the data is deliberately unavailable by user choice, and the post treats that as correct behavior rather than a gap to route around. Tags: `#xref` **Highlight**: [view highlight](readwise://01m20ga30xakrcwhs6x8xckwjh) <!-- atomicity: 1 idea ✓ --> #### [H2] One reposted post reached 2,547 distinct Fediverse instances > [!quote] ID:rw_01m20ga30xakrcwhs6x8xckwjh > "It eventually found its way to… 2,547 instances!" The post's concrete, falsifiable headline measurement — a single-sample data point for how far one popular post spread, produced by the crawl method described earlier in the post. Tags: `#xref` **Highlight**: [view highlight](readwise://01m20ga30xakrcwhs6x8xckwjh) <!-- atomicity: 1 idea ✓ --> #### [H3] The author frames the crawl script as rough, unoptimized, purpose-built > [!quote] ID:rw_01m20ga30xakrcwhs6x8xckwjh > "This is not very efficient code - nor well written. It was designed to scratch an itch. It uses Mastodon.py to interact with the API." Sets reader expectations honestly, and — per this analysis's Logical Validity check — undersells the issue: the code contains a specific variable-scoping bug in the favourites-counting step, not just general inefficiency. Tags: `#xref` **Highlight**: [view highlight](readwise://01m20ga30xakrcwhs6x8xckwjh) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A measurement's stated limits are only useful if they're itemized, not bundled into one caveat **Claim** (one sentence, Courtney's voice): A partial measurement is more trustworthy when its incompleteness is broken into separately named, independent causes (here: privacy opt-outs, one-way notification visibility, and API access-key requirements) rather than folded into a single vague "this is incomplete" disclaimer, because each cause implies a different kind and direction of undercount. **Evidence pointer**: [[#H1]] **Scope & conditions**: Applies to any crawl or reach-measurement tool built on a platform API with mixed public/private/rate-limited data; the value of itemizing breaks down if the causes actually do interact in ways that can't be cleanly separated. **Links**: - [[How far did my post go on the Fediverse?]] — because evidence-for the source reasoning this candidate generalizes from - [[ActivityPub - Is it worth defending against replay attacks and message/signature time skew?]] — because contrasts on the companion post's similar "which check is actually doing the work" reasoning applied to security instead of measurement completeness <!-- atomicity: 1 idea ✓ --> #### [P2] A leftover loop variable from an earlier block is a silent source of wrong aggregate counts **Claim** (one sentence, Courtney's voice): In any script that accumulates results across multiple sequential loops sharing similar variable names, a variable reused from an earlier loop (rather than freshly computed in the current one) will silently populate results with stale data instead of raising an error, because the language doesn't scope loop variables to the loop body — making this exact bug class worth a specific code-review check whenever adapting or reusing this kind of scraping script. **Evidence pointer**: [[#H3]] **Scope & conditions**: Specific to languages (like Python) where `for` loop variables persist in the enclosing scope after the loop ends; applies whenever a script has multiple loops that reuse short, similar variable names (`f`, `r`) across blocks. **Links**: - [[How far did my post go on the Fediverse?]] — because evidence-for the specific bug found in this source's own example script <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - Worth re-running the post's script with the favourites-loop bug fixed (`f` instead of `r`) to see whether the corrected favourites subtotal changes the overall 2,547-instance headline number or only the favourites-specific count. `#xref` - The companion 2026-09-08 post from the same site links back to this one via "ActivityPub is one big chain-mail" — worth checking whether that later post's replay/idempotency reasoning has any bearing on the reliability of this post's reshare/favourite counting (e.g., could a duplicate-processed reblog inflate an instance count here the way a duplicate-processed activity could elsewhere). `#xref` ### → Things 3 (max 2 actions) - [ ] If building any "how far did this post spread" reporting for Post Kinds/IndieWeb webmention data, itemize completeness limits (opt-outs, notification visibility, access-key gating) the way this source does, rather than a single blanket caveat. `#things` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/How Far Did My Post Go on the Fediverse.md|How Far Did My Post Go on the Fediverse? by shkspr.mobi]] ## Highlights - Some people don't share their "social graph". That is, it is impossible to see who follows them or who they follow. ([View Highlight](https://read.readwise.io/read/01m20gtpk9wdqtcy8gwgqb78xt)) - Note: H1 — federation reach is structurally partial by user choice, not just by rate-limit or effort. #atom/literature/h1 - Tags: atom/literature/h1 - It eventually found its way to… 2,547 instances! ([View Highlight](https://read.readwise.io/read/01m20gts8aq47vmehq0n61rchf)) - Note: H2 — the post's concrete, falsifiable headline measurement of federation reach. #atom/literature/h2 - Tags: atom/literature/h2 - This is not very efficient code - nor well written. It was designed to scratch an itch. It uses Mastodon.py to interact with the API. ([View Highlight](https://read.readwise.io/read/01m20gtvx91h0fcy7ck1tdjg4p)) - Note: H3 — author's self-assessment; understates a real variable-scoping bug in the favourites-counting loop found during this analysis. #atom/literature/h3 - Tags: atom/literature/h3