Skip to content
Universal Manifest

Social/Profile

This page describes an adoption pattern for profile and social surfaces (web profile pages, public identity views, and optional indexing flows).

Social/Profile Integration

Boundary: normative vs non-normative

Section titled “Boundary: normative vs non-normative”
  • Normative contract: Specification and Conformance
  • Non-normative guidance: projection patterns in this page

What you implement (minimum checklist)

Section titled “What you implement (minimum checklist)”

Inputs

Section titled “Inputs”
  • A valid Universal Manifest (um:Manifest)
  • Resolver or direct retrieval path to fetch current manifests
  • Surface policy for privacy/consent enforcement

Outputs

Section titled “Outputs”
  • A deterministic public profile projection
  • Explicit handling for expired/invalid manifests
  • Optional export for indexing/search when consent allows

Minimum behaviors

Section titled “Minimum behaviors”
  • Enforce TTL and reject expired manifests for active use
  • Ignore unknown fields safely
  • Respect consent fields before rendering/indexing
  • Treat implementation-specific conventions as optional extensions

Core idea: Manifest → projection

Section titled “Core idea: Manifest → projection”

Universal Manifest is a portable state capsule, not “the profile page itself”.

Typical flow:

  1. A system receives a manifest (um:Manifest) about a subject.
  2. It verifies (or otherwise trusts) the manifest (TTL rules; signature when available).
  3. It derives a projection appropriate for the surface:
    • a web profile page
    • a public display capsule
    • a social identity view
    • a search/index document (opt-in)

Minimum fields for a profile projection

Section titled “Minimum fields for a profile projection”
  • subject — stable identifier (recommended: DID; allowed: any URI)
  • issuedAt, expiresAt — freshness for use
  • shards — embed or reference profile fragments
  • pointers — canonical source references (website, pod, social actor URL, etc.)
  • consents — whether the profile may be public/indexed/rendered

Schema strategy (avoid inventing the world)

Section titled “Schema strategy (avoid inventing the world)”

For cross-system adoption, prefer embedding standard vocabularies inside shards when helpful:

  • schema:Person for creators (basic public profile fields)
  • schema:Organization / schema:Place for venues

In v0.1, consumers can still interoperate by reading only the fields they understand and ignoring unknowns safely.

ActivityPub pointer (optional)

Section titled “ActivityPub pointer (optional)”

ActivityPub can start as a pointer without forcing every consumer to implement ActivityPub:

  • pointer name: activityPub.actor
  • value: https://example.social/@alice

Privacy & consent

Section titled “Privacy & consent”

Consumers should default to deny for any use not explicitly consented to.

Suggested consent keys (strings):

  • social.profilePublic
  • social.indexing
  • publicDisplay

Reference fixtures

Section titled “Reference fixtures”

Use these fixtures as implementation aids:

These examples are implementation aids and should not be treated as extra conformance requirements.

Next

Section titled “Next”