Is DCP based on Activity Streams?

No. DCP was not derived from or built on top of Activity Streams 2.0. The two happen to share a similar shape, an actor-like field, a verb, and an object or entity, because that shape is a natural, independently-discovered way to describe an event. DCP is plain JSON Schema, not JSON-LD, and its entity and rel vocabularies are purpose-built for software-project coordination.

Could Activity Streams be used for project coordination?

You could technically place project-related data inside Activity Streams objects, but you would lose the closed, validatable, coordination-specific vocabulary DCP provides. Activity Streams has no Decision, Finding, ArchitectureImpact, Milestone, or Dependency type, and no design principle equivalent to DCP carries no trust, so you would either overload social-web verbs or extend the vocabulary ad hoc and lose interoperability.

Are DCP and Activity Streams competitors?

No. They serve disjoint domains, social-graph activity versus software-project state, so adoption of one does not come at the expense of the other. Activity Streams is best understood as a structural precedent that validates the actor-verb-object approach DCP also uses, not as a rival vocabulary.

DCP vs. Activity Streams 2.0

W3C Activity Streams 2.0 is a JSON-LD vocabulary, a W3C Recommendation since 2017-05-23, for describing social-web activities with an actor, a type, an object, and an optional target (Like, Follow, Create a post). DCP shares that grammar loosely, an attributed-to actor, a verb, and an entity, but applies it to a different domain entirely: software-project coordination, not social networking.

Same grammar, different language

Look at the shapes side by side and the resemblance is real. Activity Streams’ core model is actor / type / object / target. DCP’s Event is attributed_to / verb / entity_type + entity (plus optional refs for relationships). Both are ways of saying “someone did something to something.” That resemblance is not a coincidence of naming, it is evidence that actor-verb-object is a robust, independently-rediscovered pattern for describing what happened. Activity Streams reached W3C Recommendation status doing it for the social web. DCP reaches for the same shape doing it for project coordination.

But the resemblance stops at the grammar. Activity Streams’ extended vocabulary defines roughly 40 social-domain types, Person, Like, Follow, Create, Add, and so on, aimed at feed readers and social networking applications, and it underpins the ActivityPub/Fediverse ecosystem. It has no notion of a Decision, a Finding, an ArchitectureImpact, a Milestone, or a Dependency, because none of those concepts exist in its target domain. DCP’s closed set of 8 entities exists precisely to name the things Activity Streams was never asked to name.

Comparison

	DCP	Activity Streams 2.0
Domain	Software-project coordination between agents and humans	Social web: activities, feeds, social graphs
Shape	`Event`: entity_type + verb + entity_id, plus optional entity/delta/refs	actor + type + object + optional target
Core vocabulary	8 closed entities: Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone	~40+ Object/Activity subtypes: Person, Application, Organization, Create, Like, Add, Follow, and more
JSON-LD?	No — plain JSON Schema (2020-12), no `@context`/linked-data semantics	Yes — JSON-LD by design, part of the Linked Data ecosystem
Standards status	Independent open spec, Apache-2.0 code and schemas, CC-BY-4.0 docs; 8 entities, 14 JSON Schemas, 70 passing tests, 25 conformance cases, as of 2026-07-03	W3C Recommendation, approved 2017-05-23 — the highest W3C maturity tier, stable and no longer actively evolving
Trust model	None by design — “DCP carries no trust”; a message is untrusted data with no built-in identity or authorization	No equivalent design principle stated; actor identity is typically handled by the surrounding application (e.g., ActivityPub)
Relationship to DCP	—	Structural precedent, not a competitor — validates the actor-verb-object approach; disjoint domain means no adoption rivalry

Why not just use Activity Streams for coordination?

You could, technically, shoehorn project-coordination data into Activity Streams objects: a Create activity for a new task, a custom extension type standing in for a decision. Activity Streams’ own vocabulary spec explicitly allows introducing new Object types beyond the defined set, so nothing stops you from trying.

But doing so gives up exactly the guarantees DCP was built to provide. Activity Streams’ extension mechanism is open-ended by design, which is right for a social-web vocabulary meant to grow organically, but wrong for a coordination protocol that needs a closed, validatable set of entity types so that any two independent implementations agree on what a “Decision” or a “Finding” looks like without first negotiating a private extension. DCP’s 8 entities and its closed 8-term rel vocabulary (relates_to, part_of, references, caused_by, derived_from, supersedes, concerns, blocks) exist so that field names and relationship types are guaranteed, not conventions someone might have skipped. Activity Streams also carries no equivalent of DCP’s prime directive, that a message “carries no trust” and describes project-state changes only, so bolting coordination semantics onto it would also mean inventing a trust posture from scratch. In short: you would lose interoperability guarantees to gain a JSON-LD context you don’t need for this domain.

Reading Activity Streams as validation, not competition

The honest framing is that Activity Streams 2.0 is a mature, well-designed, W3C-ratified standard doing an excellent job in its own domain, and DCP does not compete with it because the two vocabularies were never trying to name the same things. If anything, Activity Streams’ decade of production use inside the Fediverse is a point in favor of the actor-verb-object pattern DCP also relies on: a structurally similar approach has already scaled to a real, multi-implementation ecosystem. For the reasoning behind why project coordination needed its own vocabulary rather than reusing an adjacent one, see why a coordination vocabulary is a distinct layer. For the full list of DCP’s closed entity types, see the entity reference; for how DCP’s verb tokens stay open while entity types stay closed, see the verb reference. DCP’s refusal to carry identity or authority is covered in provenance, not identity. For comparisons against other adjacent specs, browse the comparison hub.

By InterIP Networks · Last updated 2026-07-01.