# ActivityPub — Programming for the Social Web # Prompt 0 — Retrieval and route Exact title/author archive search finds no matching review. Mounted-original stat reports absent. Fresh Drive metadata verifies exact ID 1vi5TJnD6x3QDAsTvm4RDYFOTg_-2-Z79 and canonical books parent 15-6hor-x19gWIYqCrNYuNiMeNWcilr3F. Authenticated streaming acquires 3,496,237 bytes; SHA, CRC and all 16 strict XML spines pass with no raw/decoded manifest collisions. Native title/copyright identify Evan Prodromou, September 2024 First Edition, first release September 20 and ISBN 9781098169466. OPF publication date September 27 is package metadata, not a replacement for the explicit first-edition statement. Copyright errata link contains 9781098162740; its edition/format is not independently verified, so print_isbn remains null. Source unchanged. Book-rule stat is hidden/on disk; the rule read earlier in this lane applies with the user single-note override. No separate Excalidraw, PN or MOC edits. Bounded Reader lookup returns a related Open Channels FM interview, not the requested book; its quotes aren’t this book’s Layer 1. A Drive search also returns a separate selected-quotes document, not an archive review; it isn’t substituted for the EPUB. No remote absence claim, highlight deduplication, timestamps or reader opinions. All P-IDs below are system selections and zero-based native body.iter locations. **Coverage:** Full: title, copyright, Preface including conventions/acknowledgments; Chapter 1 Welcome to the Fediverse with both footnotes and four figures; Chapter 5 Extending ActivityPub, every prose/code section, 44 JSON listings and Figure 5-1. Images actually inspected. Sampled: extracted navigation headings only for other units, not their arguments. Chapters 2–4 and 6, Appendices A/B, praise, dedication, author/colophon and cover image remain unread/not evaluated. No example endpoint called, no live server/account test or privacy/interoperability outcome established. | ID | Exact native excerpt | Location | Voice | | --- | --- | --- | --- | | P-0001 | This book is primarily for software developers | `OEBPS/preface01.html#body-element-11` | Prodromou exposition/code, not reader opinion | | P-0002 | I’ll be using social network to mean either the people or the software interchangeably in this book | `OEBPS/ch01.html#body-element-15` | Prodromou exposition/code, not reader opinion | | P-0003 | (N × (N – 1)) / 2 | `OEBPS/ch01.html#body-element-104` | Prodromou exposition/code, not reader opinion | | P-0004 | Nobody can kick you off the fediverse | `OEBPS/ch01.html#body-element-149` | Prodromou exposition/code, not reader opinion | | P-0005 | This analogy isn’t perfect | `OEBPS/ch01.html#body-element-223` | Prodromou exposition/code, not reader opinion | | P-0006 | The influx of new users hasn’t always been without controversy. | `OEBPS/ch01.html#body-element-285` | Prodromou exposition/code, not reader opinion | | P-0007 | This is all just speculation on my part, of course. | `OEBPS/ch01.html#body-element-304` | Prodromou exposition/code, not reader opinion | | P-0008 | I’ll be using made-up extensions to illustrate these principles. | `OEBPS/ch05.html#body-element-13` | Prodromou exposition/code, not reader opinion | | P-0009 | it can get dropped off. | `OEBPS/ch05.html#body-element-126` | Prodromou exposition/code, not reader opinion | | P-0010 | Preserving the property isn’t even necessary | `OEBPS/ch05.html#body-element-132` | Prodromou exposition/code, not reader opinion | | P-0011 | using JSON-LD natively is important. | `OEBPS/ch05.html#body-element-133` | Prodromou exposition/code, not reader opinion | | P-0012 | they have to be optional and backward compatible. | `OEBPS/ch05.html#body-element-337` | Prodromou exposition/code, not reader opinion | | P-0013 | they also won’t get to see the spoilers even if they want to! | `OEBPS/ch05.html#body-element-549` | Prodromou exposition/code, not reader opinion | | P-0014 | One is bandwidth | `OEBPS/ch05.html#body-element-899` | Prodromou exposition/code, not reader opinion | | P-0015 | change the access control on the BirthdayCard object | `OEBPS/ch05.html#body-element-1150` | Prodromou exposition/code, not reader opinion | | P-0016 | not all ActivityPub servers and clients will recognize them and implement side effects | `OEBPS/ch05.html#body-element-1372` | Prodromou exposition/code, not reader opinion | | P-0017 | the semantics of routing content to groups isn’t built into ActivityPub | `OEBPS/ch05.html#body-element-2352` | Prodromou exposition/code, not reader opinion | | P-0018 | the place is in the location property, not the object property. | `OEBPS/ch05.html#body-element-2439` | Prodromou exposition/code, not reader opinion | | P-0019 | the Leave activity uses the object property to track the Place. | `OEBPS/ch05.html#body-element-2512` | Prodromou exposition/code, not reader opinion | | P-0020 | a client that is unaware of the flag’s meaning will display the whole Note with no warning or blurring. | `OEBPS/ch05.html#body-element-3111` | Prodromou exposition/code, not reader opinion | | P-0021 | using private personal data for real people on the public social web is generally a bad idea. | `OEBPS/ch05.html#body-element-3165` | Prodromou exposition/code, not reader opinion | | P-0022 | See the exact P-0022 code excerpt below | `OEBPS/ch05.html#body-element-3854` | Prodromou exposition/code, not reader opinion | | P-0023 | "Duration": "PT423S" | `OEBPS/ch05.html#body-element-3665` | Prodromou exposition/code, not reader opinion | | P-0024 | requiring two independent publishers and two independent consumers. | `OEBPS/ch05.html#body-element-4079` | Prodromou exposition/code, not reader opinion | **P-0022 verbatim code excerpt:** ```json "splits": { "@id": "run:waypoints" ``` | System cluster | Rationale | 3–5 representatives | | --- | --- | --- | | A: Preface/Chapter 1 | Audience, network model and qualified future claims | P-0001, P-0003, P-0004, P-0005, P-0007 | | B: Chapter 5 receiver/sender principles | Pass-through, fallback and behavioral limits | P-0008, P-0009, P-0010, P-0012, P-0013 | | C: Chapter 5 cases/design | Sparse semantics, privacy caveats and context examples | P-0017, P-0020, P-0021, P-0022, P-0024 | Selection density: Preface 1; Chapter 1 6; Chapter 5 17. Counts describe this review, not reader preference or independent confirmation. # Prompt 1 — System-inferred contract and questions > [!warning] System inference, not Courtney's motive > The proposed purpose is to understand extension compatibility and distinguish data validity, semantics and real execution. **Correction point:** replace this purpose and any proposed application if your actual goal differs. No reader professional role, prior programming experience, incentives, wants or resistance is inferred. Success means you can trace a declared extension through sender/receiver roles, identify fallback behavior and state what an offline check doesn't prove. A contrary normative clause or reproducible semantic mismatch can change a technical verdict; current interoperating implementations require a separate authorized test. The source can't establish runtime compatibility, actual community safety or implementation privacy from examples alone. Constraints: selected chapters, unknown reader emphasis, no accounts/posting/network experiments, no full later implementation chapters. The system's completion incentive could favor a tidy extension story; actual defects and declared exceptions must survive Prompt 7. | Category | Open questions | | --- | --- | | Definitions | O-01: Is social network a group or its software? O-02: Is compatible a data, semantic or operational claim? | | Mechanisms | O-03: What happens to unknown properties? O-04: What does the UI do when it doesn't understand a type? | | Evidence | O-05: Which requirements are normative? O-06: What does parsing JSON fail to establish? | | Historical context | O-07: Which 2024 counts are dated? O-08: Which history is author testimony? | | Application | O-09: Can an extension change required receiver behavior? O-10: How should namespaces be checked? | | Counterarguments | O-11: What if a server loses unknown data? O-12: What if only one protocol profile is supported? | | Failure modes | O-13: Can a sensitive flag fail open in an unaware client? O-14: Can a context alias merge intended distinctions? | | DEIB/transfer | O-15: Does federation guarantee belonging? O-16: Does actor data expose private information? | | Accessibility | O-17: Does a fallback summary replace a rich interaction? O-18: Can diagrams/code be understood without color or prior jargon? | | Unanswered | O-19: Do real implementations support the examples? O-20: Can network connection counts measure utility? | | Seed claim | Initial system belief | Qualitative confidence | Reason | Needed evidence | | --- | --- | --- | --- | --- | | C-001 | API/protocol layers differ | Moderate | Different participants/endpoints | Normative profiles | | C-003 | Complete undirected pairs use N(N−1)/2 | High conditional | Combinatorial identity | Recompute boundary cases | | C-004 | Pair counts don't measure all user value | Moderate | Not every potential tie has equal value | A utility model/data | | C-006 | Unknown-property handling needs a defined contract | Uncertain | Consumers may vary | Normative clause | | C-009 | Fallback can convey only part of a rich type | Moderate | Generic type has fewer semantics | Example and receiver test | | C-014 | Delayed check-in isn't a privacy guarantee | Moderate distinction | Location history can remain sensitive | Threat model/outcome evidence | | C-018 | A context should keep distinct terms distinct | Moderate | Mapping controls identity | Inspect exact context | | C-022 | JSON syntax isn't interoperability | High distinction | Parsing doesn't execute protocols | Separate semantic/runtime checks | Reader beliefs/incentives are unknown. The author reports cochair/coeditor involvement (Preface), so expertise and advocacy share a position; that isn't proof of error. Protocol publication and exact code are fixed; software support, counts, policy and usability can drift within a year. # Prompt 2 — Map, summary and selected route | Actual unit | Coverage | Purpose/connection, system inference | | --- | --- | --- | | Title/copyright | Full | Identity, first edition/release | | Preface | Full | Audience, prerequisites, conventions, structure and acknowledgments | | Chapter 1. Welcome to the Fediverse | Full, notes/4 figures | Motivation, layers, history and explicitly speculative future | | Chapter 2. Activity Streams 2.0 | Heading/navigation only; body unread | Data foundation, role confirmed by Preface | | Chapter 3. The ActivityPub API | Heading/navigation only; body unread | Client interface, role confirmed by Preface | | Chapter 4. The ActivityPub Protocol | Heading/navigation only; body unread | Server interactions, role confirmed by Preface | | Chapter 5. Extending ActivityPub | Full prose/44 listings/1 figure | Receiving/sending, vocabulary cases and extension design | | Chapter 6. Far Horizons | Heading/navigation only; body unread | Future ideas, title/Preface-based role | | Appendix A. Activity Vocabulary Types; Appendix B. Activity Streams 2.0 Properties | Bodies unread | Reference roles from Preface | | Praise/dedication/author/colophon/cover | Bodies/image unread | Paratext, not evaluated | The central project teaches developers how to create software for a common social data/API/federation stack. Source audience: developers, architects/designers and narrative-chapter policy/business readers. It assumes JSON/programming and web/API familiarity but says modern-language experience can help. Modes: explain (layers), teach (examples), advocate (social web), narrate (participant history), speculate (labeled future possibilities). No forecasts are treated as realized developments. **Provisional summary, selected route:** Prodromou presents the social web as an alternative to isolated social-network services. He separates the data format, client API and federation protocol, explaining their connections through figures and an imperfect email analogy. His introductory history comes partly from his own participation, and his future possibilities are expressly speculative. The extension chapter asks software to tolerate unfamiliar data and asks extension designers to plan for receivers that won't understand new terms. Fictional mood, farm, spoiler and birthday-card examples expose the difference between passing data and interpreting behavior. The chapter also admits sparse group/event semantics, privacy concerns, bandwidth cost and a widely used warning flag that violates its own design recommendation. The review confirms bounded normative principles and identifies two local running-example defects. It doesn't evaluate unread implementation chapters or test a live server. JSON validity supports only syntactic correctness; interoperability, authorization, audience benefit and current software support remain separate questions. **Selective deep read:** complete motivation and complete extension chapter, including all notes/code/figures, give a coherent design-boundary test. Hotspots: Chapter 1 network-value inference and membership wording; Chapter 5 unknown-data handling, spoiler fallback, sparse groups, sensitive exception and context construction. Switch to Chapters 2–4/full references before implementing a client/server; switch to authorized interoperability tests before shipping any behavioral promise. This note doesn't activate either route. Ten guiding questions: O-02/03/04/05/06/09/10/11/13/14. They target the difference between encoded intent and receiver behavior. # Prompt 3 — Vocabulary and category boundaries Classification: technical tutorial and standards interpretation, with advocacy and participant history. Method: architecture explanation, fictional worked data and vocabulary design. Intended use: developer study; not a conformance certificate. Comparison traditions: protocol specifications, linked-data modeling, graceful degradation and federated governance. All definitions below paraphrase source usage; operational/counter definitions are reviewer additions. | Term | Source use | Competing meaning | Operational definition | Risk | Example | Counterexample | Evidence | | --- | --- | --- | --- | --- | --- | --- | --- | | Social network | People or software, explicitly interchangeable | Software service only | Name which referent a claim needs | Social graph becomes software behavior | Human tie vs feed | Count accounts as friendships | P-0002 | | Social web/fediverse | Interconnected independent services | One centrally managed platform | Separate common protocol from local service | Connected implies universally reachable | Figure 1-4 | Guaranteed acceptance by all servers | P-0004; ch1 | | AS2 | Social data model/format | ActivityPub transport itself | Identify data versus delivery | Serialization equals execution | Actor/Activity/Object | A request routing rule | ch1 164–191 | | API | Client-to-server interface | Server-to-server federation | Name participant roles/endpoints | One supported layer means both | Figure 5-1 outbox | Assuming every federating server has C2S | ch1 196; X-01 | | Protocol | Server interconnection | Any application API | Distinguish federation delivery | Same data means same behavior | Server→server inbox | UI support inferred from transport | ch1 217 | | Extension property | Added data field with namespace/context | Mandatory processing instruction | Ask what an unaware receiver does | Hint becomes enforcement | Fictional mood | Hidden required spoiler rule | P-0008/0012 | | Extended type | Additional type with fallback | Complete implementation capability | Trace base type and display fallback | Generic base guarantees rich semantics | Plant/Create | Unknown Plant shown as rich game UI | ch5 141/315/323 | | Context | Maps terms to identifiers/types | Ordinary descriptive prose | Inspect mapping and scoped definitions | Valid JSON proves correct identity | run context | splits aliases waypoints | P-0022 | | Namespace | Identifies vocabulary terms | A project name label | Compare exact identifiers | Similar spelling implies equivalence | run: prefix | Unmapped invented term | ch5 3628/3630 | | Fallback | Degraded representation/behavior | Same experience everywhere | Describe what remains and what is lost | Partial display called full support | Summary of Plant | Full game behavior from summary | ch5 323/332 | | Sensitive | Flag some clients interpret as warning | Access-control boundary | Separate display hint from authorization | Hide UI means no disclosure | Content warning | Unaware client displays content | P-0020 | | Portability | Move with reciprocal identifier condition | Total export of all history | Separate follower redirection from content/data | Migration means everything follows | alsoKnownAs/Move | Guaranteed history transfer | ch5 1687–1752 | | Privacy | Controlled sharing concern | Mere delayed posting | Name data, recipients and retention risk | Left-location report treated safe | Contact-info caution | All past-location exposure harmless | P-0021; ch5 2442 | | Interoperability | Implementers communicate/understand | JSON parser accepts input | Test syntax, identifiers, behavior separately | Capability becomes actual support | Independent implementations | Parser-only success | P-0024; ch5 4078 | Contested language: network value, private, real friends, compatibility and fediverse membership carry social or operational implications beyond schema labels. Mutual-follow intersection is an author's approximation, not a verified measure of friendship. Category-error watchlist: **present risks** in the evaluated argument include potential-pair count→utility/lock-in cause, implementation capability→outcome, delayed location→privacy, syntax→semantics, flag→enforcement and local service autonomy→universal reachability. **Review risks:** testimony→independent history and unread/current support→evidence of absence. **Absent demonstrated errors:** this review doesn't infer character/behavior from demographic identity or treat normative standards as laws. Legal/moral and theological/historical conflations are not applicable to the selected technical verdicts. No inclusion conclusion follows solely from community demographics. # Prompt 4 — Claims, expectations and falsifiers EA is explicit author claim; IA is an implied pedagogical claim from the actual example, not a direct sentence. RI is a **system-created inference, neither Prodromou's statement nor Courtney's opinion**. C-014 is an unresolved interpretation of the author's privacy rationale. No live behavior is inferred from an example. | Claim | Type/voice | Source | Expected and present evidence | Serious falsifier/boundary | Dependency/question | | --- | --- | --- | --- | --- | --- | | C-001: ActivityPub has C2S and S2S layers | descriptive EA | ch1 160/196/217; X-01 | Normative overview; two layers confirmed | Normative document describes only one layer | foundation/O-05 | | C-002: Standard federation means every server supplies the same C2S interface | RI system inference, NOT author sentence | ch1 198; X-01 | Profiles required; specification permits one or both | A valid federation-only profile defeats universal inference | 001→misuse/O-12 | | C-003: A complete undirected N-node graph has N(N−1)/2 potential pairs | mathematical EA | P-0003; T-01 | Derivation/recomputation; boundary cases checked | Any enumerated pair count differs under those assumptions | foundation/O-20 | | C-004: Network value rises as square of users and explains lock-in | causal EA | ch1 104/119/120 | Utility/causal model needed; count analogy appears | Unequal tie value or other switching causes defeat sufficiency | 003→unsupported utility bridge/O-20 | | C-005: Nobody can kick you off the fediverse if standards are implemented | scope EA | P-0004 | Governance/reachability evidence needed; broad statement appears | A conforming peer refuses exchange or local service excludes an actor | membership bridge/O-15 | | C-006: Unfamiliar extensions must not stop AS2 processing | normative EA | ch5 121; X-02 | Normative rule; checked core §5 supports tolerance | Normative rule requires failure solely for unfamiliar extension | extension foundation/O-03 | | C-007: Servers should preserve unknown properties for later consumers | practical EA | P-0009; ch5 130/1353 | Pass-through model and storage evidence; code/explanation, no server test | A tested processing path loses the field | 006→pass-through/O-11 | | C-008: An unaware receiving client may omit an extension representation | practical EA | P-0010; ch5 332 | UI contract/test needed; text explains omission | Receiver must render unknown term under a checked contract | 006→UI/O-04 | | C-009: Fallback types and summaries can carry partial meaning | design EA | ch5 141/315/323 | Example/type behavior; worked Plant/Create example | Fallback cannot convey described minimal meaning | 007→partial-use/O-04 | | C-010: New extension properties cannot require unaware software to change default behavior | design EA | P-0012; ch5 342/448/549 | Unknown-field countercase; explicit spoiler demonstration | Every intended receiver enforces the added rule under a required contract | 006→compatibility/O-09 | | C-011: Event acceptance targets the Invite, not the Event | textual/model EA | ch5 1976/2022 | Worked invitation/response pair; code present | Example Accept object points at Event instead | case/O-10 | | C-012: Client-only group routing is not built into base ActivityPub | dated behavior EA | P-0017; ch5 2353 | Normative/group implementation study needed; author reports sparse semantics | A complete verified base client-only routing contract defeats categorical reading | case/O-19 | | C-013: Arrive identifies its place through location | normative EA | P-0018; X-03 | Vocabulary definition; location confirmed | Normative Arrive identifies object as arrival place instead | case/O-05 | | C-014: Leave check-ins protect current-location privacy | causal/UI from author rationale | ch5 2442/2512 | Threat model/retention data needed; preference rationale appears | History or repeated patterns reveal location despite delayed report | case→privacy/O-16 | | C-015: Move can redirect followers under alias conditions | dated behavior EA | ch5 1687–1752 | Interoperability/profile tests needed; described Move/alsoKnownAs mechanism | A target processor ignores Move despite data being present | case/O-19 | | C-016: Sensitive flag may fail to hide content in unaware clients | design EA | P-0020 | Countercase and receiver test; source itself names failure | Required receiver semantics always enforce hiding | 010 exception/O-13 | | C-017: Private contact data should not enter public actor data unintentionally | ethical/practical EA | P-0021 | Normative privacy reasoning; caution explicit | Value judgment not empirically falsifiable as stated; a chosen public business contact is a boundary case | policy/O-16 | | C-018: The running context keeps splits distinct from waypoints | implied example claim IA | P-0022; ch5 3854; T-02 | Inspect mapping; both map to run:waypoints | Equal mappings contradict intended distinct terms | context/O-14 | | C-019: The nested running split uses the standard duration term | implied example claim IA | P-0023; X-03 | Exact key/vocabulary; source capitalizes Duration, standard is duration | Source key differs from normative term | context/O-10 | | C-020: Reusing recognized vocabularies raises interoperability prospects | comparative practical EA | ch5 2925/3621 | Cross-implementation comparison needed; rationale and examples appear | Receivers lack recognition or equivalent terms misfit domain | extension choice/O-19 | | C-021: Context inclusion policy needs two independent publishers and consumers | dated institutional EA | P-0024 | Current institutional policy needed; source states 2024 criterion | Authoritative current policy specifies another criterion | adoption/O-07 | | C-022: All valid JSON examples prove secure interoperable implementation | RI system inference, NOT author sentence | T-02; ch5 1150/3111 | Semantic/security/runtime checks needed; parser succeeds only | A syntactically valid alias/mismatched key defeats implication | syntax→misuse/O-06 | **Dependency outline:** C-001 defines layers; C-002 is a rejected all-server transfer. C-003 is conditional math; C-004 needs an extra utility/causal bridge. C-006 grounds extension tolerance, with C-007/008 receiver roles and C-009/010 fallback design. C-011–016 are cases with separate implementation/privacy boundaries. C-018/019 can fail locally without refuting extensions; they weaken copy-and-run pedagogy. C-020/021 support adoption strategy only conditionally. C-022 is rejected syntax-to-safety transfer. The load-bearing practical gap is defined data→tested receiver behavior. # Prompt 5 — Quantitative rigor before evaluation No measured Bayesian prior, likelihood or posterior exists. Use qualitative changes only after Prompt 7. Normative rules, mathematical identities and ethical preferences aren't population probabilities. Pair counts are calculable under explicit graph assumptions; utility, safety, privacy and actual implementation support aren't supplied by those counts. | Claim | Prior | Input awaiting evaluation | Likelihood policy | Posterior | Range | | --- | --- | --- | --- | --- | --- | | C-001 | Moderate | X-01 architecture/profiles | Normative text can settle declared layers | Pending | No invented number | | C-003 | High conditional | T-01 boundary counts | Enumeration tests arithmetic only | Pending | Not probabilistic | | C-004 | Moderate concern | Pair-to-value argument | No utility data, no quantitative update | Pending | No number | | C-006 | Uncertain | X-02 tolerance rule | Normative support doesn't measure implementation | Pending | No number | | C-009 | Moderate mechanism | Farm fallback example | Demonstration doesn't measure coverage | Pending | No number | | C-014 | Moderate distinction | Delayed-location rationale | No threat model/outcomes | Pending | No number | | C-018 | Moderate expected distinctness | T-02 mappings | Direct mismatch changes local verdict | Pending | Not probabilistic | | C-022 | High distinction | Parser and semantic tests | Separate validation layers | Pending | N/A for rejected inference | Dependence: book chapters/examples share one author. W3C AS2 and ActivityPub documents are a primary standards family; Prodromou participated in them. They independently expose normative text relative to the book, but aren't independent author-free empirical studies. Forty-four successful parses are forty-four syntax checks, not forty-four servers or user trials. Calibration warnings: false precision/double-counting/correlated sources high; unavailable denominators and account-versus-person proxies high for source-era counts; selection effects high for this two-chapter route; base-rate/tiny-sample concerns moderate for behavioral extrapolation. Publication/survivorship bias possible but not demonstrated by an inspected corpus. Motivated estimates are a review risk; don't compute confidence from author prestige. P-values/statistical-significance issues not applicable. Nonquantitative fallback: strong/moderate decrease, no meaningful update, moderate/strong increase, with scope stated. Normative/theoretical N/A rows stay outside probability updates. # Prompt 6 — Full-unit scaffold and evidence ledger Reader response is unknown throughout. Purpose, spine and attention ratings are reviewer organization. | Fully read unit | Purpose/thesis; claims | Terms/examples/evidence | Counter-observations | Assumptions/questions | Spine/source | Attention | | --- | --- | --- | --- | --- | --- | --- | | Preface, all sections | Explain developer audience and route; C-001 background | JSON/web prerequisites, example conventions and structure | Narrative chapters have a broader audience | Expertise doesn't certify outcomes; O-08/18 | Orientation; P-0001 | Moderate | | Chapter 1, all prose + both footnotes + Figures 1-1–1-4 | Motivate interconnected services; C-001–005 | Social graph, standard layers, pair analogy, author's history | Email analogy imperfect; community growth disputed; future explicitly speculative | Value/reachability/current counts unresolved; O-07/15/20 | Motivation; P-0002–0007 | High | | Chapter 5, all sections + 44 listings + Figure 5-1 | Design tolerable extensions; C-006–022 | Unknown moods, farm fallback, spoilers, card state, polls/Move/events/groups/location/media, vocabularies, run context | Storage drops fields; rich types lose semantics; group/event gaps; sensitive violates recommendation; private-data caution | Real software/profile/context semantics require separate checks; O-03/09/13/14/19 | Method and boundary; P-0008–0024 | High | Chapter 5 provides explicit counterexamples/concessions; it doesn't present an independently executed cross-implementation test matrix. Preface has audience/permission limits, not empirical counterexamples to extension effectiveness. Chapter 1's future disclaimers limit forecasts. **Spine:** network lock-in motivates federation → shared data/API/protocol permits connections → unfamiliar data must remain tolerable → fallbacks and known vocabularies can preserve partial meaning → documented new vocabulary may attract implementers. **Weakest link:** defined/forwarded data→correct, safe receiver behavior. Repair requires profile-specific semantic and execution tests. Pair count→utility is a separate weak bridge; needs a value model beyond the diagram. | Evidence | Claims | Type/source | Independence | Quality/limits | IDs | | --- | --- | --- | --- | --- | --- | | E-01 | 001–005 | Source Preface/ch1 prose/4 figures | Single author | Direct exposition, dated counts/history not independently checked | P-0001–0007 | | E-02 | 006–021 | Complete ch5, code/figure | Same author | Illustrative design, explicitly fictional examples | P-0008–0024 | | X-01 | 001/002/005 | [W3C ActivityPub overview/profiles and authorization](https://www.w3.org/TR/activitypub/) | Primary standard, author-participation dependence | Two layers; one/both permitted; local authorization allowed; not runtime observation | Checked overview/profiles/§3.2/Appendix B.1–B.4 | | X-02 | 006/022 | [W3C AS2 core §5](https://www.w3.org/TR/activitystreams-core/#extensibility) | Same standards family | Unknown extensions don't stop processing; JSON-LD definitions matter; not server sample | §5 narrow reading | | X-03 | 013/019 | [W3C Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/) | Same standards family | Arrive uses location; duration spelling defined; no real check-in evaluation | Arrive/duration entries | | T-01 | 003/004 | Executed pair-count recomputation | Reviewer check of formal identity | N=0,1,4,8 gives 0,0,6,28 undirected pairs; no utility proof | ch1 104/117 | | T-02 | 018/019/022 | Executed local JSON parse and exact-key/mapping inspection | Reviewer source test, not outside witness | All 44 ch5 blocks parse; splits/waypoints share run:waypoints; nested Duration differs | ch5 3854/3665 | Count: **three external primary documents in one W3C standards family, zero independent empirical implementation/audience studies**. Two reproducible local checks are reviewer tests, not independent author testimony. T-02 directly contradicts local implied example claims; standards support narrow normative architecture and terminology. Don't multiply source-family repetition into independent confirmations. Reading plan completed: Preface→Chapter 1 all notes/figures→Chapter 5 all code/figure→bounded standards and offline checks. Future implementation route would prioritize Chapters 2–4/references (high attention), then verified profiles and authorized offline/network conformance tests (high). Do not skim unread security/implementation material into findings. Synthesize only after a complete chosen unit; stop any deployment inference at the current boundary. **Gate for Prompt 7 passes for this route:** exact identity/source integrity, complete chosen prose/inline/code/figures/apparatus, 24 located quotes, 22 voiced claims and reproducible checks available. No whole-book or actual-software certification. # Prompt 7 — Evaluation, repairs and actual updates **Strongest reconstruction, system inference:** independent services can share a defined social data model and exchange activities; receiving programs must tolerate unfamiliar extensions; designers can preserve base meaning and document new vocabularies; multiple implementers can make those vocabularies useful. This organizes the selected chapters into a clearer spine than a historical/technical tutorial necessarily intends. The author also names data loss, UI loss, access-control problems and sparse semantics, so a fair reading doesn't treat extensibility as magic enforcement. | Claim/voice | Support | Grade/reason | Strongest objection | Countercase/test, not necessarily observed | Current verdict/repair | | --- | --- | --- | --- | --- | --- | | C-001: ActivityPub has C2S and S2S layers; descriptive EA | ch1 160/196/217; X-01; Normative overview; two layers confirmed | A: direct checked normative rule or recomputed formal identity | Architecture alone doesn’t establish deployments | Normative document describes only one layer | Supported architecture, not both-layer deployment guarantee | | C-002: Standard federation means every server supplies the same C2S interface; RI system inference, NOT author sentence | ch1 198; X-01; Profiles required; specification permits one or both | N/A: ethical recommendation or rejected reviewer inference, not empirical scoring | Federation profile need not implement the client API | A valid federation-only profile defeats universal inference | Reject reviewer overreach; check each service/profile | | C-003: A complete undirected N-node graph has N(N−1)/2 potential pairs; mathematical EA | P-0003; T-01; Derivation/recomputation; boundary cases checked | A: direct checked normative rule or recomputed formal identity | Complete undirected graph assumptions may not hold | Any enumerated pair count differs under those assumptions | Supported conditional combinatorics; distinguish directed counts | | C-004: Network value rises as square of users and explains lock-in; causal EA | ch1 104/119/120; Utility/causal model needed; count analogy appears | D: count argument poorly matches universal value/causal conclusion | Potential ties aren’t measured utility or a sole lock-in cause | Unequal tie value or other switching causes defeat sufficiency | Repair to potential pairs can help explain one incentive; universal value/cause not established | | C-005: Nobody can kick you off the fediverse if standards are implemented; scope EA | P-0004; Governance/reachability evidence needed; broad statement appears | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Local peers still choose what they accept | A conforming peer refuses exchange or local service excludes an actor | Repair to no single global operator; no guaranteed peer acceptance | | C-006: Unfamiliar extensions must not stop AS2 processing; normative EA | ch5 121; X-02; Normative rule; checked core §5 supports tolerance | A: direct checked normative rule or recomputed formal identity | Normative tolerance isn’t actual processor behavior | Normative rule requires failure solely for unfamiliar extension | Supported conformance principle, not all-software observation | | C-007: Servers should preserve unknown properties for later consumers; practical EA | P-0009; ch5 130/1353; Pass-through model and storage evidence; code/explanation, no server test | B: direct local text/example supports mechanism, no live implementation test | Storage conversion can discard unknown fields | A tested processing path loses the field | Supported design recommendation; storage mapping can lose data | | C-008: An unaware receiving client may omit an extension representation; practical EA | P-0010; ch5 332; UI contract/test needed; text explains omission | B: direct local text/example supports mechanism, no live implementation test | Minimal or absent UI loses rich meaning | Receiver must render unknown term under a checked contract | Supported scoped recommendation, not runtime audit | | C-009: Fallback types and summaries can carry partial meaning; design EA | ch5 141/315/323; Example/type behavior; worked Plant/Create example | B: direct local text/example supports mechanism, no live implementation test | Fallback doesn’t supply game-specific side effects | Fallback cannot convey described minimal meaning | Supported illustrative mechanism; rich interaction not guaranteed | | C-010: New extension properties cannot require unaware software to change default behavior; design EA | P-0012; ch5 342/448/549; Unknown-field countercase; explicit spoiler demonstration | B: direct local text/example supports mechanism, no live implementation test | An optional flag can’t impose an unknown obligation | Every intended receiver enforces the added rule under a required contract | Supported design warning; separate-field version also withholds optional content | | C-011: Event acceptance targets the Invite, not the Event; textual/model EA | ch5 1976/2022; Worked invitation/response pair; code present | B: direct local text/example supports mechanism, no live implementation test | Data relation doesn’t implement private access | Example Accept object points at Event instead | Local example relation supported; live authorization not tested | | C-012: Client-only group routing is not built into base ActivityPub; dated behavior EA | P-0017; ch5 2353; Normative/group implementation study needed; author reports sparse semantics | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Dated sparse semantics don’t settle current extensions | A complete verified base client-only routing contract defeats categorical reading | Bounded 2024 assessment; current extension support not evaluated | | C-013: Arrive identifies its place through location; normative EA | P-0018; X-03; Vocabulary definition; location confirmed | A: direct checked normative rule or recomputed formal identity | Vocabulary correctness doesn’t prove check-in delivery | Normative Arrive identifies object as arrival place instead | Supported vocabulary distinction, not check-in runtime | | C-014: Leave check-ins protect current-location privacy; causal/UI from author rationale | ch5 2442/2512; Threat model/retention data needed; preference rationale appears | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Past location and recurring patterns remain revealing | History or repeated patterns reveal location despite delayed report | Repair to delayed report can omit present location; no privacy guarantee | | C-015: Move can redirect followers under alias conditions; dated behavior EA | ch5 1687–1752; Interoperability/profile tests needed; described Move/alsoKnownAs mechanism | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Reciprocal aliases don’t establish universal migration support | A target processor ignores Move despite data being present | Illustrated 2024 mechanism; current/all-server support unresolved | | C-016: Sensitive flag may fail to hide content in unaware clients; design EA | P-0020; Countercase and receiver test; source itself names failure | B: direct local text/example supports mechanism, no live implementation test | Display warnings aren’t authorization | Required receiver semantics always enforce hiding | Supported limitation; do not treat flag as access control | | C-017: Private contact data should not enter public actor data unintentionally; ethical/practical EA | P-0021; Normative privacy reasoning; caution explicit | N/A: ethical recommendation or rejected reviewer inference, not empirical scoring | Advice doesn’t quantify exposure risk | Value judgment not empirically falsifiable as stated; a chosen public business contact is a boundary case | Preserve caution without making it an audited safety guarantee | | C-018: The running context keeps splits distinct from waypoints; implied example claim IA | P-0022; ch5 3854; T-02; Inspect mapping; both map to run:waypoints | F: exact source example conflicts with its intended distinction or checked term | The context identifies two intended terms with one identifier | Equal mappings contradict intended distinct terms | Contradicted by exact local context; repair splits @id to run:splits in a proposed copy, never source | | C-019: The nested running split uses the standard duration term; implied example claim IA | P-0023; X-03; Exact key/vocabulary; source capitalizes Duration, standard is duration | F: exact source example conflicts with its intended distinction or checked term | Case matters; syntax parser accepts an incorrect term | Source key differs from normative term | Local case-sensitive term mismatch; proposed copy needs lowercase duration; no runtime loss claim | | C-020: Reusing recognized vocabularies raises interoperability prospects; comparative practical EA | ch5 2925/3621; Cross-implementation comparison needed; rationale and examples appear | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Recognized vocabulary need not match desired semantics | Receivers lack recognition or equivalent terms misfit domain | Reasonable conditional design rationale; benefit magnitude unmeasured | | C-021: Context inclusion policy needs two independent publishers and consumers; dated institutional EA | P-0024; Current institutional policy needed; source states 2024 criterion | C: conditional/dated assertion lacks the needed independent implementation or context evidence | Book’s policy report may age or omit conditions | Authoritative current policy specifies another criterion | Source-era report, not checked present policy or adoption guarantee | | C-022: All valid JSON examples prove secure interoperable implementation; RI system inference, NOT author sentence | T-02; ch5 1150/3111; Semantic/security/runtime checks needed; parser succeeds only | N/A: ethical recommendation or rejected reviewer inference, not empirical scoring | Successful parsing does not execute meaning, permission or transport | A syntactically valid alias/mismatched key defeats implication | Reject reviewer overreach; parse, semantic and runtime checks differ | **Distribution: A 4, B 6, C 6, D 1, F 2, N/A 3; total 22.** A supports formal/normative facts, not an application’s conformance. B supports scoped example/design reasoning. C holds current behavior, membership, privacy and adoption questions open. D caps the network-value explanation. The two F verdicts identify repairable local code terms; they don’t refute the extensible model. N/A separates ethical advice and rejected reviewer inference. Unread chapters receive no negative grades. ## Actual qualitative updates | Claim | Prior | Evaluated decisive input | Dependence | Actual update/posterior scope | | --- | --- | --- | --- | --- | | C-001 | Moderate | X-01 explicitly defines layers/profiles | Author participated in standards; normative text itself is checkable | Strong increase for defined architecture; deployment unknown | | C-003 | High conditional | T-01 enumeration 0/1/4/8 nodes | Formal calculation, not witness repetition | Retain high conditional arithmetic | | C-004 | Moderate concern | No utility measure follows from pair count | Same-source analogy | Moderately decreases universal explanatory confidence; bounded incentive survives | | C-006 | Uncertain | X-02 §5 tolerance requirement | Same primary standards family | Strong increase for normative rule only | | C-009 | Moderate mechanism | Generic type/summary and declared UI limits | Same author's demonstration | Moderate for illustrative fallback; no support-rate update | | C-014 | Moderate distinction | Past-place report can still reveal a path | No threat/outcome study | No measured update; privacy guarantee remains unresolved | | C-018 | Moderate expected distinctness | T-02 identical @id values | Direct executed inspection | Strong decrease; local distinctness contradicted | | C-022 | High distinction | All JSON parses despite two term defects | Reviewer source check | Retain distinction; reject universal safety/interoperability inference | No percentages are measured or invented. The most important update is the exact mapping mismatch, not the number of successful parser calls. ## Counter-observations and corrections Author-favorable observations: Preface states prerequisites; Chapter 1 admits its email analogy is imperfect and future ideas speculative; community influx brings controversy; Chapter 5 warns mapped storage can drop properties, fallback clients can omit activities, extra properties cost bandwidth, invitations need access-control coordination, groups lack built-in routing, sensitive violates the author’s own recommendation, and contact data can create privacy problems. These are operational limits, not merely cheerful disclaimers. Bias/fallacy scan: potential connections→value (C-004) risks an unsupported bridge/hasty causal explanation; the mathematical identity remains sound under its assumptions. Universal membership wording (C-005) can blur technical participation with social reachability, a scope ambiguity that a no-central-operator repair resolves at the cost of an absolute promise. Novel examples don’t prove current adoption; the author expressly calls them fictional, so a novelty fallacy isn't demonstrated. Authority bias is a reviewer risk because the author helps write standards; normative checks support exact rules, not every empirical claim. No claim that a group’s demographics cause unsafe behavior appears here. **Explicit correction record:** (1) preserve native `splits`→`run:waypoints`; in a proposed copy, change that mapping to `run:splits` to keep the intended terms distinct. (2) preserve native nested `Duration`; a proposed corrected standard term is lowercase `duration`. (3) preserve Chapter 1’s formula and Figure 1-2 caption; 4/8 nodes give 6/28 undirected pairs or 12/56 directed ordered pairs. The caption’s “each way” wording shouldn't become a second independent count or a utility measure. (4) Move and policy reports stay 2024-source descriptions; no current support claim. (5) C-002/C-022 are system overextensions, not author quotes. No source bytes, live account or code repository is modified. Repair verdicts: C-004/005/014 can narrow to mechanisms/conditions without rejecting federation; the rhetorical cost is loss of certainty about benefit, reach and privacy. C-018/019 are repairable local examples with no change to the chapter’s central model. The universal guarantees in reviewer C-002/022 are not repairable as guarantees; replace them with profile- and validation-specific questions. # Prompt 8 — Systems and intellectual context **Source-available 2024 context:** Prodromou reports participation in OStatus/StatusNet/pump.io and the W3C process; this is insider testimony, not independently verified full history. He situates AS2, JSON-LD, ActivityPub, earlier feeds and messaging in a technical lineage. X-01 verifies the Recommendation’s two layers and listed author participation; the review doesn't certify every timeline claim, account count or service description. **Institutional mechanism, reviewer inference:** shared protocols reduce one kind of boundary between independently controlled services; local authorization and support still determine effective exchange. Operators, client authors and vocabulary designers have different responsibilities. Extensions can preserve opaque data while changing UI or state only where a receiver implements them. A registry or documented vocabulary is coordination infrastructure, not compulsory adoption. **Economic/political context, source claim versus inference:** Chapter 1 describes subscriptions, advertising, cooperative models and switching costs; no actual company's present terms, incentives or motives are audited. C-003 counts possible pairs; network utility and switching costs require other evidence. Source-era growth predictions, political/privacy regulation references and corporate announcements remain dated discussion, not current policy findings. **Technological context:** namespace mappings, data storage and base types connect sender intent to receiver interpretation. The JSON-LD layer can expose a semantic problem hidden from a plain JSON parser (C-018/019/022); no complete current software compatibility survey is attempted. Documentation/license discussions remain source advice, not this note’s legal guidance. **Competing approaches, system positions:** restrict a project to base types; tolerate opaque extension data; implement richer terms in selected peers; or choose a different integration boundary. Each trades functionality, coordination and complexity. They aren't verified summaries of specific unreviewed products. An analogy to schema migration is convergent reviewer comparison, not a documented historical influence. **Missing perspectives:** operators who bear moderation/storage costs, failed extension implementers, users excluded from or harmed by communities, accessibility testers and developers outside the highlighted standards network. Named acknowledgments recognize collaboration without measuring decision authority. Later software support/terminology can alter evaluative context; no current adoption or forecast outcome enters the verdicts. # Prompt 9 — Inclusion, multicultural transfer and access **Textual strengths:** Chapter 1 acknowledges diverse service models and community controversy; Chapter 5 separates sender/receiver roles, admits unfamiliar-data/UI limits and warns against accidental contact-data exposure. Summary/name/icon fallbacks offer a way to represent otherwise unfamiliar interactions. These are mechanisms, not a finding that all users belong or all clients are accessible. **Structural inclusion limits:** local choice and reusable vocabularies can preserve some autonomy, but neither guarantees minority voice, equitable moderation, durable finances or migration support. The review doesn't infer behavior or safety from LGBTQ+, national or other demographic identities mentioned in the source. Account counts aren't counts of unique humans or measures of fair participation. Nontechnical users, people facing harassment and users with constrained bandwidth need further evidence beyond schema flexibility. | Context | Conditional transfer | Limit/supplement | | --- | --- | --- | | Independent server/operator | Trace actual profile and vocabulary handling | No guarantee every remote peer accepts the service | | Multilingual client | Treat language maps/fallback summaries as a design question | Selected examples aren't a language-access audit | | Low-bandwidth environment | Consider added property/data costs | No measured payload benchmark; twice the fields needn't mean twice the bytes | | Community with privacy concerns | Separate display hints from authorization and data publication | Don't use real location/contact information in proposed tasks | | Classroom or independent learner | Compare fictional examples and exact mappings offline | Modern-language/web prerequisites still impose reference burden | **Access audit:** source syntax is conversational, but JSON-LD, protocols, namespaces and HTTP raise reference density. Adult programming reading estimate, not a measured grade level. Five source figures are actually viewed: profile/UI feature labels, small/large graph, siloed server, federated servers and sending/receiving sequence. Code provides precise text but requires monospaced formatting and explanation. Image-only arrows need prose equivalents; color alone shouldn't carry role. No screen-reader, disability, neurodiversity or mobile-device effectiveness test is claimed. Internet/server expertise and money/time may constrain implementation; current pricing isn't checked. Reviewer supplements: qualified accessibility testing, operator/affected-user perspectives and authorized profile-specific compatibility evidence. Naming more communities alone doesn't establish equitable governance. No reader role, identity or desired platform is assumed. # Prompt 10 — One-note literature/permanent pipeline Fleeting **system** reminders: separate unknown-property data retention from visible behavior; check exact case/context before trusting a snippet; resolve current support only under a selected profile; don't infer friendship from mutual follows. These aren't reader reactions. ## Literature note: extension fallback loses meaning Prodromou asks senders to plan for unaware processors and admits generic summaries, dropped properties and omitted UI (P-0009/0010/0012/0013/0016). C-006–010 and X-02 support tolerance with bounded semantics. Link: [[#^pn-fallback|Permanent candidate]]. ^ln-fallback ## Literature note: syntax doesn't establish semantics All 44 chapter listings parse, while the running context merges `splits`/`waypoints` and nested `Duration` differs from the checked term (P-0022/0023; C-018/019; T-02). These are local source defects, not an actual server exploit. Link: [[#^pn-validation|Permanent candidate]]. ^ln-validation ## Literature note: a UI flag is not authorization The author warns that `sensitive` can display without hiding in an unaware client and cautions against publishing private contacts (P-0020/0021). C-016/017 don't certify any live service. Link: [[#^pn-policy|Permanent candidate]]. ^ln-policy ## Permanent candidate 1 — Define the loss in fallback behavior **Reviewer statement, not Prodromou's sentence:** Describe which meaning remains when a receiver ignores an extension; don't label partial representation complete support. **Confidence:** moderate design distinction; current processor behavior unknown. **Scope/conditions:** an extension and its base representation must be identified; use only tested or explicitly illustrative paths. **Uncertainty:** unfamiliar clients may preserve, omit or display different fragments. **Countercase:** a required and verified peer contract can support full extended behavior. **Stop:** withdraw a full-support promise when any required peer/path is untested. Source [[#^ln-fallback|Literature note]], C-006–010. Suggested filename `Fallback compatibility must name the meaning it loses.md`. ^pn-fallback ## Permanent candidate 2 — Validate syntax, identifiers and behavior separately **Reviewer statement, not Prodromou's sentence:** A parser check, a context/term check and an execution check answer different questions. Report each result at its actual layer. **Confidence:** high as a validation distinction, not a product verdict. **Scope/conditions:** exact input/version and expected identifiers must be known; offline key checks don't model a full processor. **Uncertainty:** other semantic/runtime issues may remain. **Countercase:** a verified full pipeline may demonstrate more than an isolated parser. **Stop:** don't claim interoperability or safety from syntax-only success. Source [[#^ln-validation|Literature note]], C-018/019/022. Suggested filename `Parsing success does not certify protocol semantics.md`. ^pn-validation ## Permanent candidate 3 — Keep display hints separate from access control **Reviewer statement, not Prodromou's sentence:** A receiver-dependent warning can shape presentation without preventing disclosure to the receiver. **Confidence:** moderate distinction; no live service audit. **Scope/conditions:** examine an identified flag/content path; follow actual authorization rules before any sensitive use. **Uncertainty:** support and rendering vary; this review supplies no deployment guarantee. **Countercase:** independently enforced access control can prevent a requester from obtaining content at all. **Stop:** do not use a display flag as the only protection for private data. Source [[#^ln-policy|Literature note]], C-016/017. Suggested filename `Content warnings do not establish an access boundary.md`. ^pn-policy **Local structure map:** [[#^ln-fallback]] ↔ [[#^pn-fallback]]; [[#^ln-validation]] ↔ [[#^pn-validation]]; [[#^ln-policy]] ↔ [[#^pn-policy]]. Each link names an actual block. User override retains all candidates and maps here instead of separate files or new MOCs. A bounded MOC filename search finds [[3. Resources/MOCs/MOC · Voluntary Federation Governance]]; its opening asks how noncoercive bodies stay together and links a note about exit rights. That's a governance adjacency (reviewer inference), not technical protocol evidence. The MOC isn't changed and no external reciprocal link is claimed. The local LN/PN pairs supply reciprocal links within the required one-note artifact. **Do not attribute to author:** all PN statements, test-derived repairs, system C-002/C-022, reader priors, validation-layer organization, governance/access inferences, cross-domain analogy, future experiments/maps and any actual-performance promise. Native quotations retain author/code voice; source speculation isn't realized history. No Courtney opinion appears. # Prompt 11 — Teaching pack Audience: voluntary developers or technically curious learners with basic JSON/web knowledge. Objectives: distinguish C2S/S2S, identify fictional extensions, trace unknown-data loss, spot the two local term defects, and state why parser success doesn't certify execution. Prerequisites: objects/keys, URL identifiers and basic client/server roles. Vocabulary: AS2, context, namespace, base type, extension, fallback, authorization and interoperability. Sequence: (1) disclose full/unread route and the fictional status; (2) trace Figure 5-1 in words; (3) compare mood/farm/spoiler examples; (4) distinguish local code/context checks from live software; (5) review the sensitive exception; (6) classify what each evidence item supports. No real posting/account or real personal data enters the lesson. Cases: an unfamiliar client sees a summary but can't play the farm game (C-009); a client ignores a spoiler/sensitive flag (C-010/016); a running context silently assigns two intended concepts one identifier (C-018). Activities: label sender/receiver responsibilities; inspect both mapping keys; classify parser, semantic and runtime questions. An offline thought exercise can examine whether a flag is needed for correctness without pretending a real client has been tested. Discussion: What remains after graceful degradation? Who decides which profile/extension to implement? What does the author concede about groups and invitations? Can 28 possible undirected ties measure eight users' welfare? Reflection: name a current-support question that remains unanswered, without disclosing personal account data. Misconception checks: JSON-valid≠semantically correct; federation support≠C2S API support; base type≠rich UI; sensitive flag≠authorization; membership≠universal peer acceptance. Assessment options: label five protocol/data roles, identify one exact correction and give a countercase/stop for one PN. Pass means accurate scope and attribution, not endorsement of a network. Facilitator cautions: the email analogy is admitted imperfect; don't import every email behavior into ActivityPub. Report unread Chapters 2–4/6 and source-era counts/policies; don't teach current support as settled. Never attribute PNs or parser-derived repairs to the author. Location/contact data and exclusion can be sensitive; use synthetic examples and allow passing. Accessibility adaptations: text equivalents for arrows, readable code, no color-only tests, explain namespaces before jargon, offer written instead of spoken responses. Multilingual adaptation needs qualified terminology, not automatic translation of assumptions. Further reading: bounded W3C X-01–03, the unread technical chapters and official errata if later checked; no external product receives a verdict. # Prompt 12 — Inactive experiments, routing and drift Already done: preserve source/quotes, compute conditional pairs, parse the 44 code blocks and inspect mappings/terms. Consider: full Chapters 2–4 and references before any implementation; primary profile/conformance evidence before runtime claims. Avoid the most likely misuse: deploying copied examples or promising privacy/interoperability because this review's parser passed. Don't publish contacts, routes, heart-rate data or actual activity from a hypothetical example. PARA proposals: **Projects:** none activated; a real chosen interoperability task could later become a project with actual scope. **Areas:** development responsibilities only if the reader actually has them; none inferred. **Resources:** vocabulary, local validation distinctions and three candidates remain reusable here. **Archives:** canonical review records this exact edition/selected route. No other notes or tasks are changed. The following are inactive, reversible reviewer experiments. They test transferred PN ideas, not the author’s current-software claims. Activation date T is a future chosen date. No network, account, participant study, outreach or publication is authorized by this table. | Experiment | Claim/PN | Hypothesis | Action | Measure | Duration | Stop | Conditional review date | | --- | --- | --- | --- | --- | --- | --- | --- | | EX-01: fallback inventory | C-009/010; PN1 | A paper trace can name retained/lost meaning | Privately compare one synthetic extension and its base fields | Explicit retained/lost/unknown labels, no deployment verdict | One two-case trace | Stop when an assumption needs real processor behavior | T + 1 day | | EX-02: context distinction | C-018/019; PN2 | Separate key/mapping checks can reveal syntax-hidden defects | Inspect a private synthetic corrected copy and original side by side | Distinct intended IDs and correct standard spelling; separately record parser result | One local comparison | Stop before changing original or claiming full JSON-LD execution | T + 1 day | | EX-03: warning boundary | C-016/022; PN3 | A role diagram can separate UI hints from requester access | Draw an offline synthetic aware/unaware client path | Identify where content already exists versus where display changes | One diagram pass | Stop if actual private data or network traffic is proposed | T + 2 days | Decision rules: adopt a checklist if every case records its layer/limits; adapt it if labels overlap; further test only with a separately chosen authorized scope; reject the aid if it continues to conflate semantics/runtime or warning/access; defer if expected meanings or required profile are unknown. Rejection revises PN1 fallback loss, PN2 validation boundaries or PN3 warning/access distinction respectively. A failed aid doesn't prove ActivityPub as a whole fails. | Evaluative drift | Monitor only if used | Frequency/expiration | Early trigger | | --- | --- | --- | --- | | Protocol/extension/profile changes | Official W3C published specification and relevant maintained extension documentation | Before implementation; reassess within one year of chosen use | Changed normative clause or extension | | Actual implementation support | Exact release/profile/test evidence from selected implementation | Before relying on behavior; each upgrade | Version or profile change | | 2024 accounts/policy/adoption | Appropriate current primary statistics/policy, not guesses | Recheck before repeating as current | New date or contradicting official report | | Privacy/UI/accessibility | Authorized actual tests and voluntarily supplied barriers | Each chosen release/use, no surveillance | New content path, client or reported barrier | Non-drifting: source SHA/wording, first-edition statement, inspected code defects in these bytes, conditional graph identity and this reading route. Don't repeatedly reevaluate fixed wording unless another edition or extraction error appears. No reminder/monitor is activated. # Prompt 13 — Visual pack and completion Three appropriate maps separate architecture, evidence layers and decisions. Colors: green thesis, blue concepts, orange takeaways, purple connections/gaps. Dashed edges/nodes mark untested or unsupported transitions; each map includes a full prose equivalent. Reviewer organization, not source-author diagrams. ## Map 1 — Architecture and extension meaning Purpose: connect data and participant roles without guaranteeing every implementation. Left-to-right layout; C-001/006–010/016, P-0005/0008–0012/0020, X-01/02. Group data, transfer and display; the warning node limits semantic preservation. ```mermaid flowchart LR A["AS2 data + extension terms"] --> B["Sending client / server"] B --> C["Receiving server / client"] C --> D["Base meaning may remain"] C -.-> E["Rich UI, warning enforcement or side effects: test required"] F["Only supported protocol profiles apply"] -.-> B classDef thesis fill:#d9ead3,stroke:#38761d; classDef concept fill:#cfe2f3,stroke:#0b5394; classDef takeaway fill:#fce5cd,stroke:#b45f06; classDef gap fill:#eadcf5,stroke:#674ea7,stroke-dasharray:5 5; class A thesis;class B,C concept;class D takeaway;class E,F gap; ``` Prose equivalent: data with extension terms moves through sending and receiving roles. A base representation may survive. Rich interface, display-warning enforcement and side effects branch to a dashed test-required node; supported protocol profiles constrain the sending path. No connection guarantees an unaware receiver implements a novel interaction. ## Map 2 — Validation and evidence gaps Purpose: stop syntax checks becoming product certification. Top-to-bottom, C-018/019/022, P-0022/0023, T-02/X-03. Separate checked layers from untested runtime. ```mermaid flowchart TD A["44 selected JSON listings parse"] --> B["Syntax check passes only"] C["Exact keys/context inspected"] --> D["splits alias and Duration mismatch found"] B -.-> E["Not a semantic or interoperability certificate"] D --> F["Propose local corrections; preserve original"] E -.-> G["Actual profile, authorization, delivery and UI untested"] classDef thesis fill:#d9ead3,stroke:#38761d; classDef concept fill:#cfe2f3,stroke:#0b5394; classDef takeaway fill:#fce5cd,stroke:#b45f06; classDef gap fill:#eadcf5,stroke:#674ea7,stroke-dasharray:5 5; class A,C concept;class B thesis;class D,F takeaway;class E,G gap; ``` Prose equivalent: 44 successful parser calls establish syntax only. A separate exact-key/context check finds two local defects and leads to proposed corrections while preserving source bytes. A dashed warning rejects the move from parsing to semantic/interoperability certification, and a further dashed node lists untested profile, authorization, delivery and UI behavior. No arrow represents a full processor or deployment test. ## Map 3 — Responsible study/use decision Purpose: route proposed action without activating it. Top-to-bottom decision tree, C-002/022 and PN1–3; P-0001/0016/0020. ```mermaid flowchart TD A["Choose a real study purpose"] --> B{"Need live implementation claim?"} B -->|no| C["Use selected offline distinctions with limits"] B -.->|yes| D["Read implementation chapters + define exact profile"] D -.-> E["Obtain separately authorized actual tests"] C --> F["Record uncertainty; revise candidate if labels fail"] E -.-> G["No posting/account action authorized by this review"] classDef thesis fill:#d9ead3,stroke:#38761d; classDef concept fill:#cfe2f3,stroke:#0b5394; classDef takeaway fill:#fce5cd,stroke:#b45f06; classDef gap fill:#eadcf5,stroke:#674ea7,stroke-dasharray:5 5; class A thesis;class B concept;class C,F takeaway;class D,E,G gap; ``` Prose equivalent: choose an actual purpose. If it doesn't need a live behavior claim, the bounded offline distinctions can support study with recorded uncertainty and candidate revision. If it does, read the currently unread implementation chapters, define a profile and obtain separately authorized tests. A final dashed stop records that this review doesn't authorize posting/accounts. Implementation layout: one card per map, colored concept boxes and legible arrows above a text panel listing claim/P-IDs, gaps and prose equivalent; don't depend on icons/color alone. Single-note override creates no visual file. Idea Compass: Parents—federated protocols and linked-data modeling; Children—[[#^pn-fallback]], [[#^pn-validation]], [[#^pn-policy]]; Friends—schema validation, progressive interface support, operator governance; Competitors—base-only implementation, different integration boundaries and alternative receiver contracts. These are reviewer conceptual relationships, not inspected external product claims. Omitted forms: no causal loop because network-value/lock-in effects aren't measured; no population chart because source-era counts lack a verified denominator here; no historical timeline because the full lineage isn't independently checked; no stakeholder power diagram because actual institutional authority isn't established. Vocabulary, evidence and routing tables already provide comparison/action detail, so redundant diagrams add no checked information. ## Session completion check All **Prompts 0–13** produce saved usable output, none skipped or remaining, next_prompt null. Complete means the chain finishes for the declared selected route, not full-volume or implementation reading. Adaptations: native Layer 1 replaces unverified Reader record; single note retains all LN/PN/visual candidates; qualitative judgments replace invented probabilities; code evaluation uses actual bounded offline checks; no network activity. Amazon destination/cover remain unverified/null. Coverage: full Preface, Chapter 1 including both notes/four figures, Chapter 5 including all prose/44 listings/one figure, and identity text. Other bodies remain not evaluated except navigation-heading inspection. Highest-consequence gaps: (1) unread implementation chapters and actual profile tests before a software promise; (2) independent runtime/privacy/accessibility evidence; (3) current statistics/policy and independent history; (4) unread references/paratext before their evaluation. Introduced assumptions: proposed reader purpose, qualitative priors, reconstructed spine, operational definitions, competing positions, PN candidates, teaching/actions and visual organization. None is Courtney's belief or the author's quoted sentence. Native quotes preserve code defects; explicit correction record identifies proposed repairs without source edits. Primary W3C checks are bounded and aren't a fresh full-standards audit. Source/hash/package/quote audit doesn't prove live rendering or Sync. Root independent review determines final tracking and temporary-file deletion after verification. This artifact doesn't claim shared inventory update or cache cleanup already occurred. Drive original and Kindle remain unchanged; no network posting, account creation or outreach occurs. Independent finalization: root verifies the saved note and source, deletes this book’s temporary source and extraction, and confirms cleanup. Inventory refresh remains unverified at finalization; the shared log and inventory annotation record the observed updater outcome. The updater uses the current no-iCloud vault. Live Obsidian rendering and Sync remain unverified.