Minutes from 4 December 2025 WG Meeting

[julian@activitypub.space]

Apologies in advance if I misrepresented anybody or missed any crucial bits of information.

---

Attendees

• Julian (@julian@activitypub.space)
• Ted Thibodeau Jr (he/him) (OpenLinkSw.com) // GitHub:@TallTed // Mastodon:@TallTed
• Jesse Karmani (jesseplusplus@mastodon.social)

Agenda

1. Mastodon context issues (backfill not possible at the moment)
2. Context (topic/thread) deletion and moving between audiences (communities/categories)
   • Draft FEP for the above
3. Deleting entire tree vs. one post. with_replies or Remove(Context)?
4. Cross-posting (stalled?)

Mastodon context issues

• Backfill not possible, context remains null
• Claire and David are aware, can this be reproduced locally? @jesseplusplus
• Mastodon keeps track of the conversation, but not what the root-level ID is; Frequency keeps track of the parents. This was new to Mastodon codebase (all internally)
  • Possibly the code shared for this is not working
  • Jesse will take a look (diff b/w Decodon and Mastodon)
  • Ted: in-reply-to tracking is akin to parent tracking
  • Jesse: Not quite; Mastodon now tracks root-level ID (that's the piece that might not be working.)

Mastodon reading context?

• The other (harder) half: FEP f228
• Jesse made David aware of the possibility of using f228 to backfill
• Asked whether this would conflict with existing reply tree crawling — suspect it will not.
• Expected 6–12 months out (or more)
• tl;dr — no update available, but none was expected either.

Context Relocation and Removal

• Pre-Draft FEP
• ActivityPub.Space Discussion
• Genesis of this FEP from needs of ActivityPub.Space. It bridges Microblogiverse and Threadiverse by importing discussions by hashtag (#activitypub among others)
  • Lots of curation needed as people tend to use the #activitypub hashtag when discussing non-AP things
  • Also non-English content, etc. (ActivityPub.Space is English-focused as we have two mods, Julian and another temporary mod from toot.wales/IFTAS)
• Pre-draft shared with Rimu (rimu@piefed.social) and Felix (nutomic@lemmy.ml) for their thoughts, discussion (linked above) started last night for some additional input.
• No opposition to Move(Context) as it is not a functionality that is implemented by anybody at the moment
  • Hooray for greenfield AP dev!

Out-of-band discussion

• Remove(Context) received some pushback from Lemmy. This was expected as both Lemmy and Piefed currently use Delete(Object)
• Felix is recommending that Delete(Object) can supply with_replies property to explicitly denote that the entire reply tree is to be deleted.
• Julian is recommending that Remove(Context) be used to explicitly denote that the reply-tree/container itself is removed, context can be resolved to determine which exact object IDs to delete if needed, Remove also tells you which audience/community it was removed from.
• Rimu OK with either approach.
• Felix raised objection to the wording that Delete(Post) is shown under "backwards compatibility" — Julian will update to reflect equal priority on both approaches.

ForumWG discussion

• Julian admits that it is likely much much easier for Lemmy to update their handling of Delete vs. creating a new handler for Remove.
• Julian notes disconnect with current behaviour (Delete(Object)) and new behaviour (same, but with_replies) and the actual effect (removal from the community); you cannot actually delete someone else's content because it does not satisfy same-origin constraint (yes, sometimes, but not always.)
• Currently at an impasse as to how to proceed, but Julian encourages parties present to contribute to the discussion and review the FEP.
• Would prefer alignment as opposed to supporting both Remove and Delete(Object) w/ replies given that it is unlikely both will be implemented widely.

Action Items

• [ ] Jesse: investigate null context issue; Mastodon
• [ ] Julian: Revise and publish FEP f15d

---

Relevant Mentions

melroy@kbin.melroy.org bentigorlich@gehirneimer.de

[silverpill@mitra.social]

@julian

FEP-f15d: Context Relocation and Removal

I have two objections to this proposal. We discussed them before in Moving topics/contexts between communities:

1. It assumes that a context always belongs to one group.

As I suggested in the aforementioned thread, an Update activity is a better solution because it works when relationship between a context and a group is many-to-many. It is also semantically cleaner: "update collection audience" instead of "move collection from actor 1 to actor 2" and "remove collection from actor" (at least if ActivityStreams terminology is used).

2. Treating collections (dynamic views) as static objects that can be moved, deleted etc is not compatible with client-side signing.

One possible solution is to separate context (an object) and its contents (a collection).

@jesseplusplus @rimu @nutomic @melroy @BentiGorlich

[julian@activitypub.space]

silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting:
> 1. It assumes that a context always belongs to one group.

Yes that's correct. There was the potential for a context to belong to multiple audiences but social issues preclude further research.

Specifically, moderation gets very messy when contexts are cross posted to diametrically opposing audiences, and so that's not something I am equipped to work through right now.

Secondly, the assumption is already there that a context only belongs to one audience. We will not change that expectation.

[julian@activitypub.space]

silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting:
> 2. Treating collections (dynamic views) as static objects that can be moved, deleted etc is not compatible with client-side signing.

You mentioned this before, but I am not sure what you are referring to. Do you mind elaborating?

[silverpill@mitra.social]

>the assumption is already there

Where, in Lemmy? Even if some implementations don't support cross-posting I don't see a reason to block it at the protocol level.

And Update is simpler, that's one activity instead of two (Move and Remove).

[silverpill@mitra.social]

Collections are dynamic objects because they can be paginated and filtered. It's not possible to sign a dynamic object, because some of its properties are constantly changing (items, totalItems and others). This means collections need to be always server-managed. Therefore, clients shouldn't be allowed to directly create, update or delete them.

I think the proposed Move activity is an obfuscated Update because it changes the collection directly.

[julian@activitypub.space]

Sorry it took so long to respond to this —

Re: assumption of a context belonging to one audience
> Where, in Lemmy? Even if some implementations don't support cross-posting I don't see a reason to block it at the protocol level.

This FEP doesn't block cross-posting at the protocol level. Move just explicitly states that a context was Removed from one and Added to another. You could achieve this just fine with Remove followed by Add, but this just reduces it down to a single activity and eliminates any side-effects (e.g. a Remove without corresponding Add might mean content is purged from the db)

So in theory, a context can belong to multiple audiences, and it can be moved from one to another, or removed from one.

[julian@activitypub.space]

@silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting:
> It's not possible to sign a dynamic object, because some of its properties are constantly changing (items, totalItems and others). This means collections need to be always server-managed. Therefore, clients shouldn't be allowed to directly create, update or delete them.

Mmm, signing doesn't guarantee data correctness, it only guarantees that the data presented is correct as of sending, per the sender's point of view.

Just like how signing a Create(Note) only guarantees that the note's data is what it is at the time of the Create, a Move(Context) only guarantees the validity of the context's data at the time of the Move.

That said, this FEP doesn't have you including the entire object in, just the URI, so this is moot........ no?