# ActivityPub Actors and Followers

## Source Type

Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
federated social actors, inboxes, and follower relationships.

## Domain

Federated social graphs, actor identity, following/followers, and server-side
account representation.

## Why This Source Matters

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

- **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

| 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

- **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

- 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

- **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

| 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

- 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

- 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