Hi there,
if a client stores an “activity” with an “object”, that references “anotherObject”,
should the activity pub implementation then also save “anotherObject” or validate, that “anotherObject” is existend?
Or just store the IRI/URL?
Means:
Is a createActivity limited to one object or is it also for graphs/trees.
Or should there be a create activity for each object of the graph/tree?
activity.object -> someObject ;
someObject.anotherObject -> anotherObject;
Thanks Fredy
Strictly speaking, you aren’t required to store activities at all. You only need to store objects, and whether you traverse the graph, and how do you do that, depends on your intentions. It’s hard to reason about things this abstract with zero concrete use-case examples, and you rarely need to.
For example, if you receive a Create{Note}
that mentions a user on your instance and is in the middle of a reply thread you’ve never seen, you might want to traverse the reply thread to provide the user with some context.
This also depends on your storage. I store everything in an SQL database, so each post is assigned an ID. I can’t store a reply that points to a post that I don’t have because that parent post won’t have an ID in my table, so I won’t be able to represent that relation, so I have to traverse the thread bottom to top and then insert the rows into the table going from top to bottom.
To sum it up: you can store objects in whatever format is convenient to your particular application, the only important part is that you’re able to generate their ActivityPub representations from it. It helps to envision ActivityPub as an API.
1 Like
Hi,
“the only important part is that you’re able to generate their ActivityPub representations from it.”
should this representation contain the graph/tree or just the root object 
I decided to only store the object. And if somebody want to reference “anotherObject” he has to create it first.
Thanks
This depends on what you’re going to be doing with it. You can’t make software in isolation from its intended use cases.