p3x.deContext deletion vs. Removal brainstorming
julianCurrently I am grappling with the specifics behind how to federate out the deletion of a topic in a category (or in ForumWG terms, the deletion of a context from an audience.)
For those unaware, a context is essentially an OrderedCollection containing all objects within its purview.
Deleting a note or other object is easy. If you are same-origin as the object, you Delete(Object), done.
Deleting a context is more difficult… you can’t rely on other implementors to store references to your contexts, since it is essentially meaningless to them. Furthermore, if a context is deleted, then when a Delete(Context) is federated out, receivers will have no idea what they’re seeing, will try to retrieve the object, and find a 404. So it doesn’t even work at all.
Even worse, you can’t really delete other peoples’ contexts (or for that matter, their content) since you’re not same-origin.
Finally, I realized I’m looking at this the wrong way — I’m not deleting contexts, I’m simply removing them from an audience. Remove works perfectly fine when the context continues to exist (as it can be referenced and duck typed). Remove also works for remote content; the same-origin check applies to the audience you’re removing from.
If you’re deleting a context, you have to be the same-origin, and you really should just federate out deletion of the local members in that collection, via regular Delete(Object).
I suppose federating out self-destruction of a context would be the most complete but it is quite difficult to do when it is no longer resolvable…
@julian I forgot, why do you want to delete a context? If it's your thread, isn't it enough to just
Deletethe top-level post?I’m looking into federating out deletion of contexts because in NodeBB the concept of a topic is a discrete entity, not tied to the posts contained within. Deleting the top-level post would not alter the topic in any way, except perhaps that the next oldest reply is suddenly promoted to top-level, which is odd.
Conversely, in ActivityPub, there either is no concept of a context (threaded objects only), or merely the suggestion of one as a view (current implementations of resolvable contexts). I’m hoping to move this more towards contexts as discrete entities with their own activities.
@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
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.@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 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 w3id.org/fep/2931 to extend from 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)
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.
Yes. I think some property can also be added to posts to simplify discovery e.g.
Note.contextObserver.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 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?)
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.
As I was tagged: Use a custom activity. Also write a FEP for it.
There is a much higher chance of discovering what a ‘FederatedForumDeleteContext` activity does than some of the Delete/Remove/Strange actor types mentioned in this discussion. In particular, if there is a FEP describing it.
Opening https://helge.codeberg.page/fep/ and pasting ‘FederatedForumDeleteContext
into the search field should be the minimum requirement for a Fediverse developer if they discover the 'FederatedForumDeleteContextactivity type.