What does it mean that "an ActivityPub service will expose a set of Actors"?
Uncategorized
14
Posts
7
Posters
0
Views
-
Floppy:
The idea is to arrive at a simple statement, with reasoning, that all platforms can agree to. But of course, before that, to discuss whether or not it’s a good idea
I think it is a good idea, but first we need to figure out what is an actor. I saw a link to FEP-2277 in the markdown document source, but it doesn't seem to be used anywhere... What are your thoughts?
Another thing to consider is how follow-ability is defined. If actor doesn't have a
followersproperty, is it followable? Perhaps it is an actor hosted on a static site, that publishes activities via itsoutbox, but can't push activities to other inboxes?silverpill:Another thing to consider is how follow-ability is defined. If actor doesn’t have a
followersproperty, is it followable? Perhaps it is an actor hosted on a static site, that publishes activities via itsoutbox, but can’t push activities to other inboxes?This is a good point, I hadn\'t thought of unfollowable Actors; I was thinking of the followability being a core Actor thing. Perhaps I should put back in the FEP-2277 reference to defining what is and isn't an Actor.
-
Floppy:
In the interactions I’ve thought about here, the objects are implicitly actors, but being able to be sure of that would be useful.
Does Manyfold have a "search" feature which lets you look up an ActivityPub object by its URL?It is quite useful for interacting with remote content. For example I can click on ActivityPub icon near any comment in this thread, copy URL and load it through my home instance, and respond from there.
When we retrieve object by its URL (or ID), we get it without context. Is it an actor, or a post? This is where duck typing becomes really handy.
-
Floppy:
In the interactions I’ve thought about here, the objects are implicitly actors, but being able to be sure of that would be useful.
Does Manyfold have a "search" feature which lets you look up an ActivityPub object by its URL?It is quite useful for interacting with remote content. For example I can click on ActivityPub icon near any comment in this thread, copy URL and load it through my home instance, and respond from there.
When we retrieve object by its URL (or ID), we get it without context. Is it an actor, or a post? This is where duck typing becomes really handy.
-
What does it mean that "an ActivityPub service will expose a set of Actors"? Assuming a 1:many relationship between services and actors doesn't really make sense with the way the C2S spec is written, which assumes that many services may interface with the same actor.
The book series would be semantically represented as an
OrderedCollection, rather than aGroup.See https://github.com/w3c/activitypub/issues/486 on the feasibility of using OrderedCollection as an actor type—tl;dr is that delivery to OrderedCollections is special-cased by the spec (to support collections of actors e.g. the
followerscollection) and therefore it isn't possible to deliver to the Collection itself. Instead, I don't think representing a book series as an OrderedCollection is the best way to go about it (especially since a book series isn't a collection of Activities!)The fact that both of your motivating examples in the Motivation section are not possible even if this FEP is adopted does not provide a lot of confidence that this FEP is based on implementation experience for generic platforms. Which platforms are implementing this FEP already? Does Manyfold allow you to follow any actor type? I see in the documentation that it's currently using a separate property,
f3di:concreteTypeto determine how to deserialize an actor:(And note that this is just a single controller, so likely similar case statements are cargo-culted into other controllers handling Actor URLs as well). So currently not even Manyfold's code would allow any type of actor to be handled. How does Manyfold propose that other services allow any type of actor to be handled if they can't even do it themselves? Practically, how are implementors meant to determine which ActivityPub documents are actors and which ones are not? Just by using the
inboxproperty?Instead, I think it would be a much more reasonable proposal to handle Actor type extensions in the same way we handle Object extensions, by multi-typing them as explained by ActivtyStreams Core and demonstrated in Example 8:
When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type. For instance, some vocabularies (e.g. The Good Relations Vocabulary) define their own types for describing locations. An implementation that wishes, for example, to use a http://purl.org/goodrelations/v1#Location as an object type MUST also identify the object as being a Place as illustrated in the following:
Example 8
{ "@context": [ "https://www.w3.org/ns/activitystreams", { "gr": "http://purl.org/goodrelations/v1#" } ], "type": ["Place", "gr:Location"], "name": "Sally's Restaurant", "longitude": 12.34, "latitude": 56.78, "gr:category": "restaurants/french_restaurants"}An example of this for Manyfold would be the following:
{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:Creator"], "name": "Stanford University Computer Graphics Laboratory", ....}{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:3DModel"], "name": "Stanford Bunny", ....}(I tried to give this example with a real Manyfold actor document, but I got the error "You need to sign in or sign up before continuing." when trying to request one from try.manyfold.app. As you can imagine, this is pretty hostile to developers trying to test interoperability. However, I do note in the source code that the CreatorSerializor uses the un-namespaced "Creator" URI, which does not seem to be defined in the
@contextdocument)However, this proposal still requires the unnecessary duplication of core Actor types (what is the difference between a
Personand aCreator?)—the amount of extension types should be minimal so as to only cover the use-cases not already covered by the Activity Vocabulary. What is the goal of having two different "user" types?------
Finally, a meta note: overall, the FEP process is not a good way to achieve a consensus based decision-making process, because it operates on the principle of "publish everything", with no editorial or consensus oversight.
The only thing an FEP can say is "This is how my project does X". Since there is no opportunity for other implementors to weigh in and no editors to achieve harmony between implementation, you often end up with a large plurality of conflicting FEPs that each claim to achieve the same thing in different ways. So it's inappropriate for this FEP to claim itself as a statement "that all platforms can agree to", since the FEP process is not designed to resolve conflicts or gather requirements from a wide cross-section of implementors. So even if I thought this FEP was a good idea, I would still object to it on process grounds, because it tries to use the FEP process as a means of forcing the Mastodon project to do something, which is a fundamental misunderstanding of how FEPs work.
nightpool:The only thing an FEP can say is “This is how my project does X”.
Not at all. There is wide variety of FEPs, some of them describe existing practices, some of them are used to achieve consensus regarding new features, yet others are simply informational.
Please don't make misleading claims. If you don't know what FEP process is, you can read about it in FEP-a4ed: The Fediverse Enhancement Proposal Process.
-
nightpool:
The only thing an FEP can say is “This is how my project does X”.
Not at all. There is wide variety of FEPs, some of them describe existing practices, some of them are used to achieve consensus regarding new features, yet others are simply informational.
Please don't make misleading claims. If you don't know what FEP process is, you can read about it in FEP-a4ed: The Fediverse Enhancement Proposal Process.
silverpill:Not at all. There is wide variety of FEPs, some of them describe existing practices, some of them are used to achieve consensus regarding new features, yet others are simply informational.
My point is not that some FEPs may or may not say these things—I'm saying that is the only thing the current process is able to guarantee. Any guarantees beyond "This is how my project does X" requires a different process then the current FEP process.
In fact, the fact that the current FEP process has such loose requirements (anything is accepted with no editorial oversight) makes it very easy for FEPs to make such "misleading claims" to consensus like you seem to dislike.
-
Floppy:
Fair. I was just trying to head off the “wait does this force me to allow blocked actors” question
Perhaps more clearly, this isn't so much that they can be
followablebut rather that services should not hardcode a list of accepted actor types, and instead code for the behavior of an actor. If an Actor has afollowerscollection, then it could be consideredfollowable, but that wouldn't change whether you can webfinger that actor and get back something that behaves like an Actor.Perhaps to stem any moderation concerns, you can just note:
As long as moderation policies allow for interaction and discovery of the given actor.
-
I'd perhaps reword to change "any unblocked Actor" to just "any Actor" as moderation is an overlay on top of who you can interact with. Also, that language leads to weird things: can you
Undo(Block(Actor))on a currently blocked Actor?A decision on what to send where could use the compatibility detection proposed in FEP-9fde in future.
This isn't the right referenced FEP, since that's almost entirely about client interoperability (i.e., so microblogging platforms can announce in a standard way what features they support), despite the section on activitypub that's been awkwardly added in.
There is certainly room for a FEP that supports for instance, sending across additional data with
Followactivities (e.g., we can handle Note, Article, Image, Video; or send me only posts where the content language indicates Japanese because I don't know English so don't need that data). That is, just not who you're following but also what you want to be following. -
nightpool:
delivery to OrderedCollections is special-cased by the spec (to support collections of actors e.g. the
followerscollection) and therefore it isn’t possible to deliver to the Collection itselfit's possible to deliver to the Collection itself but impossible to deliver only to the Collection itself. the delivery algorithm as specified will attempt delivery to both the collection and its items, with no way to address only one or the other.
nightpool:I don’t think representing a book series as an OrderedCollection is the best way to go about it (especially since a book series isn’t a collection of Activities!)
not sure why a collection would have to contain Activities, but at present i am inclined to agree that Collection is a poor representation for anything other than a literal set, like a JSON-LD array
nightpool:[]. there's a lot of things that don't particularly make sense about the underlying model of Collections but the workaround would be to instead reify some class of entity that has a Collection associated with it, rather than saying it is the Collection. So for example in the social media use case, one might say that aConversationexists and hasposts, such thatConversation.postsis an OrderedCollection ordered in forward chronological order or whatever. In the case of Manyfold's "book series", it might make more sense to define aBookSeriestype and then define a separate property that references some Collection -- say something likeBookSeries.books.Practically, how are implementors meant to determine which ActivityPub documents are actors and which ones are not? Just by using the
inboxproperty?i think it's gotta be contextual based on what you're trying to do. for example before sending a Follow you probably need an
inboxand you probably want to check for the presence of afollowerscollection. i don't think the term "actor" really means anything special here, but given that this FEP asserts that "All Actor types should be followable", it seems fair to assume that there is at least some focus on sending Follow activities? in which case i would say thatfollowersis a strong indicator this might work, and the inbox you should POST that Follow to is either directly specified viainboxor otherwise you might recursively crawl upwards viaattributedTountil you find something with aninbox. but this isn't fully or clearly specified anywhere as is touched upon in "following non-actor objects" in https://socialhub.activitypub.rocks/t/unresolved-issues-surrounding-follow-activities/114basically in other words it's less interesting to ask "what is an actor" and more interesting to ask "what can be followed" and then by extension "how can we follow it". if we say that you can follow anything with
nightpool:followersthen the next question is where to send the Follow; we have two choices, either we stipulate that theinboxmust be directly on that resource or otherwise we stipulate that we are expected to crawl up the ownership chain and that it is possible to Follow things further down the ownership chain. the caveat with the latter option is that we don't have a clear concept of this "ownership chain", it's out-of-spec on how to spawn actors or more precisely "how to create an object that has afollowerscollection and that you canFollow". this is the problem i think we should be trying to solve.An example of [multi-typing] for Manyfold would be the following:
{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:Creator"], "name": "Stanford University Computer Graphics Laboratory", ....}{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:3DModel"], "name": "Stanford Bunny", ....}it might make sense to say that a
nightpool:Creatoris also aPersonbut it doesn't really make sense to say that a3DModelis also aPerson. nor does it particularly make sense to say that a3DModelis aGroup,Organization,Application, orService. the restriction to Person/Group/Organization/Application/Service is an entirely arbitrary one, and i don't think anyone should hard-limitFollowto only working on these 5 types, especially given thatFollow's side effects are defined in terms of thefollowerscollection and not in terms of the mythical "Actor type".the unnecessary duplication of core Actor types (what is the difference between a
Personand aCreator?)what is the difference between an
as:Personand afoaf:Personor avcard:Individual? what aboutas:Organization,foaf:Organization,vcard:Organization,org:Organization? "duplication" is only an issue when two terms mean exactly the same thing. this is of course a more general problem in knowledge modeling (identity equivalence) that is sometimes solved via usingowl:sameAs,owl:equivalentClass,owl:equivalentProperty. but i think even more generally the issue is that the types are being given undue importance. ideally, each type is an interface that is being fulfilled. the notion of saying that something "is a" category or class, does not actually provide much useful information except to say "this thing exists in this categorical set". taking that second example, the claim being made is that "Stanford Bunny is a 3DModel", that "Stanford Bunny is included in the set of all 3DModels." this on its own is not enough information to do anything useful. you would most likely be doing something with a property that a 3DModel might have. so why check the type? why not check for the property instead? you're using the property either way, and the type-check serves only to make your code more fragile and less robust.that last post got a bit long and in-the-weeds so i'm gonna say these are the important tldr bits:
trwnh:
trwnh:it’s less interesting to ask “what is an actor” and more interesting to ask “what can be followed” and then by extension “how can we follow it”. if we say that you can follow anything with
followersthen the next question is where to send the Follow;it’s out-of-spec on how to spawn actors or more precisely “how to create an object that has a
followerscollection and that you canFollow”. this is the problem i think we should be trying to solve.i think @thisismissem has it right here that:
thisismissem:services should not hardcode a list of accepted actor types, and instead code for the behavior of an actor. If an Actor has a
followerscollection, then it could be consideredfollowable -
What does it mean that "an ActivityPub service will expose a set of Actors"? Assuming a 1:many relationship between services and actors doesn't really make sense with the way the C2S spec is written, which assumes that many services may interface with the same actor.
The book series would be semantically represented as an
OrderedCollection, rather than aGroup.See https://github.com/w3c/activitypub/issues/486 on the feasibility of using OrderedCollection as an actor type—tl;dr is that delivery to OrderedCollections is special-cased by the spec (to support collections of actors e.g. the
followerscollection) and therefore it isn't possible to deliver to the Collection itself. Instead, I don't think representing a book series as an OrderedCollection is the best way to go about it (especially since a book series isn't a collection of Activities!)The fact that both of your motivating examples in the Motivation section are not possible even if this FEP is adopted does not provide a lot of confidence that this FEP is based on implementation experience for generic platforms. Which platforms are implementing this FEP already? Does Manyfold allow you to follow any actor type? I see in the documentation that it's currently using a separate property,
f3di:concreteTypeto determine how to deserialize an actor:(And note that this is just a single controller, so likely similar case statements are cargo-culted into other controllers handling Actor URLs as well). So currently not even Manyfold's code would allow any type of actor to be handled. How does Manyfold propose that other services allow any type of actor to be handled if they can't even do it themselves? Practically, how are implementors meant to determine which ActivityPub documents are actors and which ones are not? Just by using the
inboxproperty?Instead, I think it would be a much more reasonable proposal to handle Actor type extensions in the same way we handle Object extensions, by multi-typing them as explained by ActivtyStreams Core and demonstrated in Example 8:
When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type. For instance, some vocabularies (e.g. The Good Relations Vocabulary) define their own types for describing locations. An implementation that wishes, for example, to use a http://purl.org/goodrelations/v1#Location as an object type MUST also identify the object as being a Place as illustrated in the following:
Example 8
{ "@context": [ "https://www.w3.org/ns/activitystreams", { "gr": "http://purl.org/goodrelations/v1#" } ], "type": ["Place", "gr:Location"], "name": "Sally's Restaurant", "longitude": 12.34, "latitude": 56.78, "gr:category": "restaurants/french_restaurants"}An example of this for Manyfold would be the following:
{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:Creator"], "name": "Stanford University Computer Graphics Laboratory", ....}{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:3DModel"], "name": "Stanford Bunny", ....}(I tried to give this example with a real Manyfold actor document, but I got the error "You need to sign in or sign up before continuing." when trying to request one from try.manyfold.app. As you can imagine, this is pretty hostile to developers trying to test interoperability. However, I do note in the source code that the CreatorSerializor uses the un-namespaced "Creator" URI, which does not seem to be defined in the
@contextdocument)However, this proposal still requires the unnecessary duplication of core Actor types (what is the difference between a
Personand aCreator?)—the amount of extension types should be minimal so as to only cover the use-cases not already covered by the Activity Vocabulary. What is the goal of having two different "user" types?------
Finally, a meta note: overall, the FEP process is not a good way to achieve a consensus based decision-making process, because it operates on the principle of "publish everything", with no editorial or consensus oversight.
The only thing an FEP can say is "This is how my project does X". Since there is no opportunity for other implementors to weigh in and no editors to achieve harmony between implementation, you often end up with a large plurality of conflicting FEPs that each claim to achieve the same thing in different ways. So it's inappropriate for this FEP to claim itself as a statement "that all platforms can agree to", since the FEP process is not designed to resolve conflicts or gather requirements from a wide cross-section of implementors. So even if I thought this FEP was a good idea, I would still object to it on process grounds, because it tries to use the FEP process as a means of forcing the Mastodon project to do something, which is a fundamental misunderstanding of how FEPs work.
nightpool:delivery to OrderedCollections is special-cased by the spec (to support collections of actors e.g. the
followerscollection) and therefore it isn’t possible to deliver to the Collection itselfit's possible to deliver to the Collection itself but impossible to deliver only to the Collection itself. the delivery algorithm as specified will attempt delivery to both the collection and its items, with no way to address only one or the other.
nightpool:I don’t think representing a book series as an OrderedCollection is the best way to go about it (especially since a book series isn’t a collection of Activities!)
not sure why a collection would have to contain Activities, but at present i am inclined to agree that Collection is a poor representation for anything other than a literal set, like a JSON-LD array
nightpool:[]. there's a lot of things that don't particularly make sense about the underlying model of Collections but the workaround would be to instead reify some class of entity that has a Collection associated with it, rather than saying it is the Collection. So for example in the social media use case, one might say that aConversationexists and hasposts, such thatConversation.postsis an OrderedCollection ordered in forward chronological order or whatever. In the case of Manyfold's "book series", it might make more sense to define aBookSeriestype and then define a separate property that references some Collection -- say something likeBookSeries.books.Practically, how are implementors meant to determine which ActivityPub documents are actors and which ones are not? Just by using the
inboxproperty?i think it's gotta be contextual based on what you're trying to do. for example before sending a Follow you probably need an
inboxand you probably want to check for the presence of afollowerscollection. i don't think the term "actor" really means anything special here, but given that this FEP asserts that "All Actor types should be followable", it seems fair to assume that there is at least some focus on sending Follow activities? in which case i would say thatfollowersis a strong indicator this might work, and the inbox you should POST that Follow to is either directly specified viainboxor otherwise you might recursively crawl upwards viaattributedTountil you find something with aninbox. but this isn't fully or clearly specified anywhere as is touched upon in "following non-actor objects" in https://socialhub.activitypub.rocks/t/unresolved-issues-surrounding-follow-activities/114basically in other words it's less interesting to ask "what is an actor" and more interesting to ask "what can be followed" and then by extension "how can we follow it". if we say that you can follow anything with
nightpool:followersthen the next question is where to send the Follow; we have two choices, either we stipulate that theinboxmust be directly on that resource or otherwise we stipulate that we are expected to crawl up the ownership chain and that it is possible to Follow things further down the ownership chain. the caveat with the latter option is that we don't have a clear concept of this "ownership chain", it's out-of-spec on how to spawn actors or more precisely "how to create an object that has afollowerscollection and that you canFollow". this is the problem i think we should be trying to solve.An example of [multi-typing] for Manyfold would be the following:
{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:Creator"], "name": "Stanford University Computer Graphics Laboratory", ....}{ "@context": [ "https://www.w3.org/ns/activitystreams", {"f3di": "http://purl.org/f3di/ns#"} ], "type": ["Person", "f3di:3DModel"], "name": "Stanford Bunny", ....}it might make sense to say that a
nightpool:Creatoris also aPersonbut it doesn't really make sense to say that a3DModelis also aPerson. nor does it particularly make sense to say that a3DModelis aGroup,Organization,Application, orService. the restriction to Person/Group/Organization/Application/Service is an entirely arbitrary one, and i don't think anyone should hard-limitFollowto only working on these 5 types, especially given thatFollow's side effects are defined in terms of thefollowerscollection and not in terms of the mythical "Actor type".the unnecessary duplication of core Actor types (what is the difference between a
Personand aCreator?)what is the difference between an
as:Personand afoaf:Personor avcard:Individual? what aboutas:Organization,foaf:Organization,vcard:Organization,org:Organization? "duplication" is only an issue when two terms mean exactly the same thing. this is of course a more general problem in knowledge modeling (identity equivalence) that is sometimes solved via usingowl:sameAs,owl:equivalentClass,owl:equivalentProperty. but i think even more generally the issue is that the types are being given undue importance. ideally, each type is an interface that is being fulfilled. the notion of saying that something "is a" category or class, does not actually provide much useful information except to say "this thing exists in this categorical set". taking that second example, the claim being made is that "Stanford Bunny is a 3DModel", that "Stanford Bunny is included in the set of all 3DModels." this on its own is not enough information to do anything useful. you would most likely be doing something with a property that a 3DModel might have. so why check the type? why not check for the property instead? you're using the property either way, and the type-check serves only to make your code more fragile and less robust. -
After feedback and looking at FEP-2277 some more, there are a few changes I need to make to this, possibly even including the title. I don't want it to say "don't filter on
typefor determining followability", that feels too on-the-nose, but it needs to say something more precise than the current title. Maybe by trying not to call out implementations directly I've just made it too woollyI will perhaps change this to directly delegate the question of "what is an actor" to FEP-2277, and change this to talk about "followable objects" instead?
I guess basically the core of the matter is that "what is the object type" is not a sufficient or useful proxy for "should I let people follow this thing".
Edits will follow, thank you everyone for your thoughts so far, this is exactly what I was hoping for
-
After feedback and looking at FEP-2277 some more, there are a few changes I need to make to this, possibly even including the title. I don't want it to say "don't filter on
typefor determining followability", that feels too on-the-nose, but it needs to say something more precise than the current title. Maybe by trying not to call out implementations directly I've just made it too woollyI will perhaps change this to directly delegate the question of "what is an actor" to FEP-2277, and change this to talk about "followable objects" instead?
I guess basically the core of the matter is that "what is the object type" is not a sufficient or useful proxy for "should I let people follow this thing".
Edits will follow, thank you everyone for your thoughts so far, this is exactly what I was hoping for
Since the publication of this FEP, I should note that FEP-efda might be closer to what you are looking for, James?
I'm trying to read between the lines of your draft, and it sounds like you just want to allow people to follow an OrderedCollection, which I'd also like to see happen. For NodeBB, topics are represented as an OrderedCollection (via 7888, actually)
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Turns out supporting trans rights is a winning issue. Wake up, Democrats! https://www.erininthemorning.com/p/anti-trans-democrats-blown-out-in
-
@evan I agree... that characterization has been a bugaboo of mine.
"User" is a perfectly cromulent word.
-
@esilvia @filobus cosa hanno da lamentarsi venti milioni di italiani astenuti alle elezioni europee?
-
Crosetto e Meloni da Mattarella. Per il Quirinale la crisi nel Golfo “è grave”. L'esecutivo: “Il momento più difficile degli ultimi decenni”... no, è stato il COVID e non c'era un governo di scappati da casa!
-
i cant believe Im PUPPY and NONE of u Fuckers Told Me
-
@Gargron you are chaotic evil! 😬
-
@GustavinoBevilacqua hai bisogno di farti bloccare di nuovo? 8-D
-
@andre123 non capisco la differenza tra nodi in vista e online. Se sono alimentati (accesi) sono visibili o online?
