Complete IDENTITY-WP-0003 corpus backfill and model refinement

Backfill all 23 research source notes with terminology extracts, modeling
assumptions, conflicts, canonical mappings, and references. Refresh terminology
artifacts, refine the conceptual model with explicit scenario paths, reconcile
canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
2026-06-21 20:22:20 +02:00
parent 790a2f2041
commit 1c1b5c9bc6
32 changed files with 2676 additions and 623 deletions

View File

@@ -1,50 +1,114 @@
# Activitypub Actors Followers
# ActivityPub Actors and Followers
## Source Type
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
federated social actors, inboxes, and follower relationships.
## Domain
TODO: Classify the source domain.
Federated social graphs, actor identity, following/followers, and server-side
account representation.
## Why This Source Matters
ActivityPub actors, inboxes, outboxes, followers, following, federation, and social identities.
ActivityPub treats users as server-side actors with inboxes and outboxes. A
person may have several actors across servers, mapping well to contextual
identities and personas.
## Key Concepts
TODO:
- concept 1
- concept 2
- concept 3
- **Actor**: Activity Streams object (Person, Service, Group, Organization,
Application) with `inbox`, `outbox`, `followers`, `following`, `liked`.
- **Person actor**: human-associated actor on a federated server.
- **Service / Application actor**: automated or app-mediated actor.
- **Group actor**: collective actor with shared inbox/outbox.
- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject.
- **Followers / Following collections**: reverse-indexed social graph edges.
- **preferredUsername**: handle local to the origin server.
- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL.
- **SharedInbox**: delivery optimization for addressing multiple actors.
- **Public / followers-only addressing**: audience scoping for activities.
- **WebFinger**: discovery of actor profile from `acct:user@domain`.
## Relevant Terminology
TODO: Extract terms used by the source and note their source-specific meaning.
| Term | Source meaning |
| --- | --- |
| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. |
| Person | Actor type for human-associated accounts. |
| Follow | Directed activity establishing follower relationship. |
| Follower | Actor who follows another actor. |
| preferredUsername | Local handle on origin server. |
| Actor ID | HTTPS URI identifying actor globally. |
| Inbox / Outbox | Message endpoints for receiving/sending activities. |
| Group (actor type) | Collective actor in ActivityPub sense. |
| Service | Non-human automated actor type. |
| acct: URI | Account identifier for WebFinger discovery. |
## Modeling Assumptions
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
- **Actor is the primary social identity unit**, hosted on an origin server.
- **One human may operate multiple actors** across servers (implicit, not
standardized as same-person link).
- **Following is a social subscription**, not membership or authorization.
- **Actor ID is globally unique** within the fediverse namespace.
- **Server is authority** for actor existence and deletion.
- **Groups and Organizations are actor types**, not separate provisioning models.
- **No standardized account linking** across actors for same natural person.
## Identity-Canon Implications
TODO: Explain what this source suggests for the canonical identity model.
- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association
via Account/Profile on origin server).
- **Person actor** implies **Natural Person** operator but actor ≠ person.
- **Service/Application actor** maps to **Artificial Agent**.
- **Group actor** maps to **Community** or **Group** collective actor.
- **Follow** maps to **Following Relationship** (directed, social).
- **preferredUsername** + domain maps to **Identifier** in server **Scope**.
- **Actor ID (URL)** maps to global **Identifier**.
- Multi-server actors per person support S02, S09, S14 without mandatory
synonymity.
- **followers-only** audience maps to Scope/audience boundary on Profile.
## Terminology Conflicts
TODO: Record where this source uses terms differently from other sources.
- **Actor vs. User**: ActivityPub actor is server entity; apps say user.
- **Person vs. Natural Person**: Person is actor type, not verified human.
- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group.
- **Follow vs. Member**: following ≠ community membership unless separately defined.
- **Account vs. Actor**: `acct:` suggests account, but actor is richer object.
## Candidate Canonical Mappings
TODO: Map source-specific concepts to identity-canon candidate concepts.
| ActivityPub concept | Candidate canonical concept |
| --- | --- |
| Actor (Person) | Actor + Profile + Account (on origin server) |
| Actor (Service) | Artificial Agent + Service Account |
| Actor (Group) | Community or Group collective actor |
| Actor (Organization) | Organization collective actor |
| Follow activity | Following Relationship |
| Followers/Following collections | Relationship indexes |
| preferredUsername | Identifier (local handle) |
| Actor ID (URL) | Identifier (global) |
| acct: URI | Identifier |
| Origin server domain | Scope |
| Inbox/Outbox | Operational endpoints (downstream) |
| WebFinger | Discovery protocol (downstream) |
## Open Questions
TODO:
- Question 1
- Question 2
- Should cross-server actors for one Natural Person require explicit Synonymity
Assertion, or remain unlinked by default?
- Does ActivityPub Organization actor type map to Organization or Community
depending on moderation model?
- How should moved-to / moved-from actor migration (if used) map to Identifier
Binding supersession?
- Should followers-only audience be a Profile visibility Scope or separate
Relationship attribute?
## References
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
- W3C ActivityPub — https://www.w3.org/TR/activitypub/
- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/
- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033