@unattributed 𓂃✍︎ @Ben Pate 🤘🏻 @Social Web Foundation @Sovereign Tech Agency @Bonfire Ideally, one day, the highly advanced permissions system available on Hubzilla (based on Zot, ActivityPub optional), (streams) (based on Nomad, ActivityPub optional) and Forte (based on ActivityPub) would be cast into one or multiple FEPs.

This would solve this issue by not only controlling who receives a DM, but also who is permitted to see the DM. In combination with FEP-171b Conversation Containers (which was invented on (streams), inherited by Forte and backported to Hubzilla), the permissions of the DM would be inherited by all comments and replies to the DM with no way of ever changing these permissions anywhere in the conversation.

See, if I send a DM to Alice and Bob, then only Alice, Bob and I are permitted to see the DM. Also, only Alice, Bob and I are permitted to participate in the conversation, and Alice, Bob and I can see each comment and reply, but only the three of us are permitted to see them. The entire conversation has the exact same permissions all over, inherited from the initial DM.

Anyone of us can mention Carol all we want. But that does not give her permission to see anything in the conversation, not even the comment/reply that mentions her. Once the initial DM is out, its permissions are set in stone, and it's also set in stone that any and all follow-ups in the same conversation have the same permissions as the initial DM.

This does not even require encryption. That said, at least Hubzilla does offer encryption on top of the permissions system; however, it's only compatible within Hubzilla AFAIK.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #FEP_171b #ConversationContainers #Permission #Permissions #DM #DMs #DirectMessage #DirectMessages #PrivateMessage #PrivateMessages
Social Web Foundation

Towards a bigger, better fediverse

Social Web Foundation

FEP-171b: Conversation Containers has been updated:

https://codeberg.org/fediverse/fep/pulls/669

Notable changes:

- Implementers are not required to publish the container collection anymore (although this is recommended). This part of the spec might be difficult to implement in some projects, so it was decided to relax the requirement.
- Sequence diagram. Could be viewed at https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md#containers
- Comparison of Conversation Containers and forwarding from inbox.

#fep_171b #ConversationContainers

FEP-171b: Update proposal

- Specified that collection SHOULD be implemented. - Specified access control. - Added sequence diagram. - Clarified delivery vs addressing. - Fixed examples. - Updated link to GtS Interaction Policy. - Compare to forwarding from inbox. - Added Mitra to the implementation list. - Change d...

Codeberg.org
@D. Olifant It has been solved by Friendica for 15 years. Five and a half years longer than Mastodon has been around.

It has been solved by Hubzilla for 10 or 13 years, depending on what you count as Hubzilla's first release.

It has been solved by the other members in the family just as well.

There even is an FEP for that which is based on how (streams) and Forte do it: FEP-171b Conversation Containers.

CC: @Tim Chambers

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations #FEP_171b #ConversationContainers
fep/fep/171b/fep-171b.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org
@Scott Jenson The "can't see all replies" is a deeply hard federation problem but we have an incoming fix for that!
You mean the kind of "fix for that" that Friendica when it was launched into the Fediverse 15 years ago? Namely full awareness and support of threaded, one-post-many-comments conversations?

Or, better yet, Conversation Containers as created by Friendica's creator in his own streams repository, then inherited by his own Forte, then backported to his original creation Hubzilla as per FEP-171b?

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

@Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.

The Sin of Overwhelming Complexity: Instance Selection Paralysis


The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.

In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.

In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.

Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.

Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.

Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.

The Sin of Inconsistent Navigation: Timeline Turmoil


The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.

First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.

Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.

However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.

Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.

The Sin of Remote Interaction Purgatory: Federation Gymnastics


Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.

But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.

You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.

Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.

So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.

Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.

Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).

Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.

Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.

The Sin of DM Disasters Waiting to Happen


I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).

On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.

If I want to DM you, I can either tag you @!{[email protected]} rather than @[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.

Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.

Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.

If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).

Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.

Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.

The Sin of Ghost Conversations and Phantom Follower Counts


And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.

Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.

This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.

Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.

Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.

Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.

So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.

The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.

The Sin of Invisible Discovery: The Content Mirage


I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.

But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.

Also:
  • Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
  • Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
  • (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.

Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.

Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.

(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.

As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.

The Sin of User Discovery Hell


Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.

Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.

The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.

Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.

Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?

Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.

Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.

Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.

(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.

These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").

Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.

This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.

(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.

If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.

A global directory of everything sounds like a good idea, but it's next to impossible to implement.

Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?

Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.

For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.

Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.

Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.

But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.

Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.

Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?

CC: @Risotto Bias

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers
Hubzilla Fediverse Server and Community

@Rob Shearer

Excellent write-up, agree with most of the points.

On a related note: it is a pity that the poorly thought-out and designed Mastodon became the overwhelmingly popular Fediverse platform. I wish it were one of the Mike Macgirvin creations such as Hubzilla or (streams) or Forte, with their advanced features such as Nomadic Identity, OpenWebAuth (Federated Single Sign On), conversation containers for threaded conversations, extremely fine-grained privacy controls, etc.

Nomadic Identity, in particular, is brilliant. This is how it works. You have a channel (that participates in the Fediverse, this is equivalent to an account on Mastodon) on any account on, let us say, Hubzilla instance A. You can open another account on Hubzilla instance B, and create a clone there of your channel on instance A. So this clone becomes a live, real-time backup of your channel; the backup includes your connections as well as your posts. And it is bidirectional. You can log on to your clone channel on B, and use it like your main instance, and now the clone on instance A will mirror your activity. If you wish, you can clone the channel on a third instance C. If one of A or B or C abruptly shuts down, you can continue operating your channel from your clone channel, so you lose nothing.

This addresses one of your pain points as to how account migration does not work on Mastodon.

By the way: you can have multiple channels per instance, and you can have clones of each channel on different instances. So if you wish, you can have separate channels for your hobbies and your professional activities and your politics; all contained and operated within a single account on a particular instance.

You can read more about Nomadic Identity here

#^https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b

and here.

#^https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b

It is said that Bluesky is working on pioneering something like Nomadic Identity. Ironically, Mike Macgirvin had already pioneered it all the way back in 2012. He initially did it with Nomad (which underlies Hubzilla and (streams)), a protocol far richer and better-defined than ActivityPub; and recently, he even got Nomadic Identity working on ActivityPub.

#^https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584

Unfortunately, the movers and shakers of the ActivityPub world keep pretending that Mike Macgirvin and his work does not exist.

Then there’s OpenWebAuth for Federated Single Sign On. This enables seamless granting of permissions for you to operate your social dashboard from different parts of the Fediverse.

You can read here how Nomadic Identity and OpenWebAuth together enable network resilience, censorship resistance, and ease of migration.

#^https://wedistribute.org/2024/03/activitypub-nomadic-identity/

There’s also conversation containers—these ensure that unlike on Mastodon, every single post/comment in a conversation thread is visible to every single person participating in or merely viewing the thread. (Also: you don't need @ tagging, anyone who participated in the conversation by replying at least once or by boosting or liking some post is notified of all new posts/comments.)

I won’t elaborate on the fine-grained privacy controls, but I think they too address some of your pain points with Mastodon.

Having said all that, I must mention that your core criticism of Mastodon also applies to Hubzilla, (streams), and Forte: there is asynchronous distribution of “some subset of a global database across some parts of the network”. I personally think there ought to be a truly universal search and community-controlled user-specific custom algorithms to address this problem, but I doubt the vocal part of the userbase here would agree.

And relative to Mastodon, the Hubzilla+(streams)+Forte community is tiny, so there is hardly any local content.

#Nomad #Zot #ActivityPub #Mastodon #Hubzilla #Forte #NomadicIdentity #OpenWebAuth #ConversationContainers #PrivacyControls

@Jeff Atwood
Nomadic identity, brought to you by Hubzilla

If you haven’t heard of Hubzilla yet, it is an advanced platform for online communications and content publishing powered by a…

Medium
@Xhuul As a user, Hubzilla (official website) and (streams) (code repository).

Why, you ask?

tl;dr: Both Hubzilla and (streams) blow Mastodon out of the water big time in every way possibly conceivable.

  • Modular architecture. Features (so-called "apps") can be activated and deactivated server-wide by the admin and then activated and deactivated on individual channels by the users. Third-party app and theme repositories can be added to servers. More and more third-party themes are becoming available for Hubzilla which actually change the layout of the UI. (streams) already has two themes to choose from.
  • Nomadic identity. Basically bidirectional, near-real-time, live, hot backups of your channels on another server, so-called clones. And the clones can be used just the same as the main instances of my channels. One server shuts down, I lose nothing, I've got at least one clone.
  • Channels. One account, one login, multiple fully independent identities.
  • Full support for discussion groups/forums, both public and private, both visible in and hidden from directories.
  • Full support for threaded conversations by means of Conversation Containers.
    On Mastodon, a conversation is loosely strung together from posts and more posts. And you're mostly shown piecemeal of single posts. All you ever see is posts that mention you and posts from those whom you follow.
    On Hubzilla and (streams), a conversation is the same as on Facebook and Tumblr and every blog out there: one post, any number of comments that totally aren't posts. And you're always shown entire threads with the start post and all comments (unless blocking is in the way). Everyone sees everyone else's comments, always within the context of the conversation.
  • Mastodon: doomscrolling until you want no more, or until you've got no more time. What you don't scroll down to will remain unread forever. No alternative.
    Hubzilla and (streams): unread messages counter plus unread messages list. Click one message on the list, and the whole thread around that message will be displayed, and only that thread, and all unread messages in that thread will be marked read.
  • No character limit to speak of.
    Mastodon: 500 characters, chosen arbitrarily.
    (streams): over 24,000,000 characters, limited by the database field size.
  • Text formatting. Just about all of it. With BBcode on Hubzilla and with BBcode, Markdown and HTML on (streams).
  • Spoiler tags. In addition to a summary (which Mastodon misuses for CWs).
  • Quotes.
  • Quote-posts. (Yes, that's something else than quotes. And yes, Hubzilla and (streams) can quote-post Mastodon toots right now with no problems.)
  • Being able to embed images within posts. Not as file attachments, but in-line, right between paragraphs, with text above and more text below. You know, like on a blog.
  • Unlimited number of images per post.
  • Unlimited number of options per poll.
  • The most advanced and fine-grained permissions systems in the whole Fediverse. Well over a dozen individual permissions on up to three levels: for the whole channel, for individual connections, per post/thread. Including reply controls which are even more advanced on (streams) than on Hubzilla.
  • Private messages, not direct messages.
  • Being able to post only to one specific what-amounts-to-a-list-on-Mastodon-but-on-coke-and-roids. Nobody else can see the post. Nobody else can see the comments thread. And nobody else can comment.
  • Regular expressions in filters.
  • (Optional on Hubzilla) Individual filters per connection, one whitelist, one blacklist.
  • ((streams) only; Hubzilla needs filter syntax for this) Declutter your stream by choosing to block boosts either for your whole channel or from individual connections.
  • (Optional) Separate text filter that automatically hides posts behind content warnings generated reader-side, easy to configure with only one list of keywords (which supports regular expressions at least on (streams))
  • (Optional) Friend zoom/affinity slider that lets you filter your stream by how "close" you are to certain connections (all the way to the left: only you; all the way to the right: everyone).
  • (Hubzilla only) Connect to diaspora* users.
  • (Hubzilla only) Subscribe to RSS and Atom feeds.
  • Integrated cloud file space with built-in file manager, permissions management and WebDAV connectivity.
  • Integrated event calendar.
  • Integrated CalDAV calendar server (which uses the event calendar UI on Hubzilla).
  • (Optional on Hubzilla) Integrated CardDAV addressbook server.
  • (Hubzilla only; optional) Post long-form, formatted, non-federating articles.
  • (Hubzilla only; optional) Make long-form, formatted, non-federating planning cards.
  • (Hubzilla only; optional) Built-in wiki engine for multiple wikis per channel with multiple pages each.
  • (Hubzilla only; optional) Add basic webpages to your channel.

By the way, Hubzilla is older than Mastodon. And Hubzilla even supported ActivityPub before Mastodon.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #NomadicIdentity #Permissions #Conversations #ConversationContainers
Hubzilla - Join the Fediverse

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

@Hamiller Friendica Es gibt auch noch FEP-171b "Conversation Containers". Das basiert auf etwas, was (streams) vor etwa einem Jahr eingeführt hat. Bis dahin hatte (streams) dasselbe Konversationsmodell wie Hubzilla, das wieder dem von Friendica ähnlich ist. Und vor einer Woche hat Hubzilla selbst Conversation Containers eingeführt.

Davon mal abgesehen könnte das gesamte Threadiverse (Lemmy, Mbin, PieFed...) ohne ein Konzept von Konversationen auch nicht funktionieren.

Es geht also schon. Auch mit reinem ActivityPub. Die Entwickler müssen nur wollen. Aber Mastodon will im Grunde nichts, was Twitter vor Musk nicht auch hatte.

CC: @Christiane Brauch :calckey:

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #ConversationContainers #FEP_171b
fep/fep/171b/fep-171b.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org
@criley :manjaro: @Robert Kingett To be fair, these aren't all general Fediverse issues. It isn't like the whole Fediverse has them. They just seem to be general Fediverse isses if all you've ever experienced first-hand in the Fediverse is Mastodon, and if you think the Fediverse is mainly a Twitter-like microblogging platform with YouTube, Instagram and TikTok clones glued on.

For example, the issue of replies is mostly one on Mastodon because of how Mastodon has always tried to ape Twitter. Mastodon doesn't know conversations. Those who only know Mastodon are keen to deny this and say that Mastodon does know conversations. But those who have experienced Friendica, Hubzilla and/or (streams), not to mention the Threadiverse, know what support of conversations in the Fediverse can really be like.

A key element of conversations is the distinction between posts and comments. In conversation models, posts only ever stand at the start of a conversation, and everything that follows is not a post, but a comment. And this exists in the Fediverse. It has been around for much, much longer than Mastodon which does not and doesn't want to distinguish between posts and comments.

Friendica was launched in July, 2010, five and a half years before Mastodon. For as long as Mastodon has been around, it has been continuously federated with Friendica.

But Friendica is not another Twitter clone. It was created as an alternative to Facebook, but better than Facebook and with full long-form blogging capabilites among its features. Now, blogs have a one-post-many-comments conversation model, and so does Facebook. So, logically, so does Friendica.

On Friendica, a conversation isn't post-by-post piecemeal, and it isn't shown as piecemeal. It is shown as a whole with the post at the top, a comment tree below and the comment entry mask at the bottom. Same as on blogs or forums or Facebook etc.

Now here comes the actual kicker: Once you receive a post (remember the distinction between posts and comments), you also receive all comments. From people whom you don't follow and who didn't mention you. Even from accounts on instances which the Friendica node you're on has never heard of. Whenever someone replies to a post you've received in the past, whenever someone replies to a comment on a post you've received in the past, you get that reply onto your list of unread activities.

That's because you don't receive that reply from the replier. You receive it from the original poster who owns the whole thread.

Better yet: This entire system works without mentions. Mentions are only for show if you comment on a comment so that it's clear whom exactly you're replying to. That is, on today's Friendica, even that isn't necessary anymore because Friendica has switched from a strictly chronological comment order to a comment tree.

It's funny how the Fediverse sees this as something between utopic science-fiction and entirely inconceivable. But for the Fediverse, Twitter has always been the gold standard, and everything that works differently is weird, even the much, much bigger Facebook.

Hubzilla has inherited this behaviour from Friendica. After all, it was built from a Friendica fork from 2012 by Friendica's own creator, @Mike Macgirvin 🖥️, and it itself emerged in 2015, still ten months before Mastodon. And again, Mastodon has always been federated with Hubzilla. In fact, when Mastodon introduced ActivityPub in September, 2017, even then it connected to Hubzilla via ActivityPub because Hubzilla had implemented it in July.

The key difference is that Hubzilla added extensive permission controls to the mix. On Hubzilla, a conversation always has the same permissions all over. Comments cannot have different permissions than the post, and the original poster can't change the permissions after posting anymore.

Another step in the evolution is the streams repository which contains a decentralised social networking application that's officially nameless, but commonly referred to as "(streams)" in parentheses. It's a fork of a fork of three forks of a fork of probably another fork of Hubzilla, all forks in this chain and all the way back to Friendica are by the same creator, and it's from October, 2021.

Like Friendica in the meantime, and unlike Hubzilla where conversations are still strictly chronological, (streams) has tree-style comments sections.

About a year ago, the conversation model on (streams) was reworked again into something that was named "conversation containers". Mike explains them in this post:

(Start quote)

In the microblog model, Francis posts a message and it goes to all his followers. Taylor responds and the response goes to all her followers. Taylor's response is rarely seen by the rest of Francis's followers. They are different conversations with completely different audiences.

In the conversation model, Francis posts a message to all his followers. Taylor responds (only) to Francis, and Francis relays the comments to all his followers.

In this way, Francis has a contained conversation. There is one audience and one set of messages that are part of the conversation. Francis owns this conversation and decides who is a part of it. Taylor's followers aren't involved in any way.

This type of construct is a requirement for providing private groups and circles/aspects in the fediverse - as these features are by definition "contained conversations". It mostly provides a range of interactions that can't really be provided by the microblog model.

(End quote)

Conversation containers have since been turned into an ActivityPub FEP, FEP-171b. A few days ago, Hubzilla introduced them with version 10.

And indeed, both with conversation containers and their predecessor from Hubzilla, the thread starter is the exclusive owner of the whole thread. The thread starter decides who can see the start post and therefore the whole thread. The thread starter decides by channel role and contact roles who is allowed to comment on their posts as well as on comments on their posts, and on Hubzilla, the thread starter may even optionally forbid comments on a new thread entirely.

However, this is limited when software that doesn't understand any of this comes into the mix, especially Mastodon. What does work is limiting the audience of a post and therefore the whole thread. Mastodon understands anything from Hubzilla or (streams) that isn't public as a DM, and it doesn't let you e.g. boost DMs to your own followers.

But Mastodon doesn't know permissions. Mastodon doesn't know enclosed conversations. And Mastodon doesn't know the concept of permissions being defined by the start post. And so it's possible to change the permissions for a reply to a post from Hubzilla or (streams).

Granted, you can't reply to a restricted-audience thread in public because you can't reply to a Mastodon DM in public. But you may be tempted to make a reply to a public post private and believe it actually is private. It isn't.

Also, while you, as the thread starter, can delete comments from your own threads, you can't fully undo them. A deleted comment is also removed from all copies of the thread on Hubzilla and (streams), maybe also on Friendica. But the deletion is not carried out by all the microblogging instances in the Fediverse, whatever they run. And especially, if the bad comment came from e.g. Mastodon, neither Hubzilla nor (streams) can delete the post that became this comment from the commenter's own Mastodon account.

This is not a limitation on Hubzilla's or (streams)' side. It's a limitation on Mastodon's side. And it can only be fixed by Mastodon adopting conversation containers as well as a permission model like on (streams).

I can already predict that this will not happen. Eugen Rochko is too proud to adopt technology from developers of directly competing Fediverse server applications into Mastodon. His devs are brainwashed into "knowing" that Mastodon is superior to everything else in the Fediverse in any way imaginable. Mastodon itself is constantly trying to force its own proprietary designs upon the rest of the Fediverse. It's supported by Mastodon fundamentalists who think that Mastodon is the Fediverse gold standard, and "different from Mastodon" means "broken".

And adopting technology from elsewhere in the Fediverse would require Mastodon to officially acknowledge the existence of a Fediverse outside of Mastodon (plus commercial players), especially one that does certain things better than Mastodon.

CC: @jwz

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

I'm winding down the effort on conversation containers now, so if you've still got any issues that haven't been addressed, please let me know. (The issue with empty messages in Hubzilla has been addressed and is working its way through the system). Since there is still some confusion, I'll try to...