scott

Something like this:

{  "@context": "https://www.w3.org/ns/activitystreams",  "thr": "https://purl.archive.org/socialweb/thread#",  "thread": {    "@id": "thr:thread",    "@type": "@id"  },  "root": {    "@id": "thr:root",    "@type": "@id"  }  "traits": {    "traits": "inbox, outbox, conversation, amendable"  }}

This would let me know that it is a thread and that people can follow the context. I can then render it as a thread and potentially add a follow or subscribe button for the context.

You could also declare that it does not have an inbox and outbox, which saves me the trouble of checking myself.

@julian

If, for example, someone were to see my context and say "I'd like to map this context's objects out into a word cloud and do sentiment analysis on it", I think that's a perfectly cromulent use of the data. For me to say "this here is a thread, and you better treat it as a thread" is contrary to the spirit of ActivityPub and fedidevs in general.

Simply declaring a collection to be a thread does not force people to display it as a thread. But it does provide valuable information to people who do want to display it as a thread.

So you are not removing people's choice by simply stating that on your platform, this is considered a thread.

@julian The sad thing about this is that we have an opportunity to set the standard here, and we are not taking that opportunity.

Yes, we have to assume that not all platforms will add the additional fields, and we have to have a fallback way of processing incoming posts.

I am just flabbergasted that "thread": "https://remote.example/thread/117", is too hard to include with posts distributed by the forum. Even if you don't use it, some of us might find that to be useful information.

But it appears that I am alone in this, so I will just let it be.

@julian If that is how you want to do it, I respect that. But I do find it odd that the FEP actually has a field for thread and nobody plans on using it. But, most platforms either have 1 context or 0 contexts, so it makes sense.

I still haven't decided how I will do things with my fediverse-enabled project management system. At some point, there will probably be multiple contexts. If that is the case, I probably will put the thread as the first context and then also declare what the thread is using FEP 76ea or something similar.

That way, at least with my project, you won't have to guess which one is the thread. And since your platform only has one context, then I won't have to guess either.

@julian The sticking point is basically whether I should guess what the thread is, or be told what the thread is.

He wants me to perform a bunch of tests and guess; I want it to be declared.

I am not sure what you are going to do when there are multiple collections associated with a post. Because unless the thread is declared, you won't know which is which.

Reposting here, since the conversation got sidetracked onto Mastodon.

@infinite love ⴳ

Most contexts are multi-faceted in this way. #^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

To give you an example:

Here is a thread (conversation with a topic):

#^https://community.nodebb.org/topic/18364/fep-convergence-400e-7888-171b-conversation-containers-76ea

Here is a collection (a list of posts labelled "Forums and Threaded Discussions Task Force"):

#^https://community.nodebb.org/category/31/forums-and-threaded-discussions-task-force

Notice how they are rendered completely different.

A collection is NOT a thread. And some apps need to know which is the thread so we can render the display properly.

@Kichae Ideally, people should be notified that they are posting to a forum and not replying to a post on an individual channel, that way we can set some expectations in advance.

I am not sure how ActivityPub handles it, but Hubzilla somehow communicates with other Hubzilla instances that a particular channel is a forum. It's probably communicated in webfinger, or something like that.

Just having an icon, tag, or Bootstrap-style badge next to a channel saying "forum" would be helpful.

It would be nice if Direct Messages (DMs) or Private Messages (PMs) were treated like email and only sent to the people you are sending it to.

But generally, on most platforms, if you mention someone in the top level post, they are assumed to be on the recipient list. (Note, some platforms, like Mastodon, treat every post as if it were a top level post.)

Hubzilla has more privacy features, which prevents your messages from leaking to others, but part of that is because we use the Zot protocol between Hubzilla instances, and can set privacy at the thread level (i.e. the permissions of the top level post is the permissions for the entire thread).

When the same conversation is sent via ActivityPub, we lose a lot of control over the privacy of that post. We can and do address it to specific recipients, but other platforms don't have the same types of access controls, which means we can't enforce the access control list for that conversation on those platforms.

For reference, Hubzilla renders both the same way.

If you "share" someone's post (what Mastodon users call a "quote post") is basically just:

@[email protected] [quote]Whatever they said.[/quote]

which gets translated to:

@[email protected]<blockquote>Whatever they said.</blockquote>

If someone quotes someone's post in a forum, it is the same exact thing.

And users can also add their own blockquotes to posts by using the BBCode [quote] tags too.

It's all blockquotes.

Note: This posts uses <code> blocks. This may not render properly on all platforms.

Having a separate thread property may be useful. One possible use case would be where threads or posts are labelled or categorized or placed in a list, and this is exposed as a context.

In that case, the thread and the context would be different.

cc: @Evan Prodromou @Sean Tilley @julian @Darius Kazemi

I totally understand the issue with the number of hours in the day. I have a lot of projects going too.

I am working on creating an ecosystem of websites that all use Magic Signon (OpenWebAuth). Social media websites, forum communities, productivity apps, online courses, etc. You can use the same social identity to log into all of them.

The more projects that support it, the more people will use it.

A forum project like yours would make a great addition. :-)