How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?

julian

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.

[email protected]

julian:

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

Duck typing can be used to identify activities. I'd prefer a cleaner solution, but not strongly opposed to this idea.

a

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

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.

julian

While discussing what is contained in the context collection, I'd like to clarify what exactly is being Add'ed in 400e and (the upcoming) 171b, and whether that also coincides with the collection items.

That is, if a context collection contains only simple objects, then the assumption is that context owner will only federate an Add out for simple objects. Likewise if the collection contains activities, then I'd expect Add(Like(Note)) to come from that owner.

However, a quick re-reading of 400e suggests that only simply objects are federated out via Add. That would tip the scale a bit toward the context containing only objects.

[email protected]

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

@[email protected] if recommending outbox I'd suggest also calling out the inbox for future use (follow event, in particular).

Pinging @[email protected] for thoughts.

infinite love ⴳ

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

julian

@[email protected] @[email protected] thread would just be simple objects, and context would be the activity stream, no?

Wondering whether this addresses concerns between 7888 and 76ea (@[email protected])

infinite love ⴳ

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

Evan Prodromou

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

infinite love ⴳ

@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

infinite love ⴳ

@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

infinite love ⴳ

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

infinite love ⴳ

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

julian

@[email protected] happy to publish on fedi but it doesn't necessarily have to take place within the confines of ForumWG, the group just has an interest in the outcome

@[email protected]

silverpill

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

infinite love ⴳ

@[email protected] @julian @[email protected] 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

infinite love ⴳ

@[email protected] @julian @[email protected] which is to say: collecting the activities is generally useless for fedi. except/unless the activities are contentful objects, in which case they become “posts”.