Context deletion vs. Removal brainstorming
Technical Discussion
30
Posts
3
Posters
5
Views
-
@julian yes, this is how followers-only posts in mastodon work. they address your followers collection, which gets expanded to all items in the followers collection.
trwnh@mastodon.social I am going to argue technical details here — when Mastodon sends a followers-only post, they are addressing the followers collection but they aren't parsing it to retrieve targets. They already know them internally and build the targets separately.
I still know of no known implementation that sends an activity addressing a collection, and resolves that collection to find the actor ids.
-
@julian you could, and arguably you should/must, but "no one currently does this" is not the same as "no one will ever do this". consider the case of a public collection.example, and you author an activity to:[collection.example] which you HTTP POST to outbox.example... the specified behavior is that outbox.example fetches collection.example with your credentials and discovers inbox on any items[*]. there is undefined behavior when collection.example has an inbox.
-
@julian mastodon doesn't resolve anything directly over HTTP but they do the equivalent internally with an SQL query. the case where a Collection has an inbox is unhandled because mastodon ignores anything that isn't Person/Group/Organization/Application/Service. mastodon i think also disallows addressing collections that aren't your own followers collection (potentially overzealous spam protection?)
-
@julian mastodon doesn't resolve anything directly over HTTP but they do the equivalent internally with an SQL query. the case where a Collection has an inbox is unhandled because mastodon ignores anything that isn't Person/Group/Organization/Application/Service. mastodon i think also disallows addressing collections that aren't your own followers collection (potentially overzealous spam protection?)
@julian in "technical terms" the reason no one has to worry about this issue is because no one implements activitypub, and when they deliver, they generally disallow delivering to any collections except your own followers collection.
imagine addressing someone else's followers collection, or your own following collection, or a group's members collection, or a public collection. those are all possible in activitypub and would behave according to the specified delivery algorithm for any AP outbox
-
@julian in "technical terms" the reason no one has to worry about this issue is because no one implements activitypub, and when they deliver, they generally disallow delivering to any collections except your own followers collection.
imagine addressing someone else's followers collection, or your own following collection, or a group's members collection, or a public collection. those are all possible in activitypub and would behave according to the specified delivery algorithm for any AP outbox
@julian i mean, if i sent nodebb an activity addressed to collection.example right now, what would you do with it? mastodon would use that as a signal to upgrade any "direct" or "followers" post to a "limited" post. this was implemented as part of their early support for "circles", which i think are so far only a thing on fedibird and bonfire maybe? i'm not sure how audience would be inherited in further interactions but mastodon would probably default to followers-only as overridden by API
-
@julian in "technical terms" the reason no one has to worry about this issue is because no one implements activitypub, and when they deliver, they generally disallow delivering to any collections except your own followers collection.
imagine addressing someone else's followers collection, or your own following collection, or a group's members collection, or a public collection. those are all possible in activitypub and would behave according to the specified delivery algorithm for any AP outbox
trwnh@mastodon.social but that's exactly it, nobody does it.
That's perhaps not a compelling reason to remove it from the spec, but if it's already on the chopping block then I don't feel as strongly about sticking to that part of it.
-
@julian i mean, if i sent nodebb an activity addressed to collection.example right now, what would you do with it? mastodon would use that as a signal to upgrade any "direct" or "followers" post to a "limited" post. this was implemented as part of their early support for "circles", which i think are so far only a thing on fedibird and bonfire maybe? i'm not sure how audience would be inherited in further interactions but mastodon would probably default to followers-only as overridden by API
trwnh@mastodon.social I can't speak for how Mastodon would handle it, but if an arbitrary collection were addressed, I don't see why it would change visibility of the object.
Public and unlisted are containing as:Public in to and cc respectively. Followers-only is sender's follower collection addressed, and otherwise it's mentioned-only post.
Would Mastodon try to resolve the collection for actors? Good question. If it did it would likely resolve it, see that it isn't an Actor, and give up. However I'm venturing into conjecture now.
-
@julian in theory there shouldn't be anything wrong with saying a Collection is also something else, but activitypub's delivery algorithm will have unintended consequences if you address a Collection that has its own inbox
also Remove is defined with respect to object+target, not object+origin. yes, this is somewhat confusing because in english we remove "from" rather than remove "to", but that's far from the only slip-up. (currently AS2 also defines you Invite an Event to a Person...)
trwnh@mastodon.social said in Context deletion vs. Removal brainstorming:
> also Remove is defined with respect to object+target, not object+origin.That's fine, I'll make the corresponding change.
I was basing it off this line in the AS spec:
> If specified, the
originindicates the context from which theobjectis being removed. [[source](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-remove)] -
@julian if "no one POSTs to outbox" is an argument for axing the outbox, then i don't know what we'd be discussing, because what would be left? i mean, maybe we can say "addressing collections no longer expands delivery to items", but then we presumably need an alternative that doesn't involve addressing actors one-by-one.
-
@julian that's pretty much exactly what happens iirc, except instead of "it isn't an actor", the check mastodon does is "it isn't a Person/Group/Organization/Application/Service".
multityping [OrderedCollection, Service] as you propose would cause mastodon to try to process it as an actor, but likely fail when it doesn't pass the webfinger assertion and therefore can't be converted to an Account entity.
-
@julian yes, this is an area where AP actually contradicts AS2 for no good reason. semantically it should be origin, but the side effects of AP are defined wrt target.
-
@julian that's pretty much exactly what happens iirc, except instead of "it isn't an actor", the check mastodon does is "it isn't a Person/Group/Organization/Application/Service".
multityping [OrderedCollection, Service] as you propose would cause mastodon to try to process it as an actor, but likely fail when it doesn't pass the webfinger assertion and therefore can't be converted to an Account entity.
@julian mastodon has a level between "followers-only" and "mentioned-only", which represents exactly this case -- "limited". this means that there are addressees who are not are not accounts, and who are not your followers. to mastodon, these are basically "unknown recipients", and it records the fact that they were addressed but not who they are (its database model doesn't support this)
but activitypub only has actors and collections (while overlooking that the same thing might be both)
-
it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
What limitation?
The problem is not that ActivityPub has a limitation, the problem is that it doesn't have enough. It can't be used to build a real application because it doesn't specify what is valid and what is not. it doesn't even specify what an "actor" is.
Fortunately, the answers to these questions were found and documented in FEP-fe34 and FEP-2277. Object observers are likely compatible with both FEP-fe34 and FEP-2277. Other ideas are not compatible.
In your proposed structure (feel free to correct if wrong), a resolvable context would declare an
observerproperty pointing to an Actor, who would be federating actions out on its behalf.Yes. I think some property can also be added to posts to simplify discovery e.g.
Note.contextObserver.However, it has the same technical hurdle — lack of existing implementation — than the alternative, which is to multi-type the collection into
["OrderedCollection", "Service"]or similar.So
["OrderedCollection", "Service"]is supposed to be an actor that is also a dynamic container? That doesn't make any sense, and I don't know how to implement that in C2S setting. It also conflicts with FEP-fe34 and FEP-2277. -
it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
What limitation?
The problem is not that ActivityPub has a limitation, the problem is that it doesn't have enough. It can't be used to build a real application because it doesn't specify what is valid and what is not. it doesn't even specify what an "actor" is.
Fortunately, the answers to these questions were found and documented in FEP-fe34 and FEP-2277. Object observers are likely compatible with both FEP-fe34 and FEP-2277. Other ideas are not compatible.
In your proposed structure (feel free to correct if wrong), a resolvable context would declare an
observerproperty pointing to an Actor, who would be federating actions out on its behalf.Yes. I think some property can also be added to posts to simplify discovery e.g.
Note.contextObserver.However, it has the same technical hurdle — lack of existing implementation — than the alternative, which is to multi-type the collection into
["OrderedCollection", "Service"]or similar.So
["OrderedCollection", "Service"]is supposed to be an actor that is also a dynamic container? That doesn't make any sense, and I don't know how to implement that in C2S setting. It also conflicts with FEP-fe34 and FEP-2277.If I used an object observer for a topic/context, and proceeded to delete that context, the object observer would go away too.
That is, unless you're inferring that I take steps to preserve the object observer for some period of time (if not forever?)
Gli ultimi otto messaggi ricevuti dalla Federazione
-
If I used an object observer for a topic/context, and proceeded to delete that context, the object observer would go away too.
That is, unless you're inferring that I take steps to preserve the object observer for some period of time (if not forever?)
-
Dagnabbit. Here's a comment from 11 years ago on this topic!
https://github.com/w3c/activitystreams/issues/20#issuecomment-58034202
-
it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
What limitation?
The problem is not that ActivityPub has a limitation, the problem is that it doesn't have enough. It can't be used to build a real application because it doesn't specify what is valid and what is not. it doesn't even specify what an "actor" is.
Fortunately, the answers to these questions were found and documented in FEP-fe34 and FEP-2277. Object observers are likely compatible with both FEP-fe34 and FEP-2277. Other ideas are not compatible.
In your proposed structure (feel free to correct if wrong), a resolvable context would declare an observer property pointing to an Actor, who would be federating actions out on its behalf.
Yes. I think some property can also be added to posts to simplify discovery e.g. Note.contextObserver.
However, it has the same technical hurdle — lack of existing implementation — than the alternative, which is to multi-type the collection into ["OrderedCollection", "Service"] or similar.
So ["OrderedCollection", "Service"] is supposed to be an actor that is also a dynamic container? That doesn't make any sense, and I don't know how to implement that in C2S setting. It also conflicts with FEP-fe34 and FEP-2277.
-
@julian mastodon has a level between "followers-only" and "mentioned-only", which represents exactly this case -- "limited". this means that there are addressees who are not are not accounts, and who are not your followers. to mastodon, these are basically "unknown recipients", and it records the fact that they were addressed but not who they are (its database model doesn't support this)
but activitypub only has actors and collections (while overlooking that the same thing might be both)
-
@julian yes, this is an area where AP actually contradicts AS2 for no good reason. semantically it should be origin, but the side effects of AP are defined wrt target.
-
@julian that's pretty much exactly what happens iirc, except instead of "it isn't an actor", the check mastodon does is "it isn't a Person/Group/Organization/Application/Service".
multityping [OrderedCollection, Service] as you propose would cause mastodon to try to process it as an actor, but likely fail when it doesn't pass the webfinger assertion and therefore can't be converted to an Account entity.
-
@julian if "no one POSTs to outbox" is an argument for axing the outbox, then i don't know what we'd be discussing, because what would be left? i mean, maybe we can say "addressing collections no longer expands delivery to items", but then we presumably need an alternative that doesn't involve addressing actors one-by-one.
-
trwnh@mastodon.social said in Context deletion vs. Removal brainstorming:
> also Remove is defined with respect to object+target, not object+origin.That's fine, I'll make the corresponding change.
I was basing it off this line in the AS spec:
> If specified, the origin indicates the context from which the object is being removed. [[source](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-remove)]
