Context deletion vs. Removal brainstorming
Technical Discussion
30
Posts
3
Posters
76
Views
-
I think
contextproperty should point to a collection (a dynamic view), but we can introduce a newDelete-able object that is linked to that collection. It could be an actor: https://codeberg.org/fediverse/fep/src/branch/main/fep/f06f/fep-f06f.mdYou also mentioned
Remove, how it should look in practice?Removefrom whattarget?At least from the point of view of NodeBB, when a topic is deleted, the Collection is de facto gone. That's why it's problematic to federate out a delete because nobody else can resolve it to find their "version" of your context.
-
However specifically in response to your suggestion to use an Object Observer, I am not entirely sold on the concept because it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
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. 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.> You also mentioned
Remove, how it should look in practice?Removefrom whattarget?No target, but
origin. The collection is removed from the audience, so the audience is set inorigin. -
Obligatory mentions to trwnh@mastodon.social and helge@mymath.rocks because I called out multi-typing, which is a whole other conversation in and of itself.
-
@julian activitypub has no concept of replies either. neither `inReplyTo`/`replies` nor `context` were specced for activitypub. these are more generally terms from the activitystreams vocabulary, and they have no side effects defined or associated with them
-
@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...)
-
@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...)
@julian for what it's worth, this is what i was trying to head off in the past several months of discussion, with regards to as:context *being* an as:Collection, as opposed to *having* an associated as:Collection. it's why i wrote https://w3id.org/fep/2931 to extend from https://w3id.org/fep/7888
changing the activitypub delivery algorithm would probably end up needing new properties: one that delivers directly (deliverToActor) and one that delivers to expanded items (deliverToCollection)
-
@julian for what it's worth, this is what i was trying to head off in the past several months of discussion, with regards to as:context *being* an as:Collection, as opposed to *having* an associated as:Collection. it's why i wrote https://w3id.org/fep/2931 to extend from https://w3id.org/fep/7888
changing the activitypub delivery algorithm would probably end up needing new properties: one that delivers directly (deliverToActor) and one that delivers to expanded items (deliverToCollection)
@julian prior art: Web Access Control differentiates subjects who are being granted authorization to access a certain resource. they have separate properties
- agent = every value is a foaf:Agent, and access is granted directly to each entity
- agentGroup = every value is a foaf:Group, and access is granted indirectly to each foaf:member
- agentClass = every value is a rdfs:Class, and access is granted according to vocabthe classes are Agent (as:Public) and AuthenticatedAgent (logged in only)
-
@julian prior art: Web Access Control differentiates subjects who are being granted authorization to access a certain resource. they have separate properties
- agent = every value is a foaf:Agent, and access is granted directly to each entity
- agentGroup = every value is a foaf:Group, and access is granted indirectly to each foaf:member
- agentClass = every value is a rdfs:Class, and access is granted according to vocabthe classes are Agent (as:Public) and AuthenticatedAgent (logged in only)
@julian so we have kind of a problem of data modeling, where we have actors (inbox), collections (items[*].inbox), possibly groups which could either deliver directly (inbox) or indirectly per foaf (member[*].inbox) or double-indirectly via swicg/groups task force's current proposal (members.items[*].inbox)
we could *maybe* avoid this by directly specifying which inboxes to deliver to, a la multibox (https://w3id.org/fep/0499 is one take on this), but it's unclear which if any/all are supported.
-
@julian so we have kind of a problem of data modeling, where we have actors (inbox), collections (items[*].inbox), possibly groups which could either deliver directly (inbox) or indirectly per foaf (member[*].inbox) or double-indirectly via swicg/groups task force's current proposal (members.items[*].inbox)
we could *maybe* avoid this by directly specifying which inboxes to deliver to, a la multibox (https://w3id.org/fep/0499 is one take on this), but it's unclear which if any/all are supported.
@julian hopefully this demonstrates why the distinction between "is a" and "has a" matters a lot. in the group case you would need to distinguish between delivering to a group vs delivering to a group's members. currently there's a lot of ambiguity around this in 1b12 applications.
-
@julian hopefully this demonstrates why the distinction between "is a" and "has a" matters a lot. in the group case you would need to distinguish between delivering to a group vs delivering to a group's members. currently there's a lot of ambiguity around this in 1b12 applications.
trwnh@mastodon.social You're speaking theoretically... that the spec says that if a collection is addressed, then all members in that collection are by definition addressed.
Do you have an example of this in the wild? This has the potential to be a speed bump that is entirely theoretical, and can be ignored in advance of its removal from the AS2 (or AP?) spec(s).
-
trwnh@mastodon.social oh doy... of course it exists in the wild, we address to follower collections all the time.
... but crucially, when you address a follower collection, you don't resolve the follower collection itself, you rely on the follower to forward your activity onwards... so, again, perhaps resolving a collection for addressing isn't actually used in-practice?
-
@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.
-
@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)]
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Okay, I've setup https://notes.socialcg.org/about
-
@julian i'd say the confusion is primarily that we've shifted topic around several different things and i'm still not sure which is the intended topic of the discussion :x
- deleting posts that are in a thread
- removing posts from a thread
- implications for downstream posts in a thread when some ancestor in the reply chain is deleted/removed
- deleting a thread that is in a forum
- removing a thread from a forum
- moving a thread to the "uncategorized" forum
- ...?
-
@julian if the intent is to signal what happens when nodebb moves a thread to "uncategorized", then i think the simplest thing is for nodebb to treat "uncategorized" as a forum in itself, still. you already assign them an id of -1, so you are in effect treating the "uncategorized" category as a category still.
-
@julian the confusing thing to me, though, is that both Delete and Remove already don't imply anything about posts in the thread if the thread is deleted/removed from the forum.
by default, if you Delete a thread, the forum might still have a broken link to the now-deleted thread, and the posts also have broken links to the thread.
by default, if you Remove a thread from the forum, the posts still exist within the thread.
-
trwnh@mastodon.social specifically however, is that you're not deleting the context. Just removing it.
NodeBB has the concept of a context not belonging to an audience (the "uncategorized" pseudo category.) in those specific situations, contexts would be removed from the audience, not deleted.
Lemmy and Piefed don't have these concepts, so they simply delete them. So therein lies some of the confusion I believe.
-
@julian like removing a whole thread from the forum? Remove(object=thread, target=forum)? this seems like something altogether different than removing posts from a thread.
removing threads from a forum is possible but if the thread is owned by the forum then the forum can also delete them.
the part that differs between impls is whether Delete(thing that is a context) should do anything to objects where context = the Delete.object, right? i think it makes the most sense to just orphan them.
-
trwnh@mastodon.social it signals that the actor is removing the context from the targeted audience.
The audience can optionally announce it, and receivers synchronizing with that audience (per 1b12) should follow suit and remove the context as well.
-
@julian what does Remove(Context) mean here?
