{"id":"4c0d3f46-9380-452f-a274-81980f9c01e4","arxiv_id":"2505.22962","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A ten-component framework shows how four decentralized social media protocols allocate power over identity, curation, and infrastructure in different ways.","lead":"This paper builds a shared vocabulary for describing how decentralized social media protocols distribute control. Comparing ActivityPub, AT Protocol, Nostr, and Farcaster, it shows that each protocol makes different trade-offs in who holds power over identity, curation, and infrastructure.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Framework's universality is unsupported: the lexicon is induced from four server/relay-based protocols, and Tables 2-3 already show optional components; an out-of-sample P2P test (Secure Scuttlebutt) is needed.","rationale":"The reader's weakest assumption concerned the sufficiency of documentation and insider interviews for characterizing power. I agree that the qualitative evidence base is thin, but the more fundamental gap is the universality of the framework itself. Even perfectly reliable informants who know the four protocols extremely well cannot establish a \"must define\" claim about all feed-based decentralized social media protocols; the claim requires either a theoretical saturation argument or an out-of-sample test. The paper's own N/A entries in Tables 2-3 already indicate that the component set is not uniformly mandatory, which weakens the wording of the central claim. None of this invalidates the framework as a comparative description of ActivityPub, AT Protocol, Nostr, and Farcaster, and the power analysis in §4.4 is plausible and well grounded for those cases. The appropriate resolution is to keep the conditional acceptance but add a concrete condition: either demonstrate the framework on a structurally different feed-based protocol such as Secure Scuttlebutt, or soften the claim to the studied protocols. This matches the reader's CONDITIONAL verdict, so no change to the verdict is needed; I add a sharper, more actionable condition.","tokens_in":21531,"tokens_out":5629,"duration_ms":58568,"concrete_test":"Perform a component-by-component mapping of Secure Scuttlebutt (SSB) onto the framework in §4.1-4.2, using only SSB's official documentation and independent of the paper's interview data. Have two researchers separately fill Tables 2 and 3 for SSB, flagging any component that (a) has no referent, (b) requires a new category, or (c) can only be made to fit by redefining SSB's core mechanics (local-only feeds, gossip replication, no required server). If either coder reports a required redefinition, the \"any feed-based protocol must define\" claim fails as stated; the paper should then either revise the claim to \"the four protocols studied\" or demonstrate that SSB fits without ad hoc modifications.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim in §1 is that the framework offers \"a consistent lexicon of the core socio-technical components that any feed-based decentralized social media protocol must define.\" That universality claim is load-bearing: if the lexicon is not general, the contribution shrinks to a description of four chosen protocols. Two problems stand out. First, the paper's own Tables 2 and 3 contain N/A cells: ActivityPub, Nostr, and Farcaster have no Aggregator, so not all listed components are mandatory even within the sample. The \"must define\" claim is therefore already overstrong internally. Second, the framework was inductively derived in §3.2 from four protocols that all share a client/server-relay architecture: instances, PDSs, relays, and hubs (§3.1). No peer-to-peer feed-based protocol was included. Consider Secure Scuttlebutt (SSB), a mature feed-based decentralized protocol with no required servers: feeds are local append-only logs replicated by gossip, and \"pubs\" are optional helpers. SSB has no protocol-defined \"Space\" whose data live on a \"Server,\" and identity storage is the same local log rather than a subset of server storage. If SSB cannot be mapped onto Tables 2-3 without stretching categories or adding new components, the framework is sample-derived, not a universal lexicon. The insider interviews (P1-P10) cannot resolve this because none addresses out-of-sample architectures.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper develops a conceptual framework for analyzing the politics of decentralized feed-based social media protocols. The framework consists of four architectural components (Clients, Spaces, Servers, Aggregators) and six interaction components (Actions, Feeds, Space Storage, Identity Storage, Space Curators, Personal Curators). The authors apply it to ActivityPub, AT Protocol, Nostr, and Farcaster, drawing on protocol documentation, media coverage, firsthand platform use, and ten interviews with developers and experts. They use the framework to describe how each protocol distributes control and to surface three cross-protocol axes of power: over identity, over curation, and over infrastructure. The paper claims to provide a consistent lexicon for any feed-based decentralized social media protocol and argues that protocol design should be a central site of analysis for CSCW research.","tokens_in":21819,"tokens_out":3428,"duration_ms":38015,"significance":"If the framework's generality claim held, the paper would give researchers and designers a common vocabulary for comparing decentralized social media protocols and would usefully shift attention from individual platforms to the protocols underneath them. The manuscript has real strengths: it is grounded in a substantial body of documentation and media sources, it triangulates those sources with first-hand usage and interviews, it is transparent about its inductive process, and it presents the four protocol case studies in a way that is accessible and informative. The three power axes (identity, curation, infrastructure) are a valuable analytic contribution even if the universal-lexicon claim is relaxed. The paper is careful in places to present the framework as an analytical lens rather than a formal model, and the discussion of re-centralization risks is well aligned with prior literature. However, the load-bearing universality claim is not supported by the evidence presented, and the qualitative coding method is underspecified relative to the article's aspirations.","major_comments":[{"comment":"The central contribution is stated as 'a consistent lexicon of the core socio-technical components that any feed-based decentralized social media protocol must define' (§1), but the paper's own tables contradict the 'must define' wording. Table 2 lists 'N/A' for Aggregators in ActivityPub, Nostr, and Farcaster, and §4.1 explicitly says Aggregators are 'occasionally present.' Thus not all listed components are mandatory even within the four-protocol sample. Please either reformulate the claim as describing components that feed-based protocols commonly instantiate, or provide an explicit definition of what 'must define' means and a scope condition under which the claim holds. This is not a cosmetic wording issue: it is the paper's advertised contribution.","section":"§1, §4.2, Tables 2 and 3"},{"comment":"The framework is inductively derived from four protocols that all share a client/server-or-relay architecture: ActivityPub instances, AT Protocol PDSs, Nostr relays, and Farcaster hubs. No peer-to-peer feed-based protocol is included. To support the universality claim, an out-of-sample test is needed; for example, Secure Scuttlebutt (SSB) is a mature feed-based decentralized protocol with no required servers, where feeds are local append-only logs replicated by gossip and 'pubs' are optional. It is not clear how SSB would map onto the Space/Server/Identity-Storage categories without stretching or adding components. If the framework cannot accommodate such a protocol, the contribution should be narrowed to the class of server/relay-based feed protocols, which would still be useful but is materially weaker than the stated claim.","section":"§3.1–§3.2, Figure 1, Tables 2–3"},{"comment":"The qualitative method is under-specified in ways that affect the validity of the 'validated in interviews' language used in §4.3. The paper does not provide a codebook, a description of how documentation and media sources were coded, or any inter-rater reliability assessment, and the ten interviewees are all protocol developers or experts with a stake in the protocols they discuss. No users, independent critics, or adversarial stakeholders were interviewed. Receiving feedback from participants on a draft of the framework (§3.3) is a member-checking step, not independent validation. Please describe the analytic procedure more fully and either soften the validation claim or add evidence that the framework was tested against perspectives other than those of its creators and advocates.","section":"§3.2–§3.3, §4.3"}],"minor_comments":[{"comment":"The table entry 'No Specific Name' for Space and Client in Nostr and Farcaster is ambiguous: it could mean the protocol does not define a Space-like concept, or that the concept exists without a canonical term. The caption says 'Nostr and Farcaster have Space-like concepts without specific names,' but the table itself does not make this distinction clear.","section":"Table 2"},{"comment":"The sentence 'Distributing the ability to do certain tasks, e.g., moderate and filter, across components can decentralized power over curation' contains a typo: 'can decentralized' should read 'can decentralize.'","section":"§5 (Discussion, first bullet list)"},{"comment":"The sentence 'This creates a clear division of roles' is confusing because the preceding text contrasts Identity Storage (a data store) with Personal Curators (functional mechanisms), which are not two roles of the same type. Consider clarifying that the distinction is between stored user preferences and the interface mechanisms that act on them.","section":"§4.2 (Personal Curators)"},{"comment":"The interview quotes in §4.4 are vivid and useful, but the paper does not say what interview protocol or questions guided the sessions. Including an interview guide or a supplementary description would help readers assess how much the quotes were prompted by the framework presented to participants.","section":"§3.3, Table 1"},{"comment":"The definition of 'protocol' as 'a set of rules governing the exchange of data between defined communications channels' is followed by a statement that protocols are 'inherently normative.' This conceptual move is fine, but the paper could engage more with the standards literature (e.g., work on standards as political artifacts) to support the claim that protocols allocate power; the current support is mostly by assertion.","section":"§2.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is a good fit for CSCW's qualitative/socio-technical scope, and the descriptive case material is likely to be of broad interest. My main concern is the gap between the strong 'any feed-based protocol' universality claim and the evidence base of four server/relay-based protocols; I do not see this as an unfixable flaw, but it requires a substantive reframing or an out-of-sample demonstration. The method section also needs more detail before the framework can be taken up by other researchers. I have no concerns about novelty or attribution: the prior literature is engaged and the contribution is clearly positioned relative to existing work on decentralized social media."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the ten-component lexicon is a genuinely useful contribution, and the four-protocol comparison is well done. The overbroad claim that every feed-based decentralized protocol 'must define' these components is not supported by their own tables—three of the four lack Aggregators—and an out-of-sample P2P protocol like Secure Scuttlebutt would likely break the framework. That's fixable by softening the claim or adding a test.\n\nWhat's new: prior work focuses on Mastodon or single platforms; this gives a shared vocabulary (Clients, Spaces, Servers, Aggregators; Actions, Feeds, Space/Identity Storage, Space/Personal Curators) and applies it across ActivityPub, AT Protocol, Nostr, and Farcaster. The three axes of power (identity, curation, infrastructure) are a nice way to surface trade-offs. The descriptions are grounded in docs and media, and the interviews give useful insider perspective. The paper is careful to present the framework as an analytical lens, not a formal model.\n\nSoft spots: the universality claim is the main one. Tables 2-3 have N/A cells, and all four protocols share a server/relay architecture. SSB is the obvious counterexample. The inductive derivation from the same four protocols plus member-checking with their developers creates a mild confirmation loop. That doesn't sink the framework for the protocols it covers, but it does mean the 'any feed-based' language should go. The method section is also thin—no codebook, no inter-rater reliability, no shared data—and the interviews are all insiders. For a conceptual paper that's acceptable if the claims are scoped, but it shouldn't be read as an authoritative empirical account of protocol politics. The power analysis leans on the interviews for interpretation, so it reflects developer perspectives more than user or critic perspectives.\n\nNet: this is a solid conceptual paper for the CSCW community. It deserves peer review, but the revision should either test the framework on a P2P protocol or clearly scope it to server/relay-based protocols. I'd also ask for a limitations section that acknowledges the insider interview bias and the missing codebook.","headline":"A genuinely useful comparative lexicon for four major decentralized social protocols, but the 'any protocol' universality claim needs to be reined in or tested out-of-sample.","tokens_in":22333,"tokens_out":2196,"would_cite":true,"duration_ms":23049,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Decentralized social media protocols are political artifacts: a new component-based framework makes visible and comparable who controls identity, curation, and infrastructure in ActivityPub, AT Protocol, Nostr, and Farcaster.","keywords":["decentralized social media","social media protocols","ActivityPub","AT Protocol","Nostr","Farcaster","platform governance","power"],"falsifier":"Give independent coders the paper's ten-component lexicon and only the public protocol documents, have them assign ownership and decision rights for each component in ActivityPub, AT Protocol, Nostr, and Farcaster, and measure inter-rater agreement; if agreement is no better than chance, the claimed consistent lexicon does not actually support comparison. A complementary empirical check would trace who can technically delete or block a user's content in each protocol—e.g., whether a relay operator can silence an AT Protocol account, or whether a Farcaster hub can refuse data—and compare the resulting power map to the paper's.","tokens_in":21341,"feed_emoji":"⚖️","tokens_out":7594,"duration_ms":70210,"temperature":0.7,"pith_summary":"The paper argues that decentralized social media protocols are not neutral plumbing: each one encodes decisions about who may control identity, content curation, and the underlying infrastructure. To make those decisions visible and comparable, it proposes a shared vocabulary of ten socio-technical components that any feed-based protocol must define—four architectural (Client, Space, Server, Aggregator) and six interaction-level (Actions, Feeds, Space Storage, Identity Storage, Space Curators, Personal Curators). Applying that vocabulary to ActivityPub, AT Protocol, Nostr, and Farcaster shows that 'decentralization' is not a single state but a set of trade-offs: each protocol distributes power across these components differently, and the arrangement determines whose power can offset whom. A sympathetic reader would care because researchers and designers currently lack a consistent way to compare protocols, and this framework supplies one, making the politics of infrastructure discussable and designable.","feed_headline":"Four decentralized protocols, four distinct answers about power","feed_subtitle":"One shared vocabulary maps who controls identity, curation, and infrastructure across four major protocols.","key_machinery":"The load-bearing mechanism is the framework itself: a consistent lexicon of ten components—four architectural (Clients, Spaces, Servers, Aggregators) and six interaction-level (Actions, Feeds, Space Storage, Identity Storage, Space Curators, Personal Curators)—that any feed-based social media protocol must define. The framework's power comes from using the same words across protocols, so ownership of each component can be assigned to a concrete actor (user, server admin, client developer, network operator) and compared. The layout of components—who is connected to whom, whether data flows through an aggregator, whether identity keys live on servers or in users' wallets—is what exposes which actors can offset or dominate each other's power.","core_discovery":"On the paper's own terms, the central discovery is that the politics of a decentralized social media protocol can be read off the arrangement of its components. The framework's four architectural components (Clients, Spaces, Servers, Aggregators) and six interaction components (Actions, Feeds, Space Storage, Identity Storage, Space Curators, Personal Curators) give every protocol the same descriptive language. Read through that language, ActivityPub appears as a federation of independently owned instances where server admins hold most identity and curation power; AT Protocol as a single network-wide space coordinated by a relay, with modular curation but a de facto reliance on Bluesky PBC's infrastructure; Nostr as relay-based and client-centric, giving users self-custodied keys and minimal moderation; and Farcaster as fully replicated hubs anchored to Ethereum, with curation concentrated in clients and high infrastructure costs. The comparison yields three cross-cutting axes of power—over identity, curation, and infrastructure—along which each protocol makes different trade-offs, meaning decentralization is not a fixed end state but a series of consequential design decisions.","pith_inferences":["Editorial inference: the framework could be applied prospectively to newer or lesser-known protocols, and to changes in these four, as a comparative audit that predicts which actors will accumulate power before they do.","Editorial inference: the three power axes suggest a testable design hypothesis the paper only gestures at—separating identity from infrastructure while distributing curation may reduce the worst re-centralization; a small comparative deployment study could test it.","Editorial inference: the same component lexicon could be applied to centralized platforms to quantify how concentrated their power is, turning 'centralized vs. decentralized' into a gradient rather than a binary.","Editorial inference: because the interviews were developer- and expert-insider, a natural next test would be a user-side evaluation of whether users actually experience the power allocations the framework predicts, such as whether Nostr users feel they own their identity."],"forward_implications":["Researchers can stop treating Mastodon as the default example of decentralized social media; the same vocabulary applies to all four protocols and makes cross-protocol comparison direct.","Protocol designers can see decentralization as three separable design choices—identity, curation, and infrastructure—and combine them deliberately instead of assuming one architecture equals decentralization.","Cost and expertise barriers mean infrastructure power can re-concentrate in practice even when the architecture is formally decentralized; AT Protocol's relay and Farcaster's hubs illustrate this.","The framework gives a concrete target for governance and tool-building: altering who owns a component, or adding new components, changes the power balance without abandoning the protocol."],"supporting_citations":[{"why":"W3C ActivityPub specification; supplies the protocol's own account of instances, client-server and server-to-server APIs, and actions.","marker":"[64]"},{"why":"AT Protocol specs; defines the PDS and relay data model the paper maps onto Servers and Aggregators.","marker":"[85]"},{"why":"Notes on running a full-network atproto relay; grounds the claim that relays carry heavy technical and financial burdens, concentrating infrastructure power.","marker":"[76]"},{"why":"Nostr's self-description; source for the relay-based architecture, cryptographic keys, and censorship-resistance goals.","marker":"[78]"},{"why":"Farcaster architecture documentation; source for Gossipsub-based full replication and hybrid server/blockchain storage.","marker":"[33]"},{"why":"Farcaster's 'sufficiently decentralized' framing; source for the claim that users own accounts and move between apps.","marker":"[34]"},{"why":"Winner's 'Do Artifacts Have Politics?' provides the paper's theoretical premise that technical artifacts embody power relations.","marker":"[101]"},{"why":"Masnick's 'Protocols, Not Platforms' supplies the motivating argument that open protocols rather than platforms can decentralize social media.","marker":"[71]"}],"fun_headline_variants":["Four protocols, three axes of power over social media","Decentralization is a design choice: a framework for four protocols","The hidden politics in decentralized social protocols","Who really controls decentralized social media? A framework","Four protocols, four answers: who holds the power"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"If protocol documentation and ten developer/expert interviews do not capture how power actually operates in these systems—because developers have vested interests, and ordinary users and critics were not interviewed—then the framework's account of who holds power could be systematically skewed.","fun_headline_variants_meta":{"raw":{"variants":["Four protocols, three axes of power over social media","Decentralization is a design choice: a framework for four protocols","The hidden politics in decentralized social protocols","Who really controls decentralized social media? A framework","Four protocols, four answers: who holds the power"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000846,"raw_usage":{"total_tokens":3675,"prompt_tokens":931,"completion_tokens":2744,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":547,"completion_tokens_details":{"reasoning_tokens":2669}},"tokens_in":547,"tokens_out":2744,"duration_ms":17603,"temperature":1.0,"reasoning_tokens":2669,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T12:55:46.647419+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Give independent coders the paper's ten-component lexicon and only the public protocol documents, have them assign ownership and decision rights for each component in ActivityPub, AT Protocol, Nostr, and Farcaster, and measure inter-rater agreement; if agreement is no better than chance, the claimed consistent lexicon does not actually support comparison. A complementary empirical check would trace who can technically delete or block a user's content in each protocol—e.g., whether a relay operator can silence an AT Protocol account, or whether a Farcaster hub can refuse data—and compare the resulting power map to the paper's.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"W3C ActivityPub specification; supplies the protocol's own account of instances, client-server and server-to-server APIs, and actions."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"AT Protocol specs; defines the PDS and relay data model the paper maps onto Servers and Aggregators."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Notes on running a full-network atproto relay; grounds the claim that relays carry heavy technical and financial burdens, concentrating infrastructure power."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Nostr's self-description; source for the relay-based architecture, cryptographic keys, and censorship-resistance goals."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Winner's 'Do Artifacts Have Politics?' provides the paper's theoretical premise that technical artifacts embody power relations."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Masnick's 'Protocols, Not Platforms' supplies the motivating argument that open protocols rather than platforms can decentralize social media."}],"review_version":1}