@Peter Vágner @Dieguito How conversations work is not unified all across the Fediverse. Even how connections work is not unified.

Mastodon has taken over the follower/followed principle from Twitter which is always illustrated with arrows with one point. A following B is illustrated with an arrow from A to B. A being followed by B is illustrated with an arrow from B to A. A and B following each other mutually is illustrated with one arrow from A to B and one arrow from B to A.

It appears to me that Friendica has adopted this to become more compatible with Mastodon. But its several descendants, created by Friendica's own creator, starting with Hubzilla, haven't.

Hubzilla, (streams) and Forte still have the bidirectional "connection" or "contact" as the default. It's illustrated with one arrow, but with one point on each end.

Also, all three understand a threaded conversation as an enclosed contruct entirely owned by the conversation starter. Everyone on these three who has the start post on their stream always actually has the whole thread on their stream.

In fact, all three have Conversation Containers implemented. This feature was originally created in the streams repository in 2022. Forte has had it from the get-go as it started out as a fork of (streams). It was eventually turned into FEP-171b and backported to Hubzilla last year.

All three make sure that everyone who has a post on their stream also always has all comments on that post, at least those that are made after they have received the post.

This works on two basic principles:

• All comments go directly to the original poster because the original poster owns the thread.
• Those who have the post automatically receive all comments from the original poster.

In a pure Hubzilla/(streams)/Forte system, your above example would look like this:

• User 1 and User 2 are connected.
• User 1 and User 3 are connected. (This doesn't even matter.)
• User 2 and User 3 are connected.
• User 2 and User 4 are connected.

Much simpler than explaining everything with "following" and "being followed", isn't it?

Now, the conversation works like this.

• User 2 sends a public post, thus creating a Conversation Container of which they are the owner.
  User 1, User 3 and User 4 receive the post.
• User 3 comments on User 2's post.
  The comment goes from User 3 to User 2, who is the owner of the conversation, and it is automatically forwarded to User 1 and User 4 who already have User 2's post on their streams.
• User 4 comments on User 3's comment.
  The comment goes from User 4 past User 3 straight to User 2, who is the owner of the conversation, and it is automatically forwarded to User 1 and User 3 who already have User 2's post on their streams.

The only mentioning that occurs here, if any, is User 4 mentioning User 3. This is not necessary for User 4's post to reach anyone. This is only necessary to make sure on Hubzilla (which doesn't have a tree view) that User 4 is replying to User 3's comment and not to User 2's post.

On Mastodon, for comparison, everything depends on who follows whom, who mentions whom and whose instance knows whose instance.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations #FEP_171b #ConversationContainers

@Jenniferplusplus I sincerely hope that you aren't building Letterbook to only interact with itself and Mastodon.

Sooner or later, Letterbook will encounter content coming in from instances of software created by @Mike Macgirvin ?️, namely Friendica, Hubzilla (these two are actually older than Mastodon), (streams) or Forte. For reference: I am on Hubzilla.

You/it will have to expect and be able to deal with the following:

• Enclosed one-post-many-comments conversations instead of threads that consist of posts loosely tied together
• Permissions of all comments/replies firmly defined by the start post; permissions/visibility can't be changed within a running conversation
• "Monster posts" of any length because none of them has a character limit
• Not just Note-type objects, but also Article-type objects (from Friendica right now, the others may implement them once Mastodon introduces sensible support for them)
• Full HTML text formatting, up to and including numbered lists, tables, horizontal lines, character size and character colour
• Both quotes (as done in bulletin-board forums) and quote-posts (posts fully embedded in other posts like quote-tweets)
• Embedded links (this comment makes a whole lot of use of them)
• Inline images embedded within the text, and more than four of these in one post
• Inline audio streams embedded within the text
• Inline videos embedded within the text
• "Weird" mentions and hashtags with the @ or the # not part of the link (look at the mentions and the hashtags in this comment, then look at mentions and hashtags on Mastodon and compare them)
• "Summaries in the CW field" (because Mastodon repurposed StatusNet's summary field, which was used by StatusNet, Friendica and Hubzilla as an actual summary field, for content warnings in 2017; several Fediverse server apps continue to use it for summaries)
• All four support titles in addition to summaries

Some of the above may also come in from elsewhere, e.g. a wider range of text formatting than Mastodon allows itself to render is fully supported by just about everything that isn't Mastodon.

Also, ActivityPub is currently evolving. New FEPs are being put to use and bringing in new features far away from how Mastodon is working. In particular, (streams) and Forte and @silverpill's Mitra use decentralised identifiers as per FEP-ef61 (Portable Objects). Forte has nomadic identity fully implemented via ActivityPub while (streams) at least supports it. And all three have conversation containers implemented, silverpill wants to make them an FEP, and Hubzilla is planning to implement them with version 10.

This means three things. One, weird identifiers. Two, weird actor identities: What looks like one user automatically cross-posting to another account on another instance to non-nomadic ActivityPub implementations is actually the very same actor residing simultaneously on multiple server instances. Three, again, conversations work drastically different from Twitter and Mastodon.

Lastly, it may be a good idea to implement a little server type display from the get-go so that the user knows what kind of Fediverse instance something comes from. Misskey and its forks have it, Friendica has it, (streams) has it, Forte has it. Just because Mastodon doesn't have it, doesn't mean it's a good idea not to have it. Besides, if content from certain server applications malfunctions on Letterbook, users can pinpoint right away what server application causes that trouble when submitting a bug report.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations #ConversationContainers #FEP_ef61 #NomadicIdentity