coulomb/identity-canon
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
This repository has been archived on 2026-07-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
b0faa22849b255a89b4e192d507abf15ae3b93ca
identity-canon/research/social-community-graphs/activitypub-actors-followers.md
tegwick 1c1b5c9bc6 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.
2026-06-21 20:22:20 +02:00

5.0 KiB
Raw Blame History

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

Reference in New Issue View Git Blame Copy Permalink