This is a topic to track the FEP-400e and FEP-1b12 reconciliation, aka "How do we handle Groups". I've made this a wiki to let implementers describe their current status quo

fep/fep/1b12/fep-1b12.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

fep/fep/400e/fep-400e.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

Implementations

Use of Group actors

Google Docs (docs.google.com)

See also

https://socialhub.activitypub.rocks/t/developers-meeting-2-groups/2302https://socialhub.activitypub.rocks/t/how-to-use-groups/1005https://socialhub.activitypub.rocks/t/groups-implementation/591https://socialhub.activitypub.rocks/t/lets-discuss-groups/519https://socialhub.activitypub.rocks/t/standardizing-on-activitypub-groups/1984

I think in order to reconcile FEP-400e and FEP-1b12 the following changes can be made:

• Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)
• FEP-400e implementations: upgrade to Conversation Containers
• FEP-1b12 implementations: add target property to Announce activity that points to context collection.

Activity types will still be different (Add vs Announce), but consuming implementations can easily accept both.

@silverpill@socialhub.activitypub.rocks Unless I'm reading this wrong, you're advocating that we should:

1. Reduce the number of moving parts to 2 (400e bows out in favour of 171b)
2. Encourage broader adoption of a resolvable context property (this would be the one differentiator that can be used as feature detection)
3. Implementations should accept both Add and Announce activities as valid for appending to a resolvable context collection.

Let me know if I have that right, I'd like to discuss this at the upcoming ForumWG meeting Thursday.

Unless I'm reading this wrong, you're advocating that we should:

Yes, that's correct. I believe it is also important to make context a collection of activities, because reactions are part of a conversation too (I didn't fully realize that until I added support for FEP-1b12 Announce(Like) and Announce(Dislike))

disagree that context should contain likes and dislikes. i think those should go in collections like likes or an extension-defined dislikes.

but also, context is agnostic to what it contains. this is why i was thinking of maybe defining new types to signal that the collection should contain "posts" (objects that have content) only, or if it can contain other non-"post" objects like Like/Announce/etc activities.

the main mechanism for deciding what goes in a context collection is more or less "whatever declares that context and gets delivered to / added by the authority"

disagree that context should contain likes and dislikes. i think those should go in collections like likes or an extension-defined dislikes.

So servers will need to make additional requests for every object in a context collection when backfilling a thread? This is quite inefficient.

The goal is 0 additional requests because every activity in collection is signed.

it's only inefficient if you care about like/dislike/share counts. i am fundamentally disagreeing that those activities should be considered part of a conversation. it adds nothing to the conversation to just tell everyone "i like this" with zero additional input to the conversation. now, if you wanted to clarify and say "i like this because ..." then maybe you actually are contributing to the conversation. you'd do that by putting content on your Like, which turns it into a "post". (posts dont have to be Notes or Articles. activities can be considered "posts" if they have content.)

From an implementor point of view, I will say that if I receive a context and it contains the entire activity history, I will simply retrieve everything and normalize it down to the items that I do care about.

For example, a collection containing:

Create(Note), Like(Note), Announce(Note), EmojiReact(Note), Create(Note)

would be collapsed down to

Note, Like, Announce, (ignored), Note

Whereas a collection containing just the objects would not need collapsing (it'd just be Note, Note). Either way, it containing the entire history does not impede my ability to parse it.

Sure, I'd miss some of the activities around it, so that's a concern, but it's not a dealbreaker. That's why I'm on the fence about this one.

My personal opinion is that this could be a non-issue. If the verbiage on the FEP were amended so that it says:

The collection MAY contain complete activities (this includes Create, Update, Delete, Like, EmojiReact and other activities) OR simple objects.

I would have no problem with this, but I do not know if this is a problem for others.

@julian I'd lean towards activities, because it's a lot easier to remove data you don't care about, than to reinvent data that you do care about but never received.