MightyNetwork::Doc::ActivityPub::Actor
Federated object, linked or not to a user.
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.
You should refresh the informations you have in your database about remote actors from time to time (say every 48 hours).
MightyNetwork::Doc, MightyNetwork::Doc::ActivityPub, MightyNetwork::Doc::WebFinger