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

a

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

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.

julian

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.

Mike P

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

a

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

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.