I found the app just two days ago and I love how it suddenly makes #friendica a feasible project from my point of view. 💖 💥 💯

I'm scratching my head how to make Friendica groups an alternative to FB groups. It's sorely needed in my community(ies) where everyone's using FB groups.

I have some suggestions I'd like to make. Like the "profile view" for a group should default to "classic view" and post and replies, to be useful.

@friendicatalk #friendicaTalk

you should add it to #fedidb (right now only my app shows up for #friendica)

fedidb.com/apps?projects=frien…

@𝔻𝕚𝕖𝕘𝕠 🦝🧑🏻‍💻🍕 Okay, so I understand this is not going to happen. I can't explain it better. I think it might be a result how the federation on fediverse is working.
Lets imagine a scenario like this:
User 1 and User 2 are following each other. They both also follow user 3 but only user 2 is following user 4.
User 4 follows User 2 but not User 1 and User 3. User 1 and User 3 are not following User4.
User 2 posts a public message to his timeline. User 1, User 3 and User 4 receive that post as they all are following user 2.
User 3 replies. User 1 User 2 and User 4 will receive the reply.
User 4 replies. User 2 receives the reply but User 1 and User 3 won't receive it as they don't follow User 4. And this is the part where the conversation flow is breaking.

I was hoping it might be somehow possible to compensate for this client side, but if the posts identifiers are different accross instances or different fediverse servers such as friendica / mastodon, then I understand we are screwed and there is no way around this.

Still I believe when viewing a post it might be possible to consider adding an entry to the options menu of that post saying something like fetch from original instance and that would fetch the whole conversation from that instance without logging in to that instance effectivelly allowing doing what we can now do in the browser i.e. open the original post as seen at their site.

Then follow up difficulties might be how to like and boost such a post if my instance may not know that post.

I understand this is complex so perhaps lets keep it for the future and thing about possible difficulties until that time.

@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