Related to the ForumWG topic of resolvable context collections, there are four FEPs that are currently in consideration:

  1. FEP-7888: Demystifying the context property
  2. FEP-400e: Publicly-appendable ActivityPub collections
  3. Draft FEP-171b: Conversation Containers, an evolution of Conversation Containers
  4. FEP-76ea: Conversation Threads

@[email protected] made a suggestion last month to hopefully reduce the number of moving parts:

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

This takes FEP 400e out of the running (potentially). But the day after that last meeting, @[email protected] put together FEP 76ea, and now we’re back to three.

My concern is that all three FEPs (7888, 171b, and 76ea) all share these distinct qualities:

  • They establish a conversational context for a given object
  • They federate out an Add on collection addition. (76ea also sends Remove)
  • They contain some concept of a context owner (attributedTo)

They differ on the following qualities:

  • 7888/171b use context whereas 76ea uses a new property thr:thread
  • 171b specifies a new object type Context
  • Collection items:
    • 7888 sends objects in chronological order
    • 171b sends activities in chronological order
    • 76ea sends objects in reverse chronological order

In the lead up to the November WG meeting I’d like to address those differences. All three FEPs are in pre-draft or draft stages, and so I am hoping we can find some common ground and compromise.

Pinging interested parties (who were not already mentioned above) for comment:

@[email protected] @[email protected] @[email protected] @[email protected]

  • Scott M. Stolz@authorship.studio
    1·
    10 days ago

    Reposting here, since the conversation got sidetracked onto Mastodon.

    @infinite love ⴳ

    Most contexts are multi-faceted in this way. #[1](https://w3id.org/fep/7888#the-different-types-of-context-and-how-they-are-actually-the-same)

    Yes they are. But, as I said, there are practical reasons for wanting to retrieve the conversation container (forum thread, social media thread, chat thread, etc.) as opposed to the reply tree.

    The biggest practical reason is delegation of moderation. In order to limit spam, trolls, and off-topic discussions, the owner(s) of the conversation container (thread) will moderate content by removing it from the conversation container, moving it to another conversation container, or flagging it in some way.

    If @julian spots a spam post on NodeBB, he can delete it. And if I retrieve the conversation container (thread) that NodeBB places the posts in, I will get the moderated version of the thread without the spam. If I parse the reply tree, I get the spam even though Julian deleted it.

    It also helps keep conversations together when the forum moderator moves a post to a different thread. If you follow the reply tree, the post would appear in the wrong thread.

    If you want threaded discussions to behave like threaded discussions over ActivityPub, you need to provide additional information that allows that to happen.

    cc: @Evan Prodromou

    1. https://w3id.org/fep/7888#the-different-types-of-context-and-how-they-are-actually-the-same ↩︎