Shared semantics are not a walled garden: where ARC meets the open web
If two sites each implement identity, comments, reactions, content structure and publishing from scratch, they have a hard time talking to each other naturally. Both may be speaking HTTP and still not know who sent a response, whether it can be verified, how it should be displayed, who may delete it, or whether the data should be synchronised. So most interaction today either falls back to features inside a single platform, or asks the author to assemble protocols, deploy endpoints and handle spam and moderation on their own.
Readers see this break in the browser easily enough. An independent article can be linked, screenshotted and copied into another community, and the original site usually has no idea any of it happened. Even when someone writes a serious response on their own site, neither side is necessarily able to show that relationship. A plain hyperlink is enough to send someone somewhere. It is not enough to handle authorship, moderation, deletion, notification or follow-up interaction. The hard part of cross-site conversation usually hides where readers cannot see it.
ARC tries to solve a smaller and more realistic part of this first: letting sites inside the same runtime model use shared content, ownership and authorization semantics. Content, authorship, permission decisions and interaction records do not have to be invented as mutually incompatible private objects every time. That is still not a cross-site connectivity layer. Displaying, notifying or writing across sites still requires an upper layer to implement discovery, mapping, delivery and authorization explicitly.
You can call this shared structure, but not automatic connection. A shared format is not shared trust, and having the same kind of DID or runtime does not mean any site may read another site's data or speak on someone's behalf. Cross-site visibility, write access, moderation and notification are still decided by explicit rules. What the system does is reduce the repeated translation two ends need to understand each other. It does not remove the boundary.
Why native interoperability is worth something
Picture two independent sites backed by the same set of system capabilities. Someone writes a response on their own notes site and cites an article on the other. Where an explicit bridge exists, compatible content references, caller identity and permission semantics let the original site stop treating that response as unexplainable foreign text. It can decide clearly about source, ownership, target and permitted actions. The author also does not have to move their article into the other side's comment database for the sake of one interaction.
This is not a scenario that must depend on a blockchain, and it does not say every interaction should be recorded as an immutable public event. Plenty of conversation belongs locally, inside one organisation, or under a retention period a particular community decides. ARC's goal is to give those choices a consistent technical entrance: keep verifiable authorship and an audit trail where they are wanted, and do not impose a public ledger on an ordinary comment where they are not.
The benefit of shared semantics is not only social either. Once sites share the basic boundaries of publishing, content, identity and actions, topic pages, citations, related content, navigation on and off site, subscriptions and collaborative workflows become easier to compose. The same limit still applies: this says their upper-layer products are easier to build, not that ARC provides cross-site discovery, feeds, a notification network or community products today. Those products need their own abuse governance, ranking, delivery and privacy decisions.
A native experience cannot require the world to change runtime
If sites with shared semantics can only talk to sites with shared semantics, it eventually repeats the part of the web's history least worth repeating, where every new convenience becomes a reason to join a closed platform. So ARC has to keep the other path open at the same time: going from its own system semantics out to public web protocols.
Webmention is a small but instructive example. A responder publishes at their own URL, then notifies the original URL. The receiver verifies that the source really points at the target, then decides whether to display it. The value of that pattern is not that it has solved comments, identity or spam. It is that it preserves a simple principle: a conversation can happen across different publishing spaces, and the original author still gets to moderate and present.
ActivityPub addresses a different level. It defines Actors, inboxes and outboxes for federated activity, and how activities such as Create, Update, Delete, Follow, Like, Announce and Undo travel between servers, with reply relationships usually expressed by an object's inReplyTo. It does not prescribe a unified comment interface, a recommendation algorithm or a moderation regime, so it should not be described as switching on a decentralised social network. Real interoperability still needs discovery, delivery, verification, abuse handling, synchronisation and local product rules.
ARC has not implemented outward compatibility with Webmention or ActivityPub. Writing them down as design directions is precisely how to avoid a more common mistake, which is treating a conveniently internal interaction model as the destination. Native ARC sites should get a lower composition cost. Sites not on ARC should still be able to form a limited, explicit, verifiable relationship with them at a suitable protocol layer.
Being open does not remove the need for product judgement
Open protocols are sometimes described as a cost that disappears by itself. But a Webmention receiver anyone can actually use has to handle the endpoint, link verification, storage, edits and deletions, anti-abuse, moderation and presentation. An ActivityPub service anyone can actually use has to handle more discovery, delivery failures, identity and content verification, request verification mechanisms, remote policy and community governance. ActivityPub itself does not mandate a single signature scheme. Protocols make boundaries negotiable. They do not make product judgements on anyone's behalf.
So ARC's goal is not to invent a universal social layer. More precisely, it provides a system foundation that can carry publishing, identity, authorization, records and actions, so upper-layer products do not start from blank every time, while respecting existing web standards and each site's autonomy on the outside. One site can publish static content only. Another can turn on attributed comments. A third can grow into a full discussion community. They should not have to become the same product before they can express a relationship the other can understand.
That brings the whole series back to where it started. The web's history is not a straight line from files to applications and then from one framework to its replacement. It has kept looking for a balance between direct publishing, programmability, interaction, operational cost and open connection. ARC's Web Device is one concrete answer inside that history: redefine publishing as a first-class runtime capability, leave live interfaces and unusual business logic to more suitable runtime paths, and let native cooperation and open protocols develop in parallel.
If that path holds up, an ordinary person does not have to become a full-stack developer or a platform's tenant before owning a web space that can both publish and respond. A professional team does not have to give up complex applications to stop rebuilding the shared foundation. That is not returning the web to its past. It is doing the promise most worth keeping once more, with the system capabilities we have now.