Good morning Fediverse.
-
Good morning Fediverse.
Just the gentle reminder. We still don't know what an Actor is in the context of ActivityPub. See e.g. FEP-2277 for a possible definition.
On a side note, this doesn't cover an important use case of the actor used to fetch public keys (it needs neither to have an inbox nor an outbox).
Finally, one should not conflate an actor with the entities that use the actor. It would be completely reasonable for this entity to want to want to move followers from one account to another (or following).
-
Good morning Fediverse.
Just the gentle reminder. We still don't know what an Actor is in the context of ActivityPub. See e.g. FEP-2277 for a possible definition.
On a side note, this doesn't cover an important use case of the actor used to fetch public keys (it needs neither to have an inbox nor an outbox).
Finally, one should not conflate an actor with the entities that use the actor. It would be completely reasonable for this entity to want to want to move followers from one account to another (or following).
>On a side note, this doesn't cover an important use case of the actor used to fetch public keys (it needs neither to have an inbox nor an outbox).
Do you mean the instance actor?
I have an answer to this conundrum in FEP-fe34. The key used to sign GET requests doesn't have to be attached to an actor. It can be an independent object withoutownerproperty. -
>On a side note, this doesn't cover an important use case of the actor used to fetch public keys (it needs neither to have an inbox nor an outbox).
Do you mean the instance actor?
I have an answer to this conundrum in FEP-fe34. The key used to sign GET requests doesn't have to be attached to an actor. It can be an independent object withoutownerproperty.Do you mean the instance actor?
Yes.
Regarding your solution. It approaches somewhat where I would expect a specification to end up at: There are 3 types of actors in the Fediverse: Receiving (handles HTTP Posts), Sending (have a public key to sign messages; perform HTTP Posts and Gets), and hosting data (answer HTTP Gets).
Unfortunately, a lot of details crop up when thinking things through, and the above naive solution quickly runs into problems.
-
R [email protected] shared this topic
-
Do you mean the instance actor?
Yes.
Regarding your solution. It approaches somewhat where I would expect a specification to end up at: There are 3 types of actors in the Fediverse: Receiving (handles HTTP Posts), Sending (have a public key to sign messages; perform HTTP Posts and Gets), and hosting data (answer HTTP Gets).
Unfortunately, a lot of details crop up when thinking things through, and the above naive solution quickly runs into problems.
@helge I think there is only one type of actor, and it is a JSON document with
inboxandoutboxproperties. Requests are sent and received by servers, not actors.In the server-centric model of Fediverse everything is simple and clear, I wrote about this previously. Whereas in the actor-centric model, even the most basic things can not be explained without adding epicycles.
-
@helge I think there is only one type of actor, and it is a JSON document with
inboxandoutboxproperties. Requests are sent and received by servers, not actors.In the server-centric model of Fediverse everything is simple and clear, I wrote about this previously. Whereas in the actor-centric model, even the most basic things can not be explained without adding epicycles.
>actor ... is a JSON document with inbox and outbox properties
Thinking more about this...
I would prefer to define actor as "an entity that produces activities". The property indicating this capability isoutbox.
