MightyNetwork :: Doc :: ActivityPub :: Actor (source, CPAN)

#NAME

MightyNetwork::Doc::ActivityPub::Actor

#DESCRIPTION

Federated object, linked or not to a user.

#JSON-LD REPRESENTATION

This is what you get when requesting an actor from a WebFinger search.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Person",
    "id": "https://example.org/users/narf",
    "preferredUsername": "narf",
    "name": "narf",
    "following": "https://example.org/users/narf/following",
    "followers": "https://example.org/users/narf/followers",
    "inbox": "https://example.org/users/narf/inbox",
    "outbox": "https://example.org/users/narf/outbox",
    "endpoints": {
        "sharedInbox": "https://example.org/shared/inbox"
    },
    "publicKey": {
      "id": "https://example.org/users/narf#main-key",
      "owner": "https://example.org/users/narf",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n[…]\n-----END PUBLIC KEY-----\n"
    }
}

As this object is federated, it needs a type and an id.

In ActivityPub specification, if the instance is https://example.org, and the name of the actor is narf, its id can be:

https://example.org/users/narf
https://example.org/@narf
https://example.org/@/narf
etc

The choice should be coherent for all the actor objects of the instance. Although, you can choose to give a random id to each actor.

The actor needs to present inbox and outbox keys which path depends on the id.

It’s better if the followers and following keys are provided. Their path depends on the id too.

Other keys are optionals.

#REFRESHING REMOTE ACTORS’ INFORMATIONS

You should refresh the informations you have in your database about remote actors from time to time (say every 48 hours).

CONTENTS

#NAME

#DESCRIPTION

#JSON-LD REPRESENTATION

#REFRESHING REMOTE ACTORS’ INFORMATIONS

#SEE ALSO