How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?
from angus@socialhub.activitypub.rocks to swicg-threadiverse-wg@community.nodebb.org on 18 Apr 2024 11:22
https://socialhub.activitypub.rocks/ap/object/d6d57ebe611ff9c77c15f3f272cc0046

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 https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md

Discourse

Currently Discourse implements FEP-1b12 to federate posts associated with Category and Tags, i.e. Activities are Announced by a Category or Tag actor.

NodeBB

NodeBB implements FEP-1b12 to federate posts associated with a category (tag actors TBD).

Lemmy

Lemmy implements FEP-1b12

[Add your implementation in here]

#swicg-threadiverse-wg

threaded - newest

grishka@socialhub.activitypub.rocks on 04 Jun 2024 13:23 next collapse

Oh hi. I'm not very active on this forum lately but I received an email about this topic, only now.

My main idea with FEP-400e was to avoid posting group posts to one's own profile at all costs. I see Announce-style groups as mostly a crutch for wider compatibility (there are even bots like this one that work on top of the Mastodon API, you mention it and it boosts). As I design things starting from the UX, I couldn't use anything that uses Announce, because that would make my desired UX nearly impossible.

Now for some other implementations "not posting to profile" might not be a concern at all. Lemmy is modeled after Reddit, which does show your posts and comments on your profile front and center. And that's fine. And it's also fine to be incompatible; you can't exactly imagine Mastodon and a phpBB forum interoperating in any meaningful capacity simply because their user experiences are so disparate.

My other idea was that it's not just walls — it's a generic mechanism of creating objects into someone else's collections, while also relinquishing full control over them. My FEP explicitly says that the collection owner can delete someone else's objects contained in the collection. I will soon start working on photo albums. Those will exist in groups too, and the way they will work is that everyone who has access to the group could upload new photos. So again, someone else's collection into which others add things.

angus@socialhub.activitypub.rocks on 04 Jun 2024 13:54 collapse

Great to see you here again!

grishka:

And it’s also fine to be incompatible

True! Albeit, I think the general consensus here is that there isn't an inherent incompatibility between 400e and 1b12. The question is more how an implementor approaches processing a Group actor's activities. @trwnh helpfully lays out the possibilities above

https://socialhub.activitypub.rocks/t/how-do-we-handle-groups-reconciling-fep-400e-and-fep-1b12/4088/19?u=angus

The point of this topic and the spreadsheet I just shared is not to contrast the two standards. It's more of an empirical reference of sorts for implmentors.

grishka:

you can’t exactly imagine Mastodon and a phpBB forum interoperating in any meaningful capacity simply because their user experiences are so disparate.

Well, I might slightly disagree with you there as Discourse, NodeBB and other forum-like implementations in the #activitypub:threadiverse-wg interoperate with Mastodon

silverpill:

Added “Yes (partial)” to FEP-1b12 column.

Thanks!

silverpill:

I intend to fully support both FEP-1b12 and FEP-400e in the future.

I think this is where the Discourse plugin will end up too.

Actually, now that I think of it, the Discourse plugin does partially support 400e as it will recognise a Collection in the target property. However it doesn't process Additions to such a collection, so saying it supports 400e is premature.

julian@community.nodebb.org on 04 Jun 2024 13:55 collapse

Actually, now that I think of it, the Discourse plugin does partially support 400e as it will recognise a Collection in the target property. However it doesn't process Additions to such a collection, so saying it supports 400e is premature.

This is where there is some potential to trailblaze as the other half of the equation might be implementing 7888, aka a resolvable context.

I have a feeling that context and target would work well to point to the same thing.

@angus@socialhub.activitypub.rocks said in How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?:

By-the-by it strikes me that these implementation spreadsheets we're making should be synthesised in some way at some point.

My assumption was that the surveys and spreadsheets would be helpful to guide discussion at WG meetings, but eventually lead to a SocialCG report of non-normative findings, followed by a recommendation for new implementors.

silverpill@socialhub.activitypub.rocks on 22 Sep 2024 06:38 collapse

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.

julian@community.nodebb.org on 30 Sep 2024 19:33 next collapse

@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.

silverpill@socialhub.activitypub.rocks on 30 Sep 2024 23:03 collapse

julian:

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))

trwnh@socialhub.activitypub.rocks on 30 Sep 2024 23:25 collapse

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"

julian@community.nodebb.org on 01 Oct 2024 14:20 next collapse

Okay, so we have some disagreement here with respect to what a context contains. Perhaps my understanding was outdated, but I thought there was some limited discussion about outbox containing the full activity log, and the collection containing the post objects. That would satisfy both sides, if I am not mistaken.

Usually the conversation devolves into "what is an actor, anyway", but let's keep things on track today LOL

silverpill@socialhub.activitypub.rocks on 01 Oct 2024 15:43 collapse

trwnh:

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.

trwnh@socialhub.activitypub.rocks on 01 Oct 2024 15:53 collapse

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.)

julian@community.nodebb.org on 01 Oct 2024 16:01 collapse

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. 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.

julian@community.nodebb.org on 01 Oct 2024 16:04 next collapse

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.

FenTiger@mastodon.social on 01 Oct 2024 16:16 collapse

@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.

trwnh@socialhub.activitypub.rocks on 01 Oct 2024 16:24 collapse

julian:

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.

You'd be missing activities regardless. If someone sends a Create Note with a context to the context manager, and I'm following the context and receive this activity, I might send a Like to the author of the Note but NOT to the context manager. In that case, the only way to obtain a complete view of the likes collection for that Note is to ask its authoritative origin. This is going to be something that happens a lot due to the messiness of fediverse implementations -- you might have 3 Likes be delivered directly to the context manager, but 7 other Likes be delivered only to the author of the liked post. If you are only processing the context collection, then does the post in question have 3 likes, or 10?

julian@community.nodebb.org on 01 Oct 2024 16:34 collapse

It's probably not going to be what some people want to hear, but some degree of lossiness is unavoidable.

All we can do is apply our best effort and set forward a straightforward recommendation that other implementors can consume and implement with minimal variance.

That's why I eschew esoteric and complex implementations when a simpler mechanic would suffice.

trwnh@socialhub.activitypub.rocks on 01 Oct 2024 16:42 collapse

julian:

some degree of lossiness is unavoidable.

some degree of subjectivity is also unavoidable. this is why i was talking about the additional signals/types above, so that you can tell if a collection contains "posts" or if it also contains some additional "non-posts". i don't think everyone is going to agree 100% one way or the other on what exactly makes up a "conversation".

julian@community.nodebb.org on 01 Oct 2024 17:03 collapse

I'll informally poll at the WG meeting Thursday for opinions. Results are of course non-binding.

I'm afraid that not only are we not going to agree, even if one option is recommended by decree, there will be implementors who refuse to adopt.

It seems evenly split right now.

silverpill@socialhub.activitypub.rocks on 23 Nov 15:57 collapse

FEP-171b (Conversation Containers) has been published (discussion thread: https://socialhub.activitypub.rocks/t/fep-171b-conversation-containers/4766).

I don't like some implementation details, but overall it is a good solution, and, most importantly, it is very similar to FEP-1b12. So we can just implement FEP-1b12 and figure out the rest later.

One collection is not enough to cover all use cases, but I think collection of posts should be provided by all applications. Personally I prefer the following collections names (although I don't have a strong opinion here):

  • thread: collection of posts (recommended)
  • context: collection of conversation activities such as Create, Update and Like (optional)
  • outbox: collection of Announce / Add activities (optional).
julian@community.nodebb.org on 23 Nov 16:09 collapse

@silverpill@socialhub.activitypub.rocks if recommending outbox I'd suggest also calling out the inbox for future use (follow event, in particular).

Pinging @trwnh@mastodon.social for thoughts.

trwnh@mastodon.social on 23 Nov 16:16 collapse

@julian @silverpill what makes something a "conversation activity" or a "post", and how are these different?

to me, a "post" is "whatever you intend for the user to see". generally this is anything that has content (or summary or name), but you can also support "contentless activities" if the semantics are clear enough. for best practices though, i'd recommend the switch-case be "presence of name/summary/content".

i don't see a reason to single out Create/Update/Like for context.

trwnh@mastodon.social on 23 Nov 16:22 next collapse

@julian @silverpill the main example here is a thread/context (same thing to me) of the following "posts":

- Article.content = "blah"
- Note.content = "foo"
- Note.content = "bar"
- Move.summary = "6 posts were moved to a different thread"
- Like.content = "i really like blah and thank you for publishing it"
- Announce.content = "blah makes a really good case and everyone should read it"

in the HTML version of the web page it renders exactly the same information as the LD.

julian@community.nodebb.org on 23 Nov 16:21 next collapse

@trwnh@mastodon.social @silverpill@socialhub.activitypub.rocks thread would just be simple objects, and context would be the activity stream, no?

Wondering whether this addresses concerns between 7888 and 76ea (@evan@cosocial.ca)

evan@cosocial.ca on 23 Nov 16:28 next collapse

@julian @silverpill I think using `thread` as a serialized version of the the reply tree is a nice first step. If people want other aspects of a conversation, as @trwnh mentioned, maybe using `context` is good, or maybe using another term.

@trwnh can we set up a time to talk through next steps 1:1? It'd be nice to consider what to do here.

trwnh@mastodon.social on 23 Nov 16:29 collapse

@evan @julian @silverpill yeah i was about to suggest a call or something as well — i’m free basically whenever, so i defer to whatever your most convenient timeslot would be

trwnh@mastodon.social on 23 Nov 16:50 collapse

@evan I guess also if @julian wants to drop in and listen or give live feedback, then that's also fine?

trwnh@mastodon.social on 23 Nov 16:50 collapse

@evan @julian Could also be a Special Topic Call for the Forum TF but that feels like too much formalism

trwnh@mastodon.social on 23 Nov 16:42 collapse

@julian @silverpill @evan I don't think the distinction matters between "simple objects" and "activity stream", but if it did, then it would be nice for the context collection owner to signal ahead-of-time their criteria for adding.

On the sending side, what matters is whether you put `context` on the activity or not. The exact same consideration applies to any other property, including putting `inReplyTo` or `published` or `to` or even `content` on the Activity instead of on the .object

silverpill@mitra.social on 24 Nov 16:08 collapse

@trwnh @julian @silverpill Conversation activity is any activity that conversation owner thinks is related to the conversation, and wants to distribute to other participants. In (micro)-blogging applications that would be Create/Update/Delete, sometimes Like, EmojiReact and Announce too (if one wants to synchronize reactions and boost counts). But in other applications these activities might be different, for example video sharing app may include View activities, and audio sharing app may include Listen activities.

trwnh@mastodon.social on 24 Nov 16:17 collapse

@silverpill@mitra.social @julian @silverpill@socialhub.activitypub.rocks this sounds more like the kind of thing that should be discussed at a protocol level for whichever protocol is distributing such activities or objects. for activitypub that usually means inbox forwarding of as:Activity, or fetching the as:outbox. for fedi which doesn’t enforce a strict requirement that everything be an as:Activity, we generally focus on final/current state of contentful objects (“posts”) as resources

trwnh@mastodon.social on 24 Nov 16:21 collapse

@silverpill@mitra.social @julian @silverpill@socialhub.activitypub.rocks which is to say: collecting the activities is generally useless for fedi.