@silverpill yes, I was thinking of the nomadic identity aspect when I said that.
-
@silverpill yes, I was thinking of the nomadic identity aspect when I said that.
So, for GoAP: a user wants to upload an image, it can specify recipients, the client builds an Image AP object out of that (including a reply collection) and wraps it in a Create collection, sends it to the server (C2S).
Server saves Image locally, creates all collections for the Image that are not empty in the Image (like replies, likes, shares, etc) adds it to outbox of user's Actor, adds it to local follower's Inbox or sends it to remote followers Inbox (S2S). If it's in reply to something(s) loads the object(s) and disseminates it to the recipients.
-
@silverpill yes, I was thinking of the nomadic identity aspect when I said that.
So, for GoAP: a user wants to upload an image, it can specify recipients, the client builds an Image AP object out of that (including a reply collection) and wraps it in a Create collection, sends it to the server (C2S).
Server saves Image locally, creates all collections for the Image that are not empty in the Image (like replies, likes, shares, etc) adds it to outbox of user's Actor, adds it to local follower's Inbox or sends it to remote followers Inbox (S2S). If it's in reply to something(s) loads the object(s) and disseminates it to the recipients.
@mariusor Could you tell me more about how
repliesand similar properties are treated by GoAP servers?I initially imagined that clients would put collection ID there, but regular ActivityPub clients (not FEP-ae97) are not supposed to mint identifiers.
So I decided to remove this from my Collections FEP and recommend explicit creation instead (via
Createactivity).One possible solution is to introduce a special value (such as
null), that tells server that it should create a collection:{ "type": "Note", "replies": null }cc @trwnh
-
@mariusor Could you tell me more about how
repliesand similar properties are treated by GoAP servers?I initially imagined that clients would put collection ID there, but regular ActivityPub clients (not FEP-ae97) are not supposed to mint identifiers.
So I decided to remove this from my Collections FEP and recommend explicit creation instead (via
Createactivity).One possible solution is to introduce a special value (such as
null), that tells server that it should create a collection:{ "type": "Note", "replies": null }cc @trwnh
@silverpill the Go ActivityPub state machine creates all collections that appear as properties in an object. So if the client has filled the replies collection with an IRI that is namespaced to the instance (or better yet, the user), it creates that an OrderedCollection using that as an ID.
So for your example, there would not be a replies created.
However the servers built with GoActivityPub have no universal rule about clients not being able to generate IDs. When they receive an object with ID they try to create it, if it fails, it fails, if it succeeds... cool. This helps with allowing users to have nice URLs for their content.
-
@silverpill the Go ActivityPub state machine creates all collections that appear as properties in an object. So if the client has filled the replies collection with an IRI that is namespaced to the instance (or better yet, the user), it creates that an OrderedCollection using that as an ID.
So for your example, there would not be a replies created.
However the servers built with GoActivityPub have no universal rule about clients not being able to generate IDs. When they receive an object with ID they try to create it, if it fails, it fails, if it succeeds... cool. This helps with allowing users to have nice URLs for their content.
@silverpill basically I did it like this because I wanted to short-circuit clients having to send Create activities that create the collections at the same time.
I can think of a flow where you create all collections that you want the actor/object to have, then you create the actor/object by setting those collections' ids in the right places, but it feels a little unwholesome.
With the automatic creation, I can also set ownership on the collections to the actor that created them, or the actor that they belong to.
In GoAP this relies a lot on URL paths having meaning and not being opaque blobs as the specs say, which might not be for everyone...
-
@mariusor Could you tell me more about how
repliesand similar properties are treated by GoAP servers?I initially imagined that clients would put collection ID there, but regular ActivityPub clients (not FEP-ae97) are not supposed to mint identifiers.
So I decided to remove this from my Collections FEP and recommend explicit creation instead (via
Createactivity).One possible solution is to introduce a special value (such as
null), that tells server that it should create a collection:{ "type": "Note", "replies": null }cc @trwnh
@silverpill PS. did I miss where the spec forbids clients passing IDs to the Create objects, or am I right that it could be a valid mechanism?
-
@silverpill PS. did I miss where the spec forbids clients passing IDs to the Create objects, or am I right that it could be a valid mechanism?
@mariusor In the section
6. Client to Server Interactionsit says "If an Activity is submitted with a value in the id property, servers MUST ignore this and generate a new id for the Activity." ActivityPub sometimes uses "activities" and "objects" interchangeably, it even allows POSTing objects directly without wrapping them inCreate, so this "MUST" may apply to objects too.I think this means that a client can pass an
id, it is just not guaranteed to be respected by a server.AFAIK there is nothing in the spec that forbids clients to provide an ID in
repliesand similar properties. -
@mariusor In the section
6. Client to Server Interactionsit says "If an Activity is submitted with a value in the id property, servers MUST ignore this and generate a new id for the Activity." ActivityPub sometimes uses "activities" and "objects" interchangeably, it even allows POSTing objects directly without wrapping them inCreate, so this "MUST" may apply to objects too.I think this means that a client can pass an
id, it is just not guaranteed to be respected by a server.AFAIK there is nothing in the spec that forbids clients to provide an ID in
repliesand similar properties.@silverpill @mariusor @trwnh I don't think the MUST applies to objects.
-
@silverpill @mariusor @trwnh I don't think the MUST applies to objects.
@evan probably that should be clarified. Should I open a ticket somewhere?
-
@evan probably that should be clarified. Should I open a ticket somewhere?
-
@evan @mariusor @silverpill although note that i think nightpool is of the opinion that POSTing a non-activity to the outbox is an at-risk behavior and should be deprecated, because the "implicit Create" behavior has to somehow know whether or not the body of the POST is an Activity or not, and we never actually define how to know this, so it is too likely that the server will accidentally wrap activities in a Create if some inference fails.
-
@evan @mariusor @silverpill although note that i think nightpool is of the opinion that POSTing a non-activity to the outbox is an at-risk behavior and should be deprecated, because the "implicit Create" behavior has to somehow know whether or not the body of the POST is an Activity or not, and we never actually define how to know this, so it is too likely that the server will accidentally wrap activities in a Create if some inference fails.
@evan @mariusor @silverpill re: ids though the RDF ecosystem (and jsonld) doesn't use "null", it uses blank node identifiers (those prefixed with _: are special cased by the prefix expansion algorithm). this can allow for "transient" activities or "anonymous" objects (and the graph data model auto assigns _:b1, _:b2 and so on when "id" is missing; the canonicalization algorithm assigns _:c14n0 and _:c14n1 and so on)
this is maybe not the best way to create replies collections though...
-
@evan @mariusor @silverpill re: ids though the RDF ecosystem (and jsonld) doesn't use "null", it uses blank node identifiers (those prefixed with _: are special cased by the prefix expansion algorithm). this can allow for "transient" activities or "anonymous" objects (and the graph data model auto assigns _:b1, _:b2 and so on when "id" is missing; the canonicalization algorithm assigns _:c14n0 and _:c14n1 and so on)
this is maybe not the best way to create replies collections though...
@evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login