@silverpill In a hilarious twist of fate, this gives (streams) and Forte an unfair advantage. They're nearly identical, they have the same maintainer, but they're two separate implementations, also seeing as Forte uses ActivityPub for nomadic identity, and (streams) doesn't and still uses its own Nomad protocol for it.

Since Mitra appears to implement (streams)/Forte features one by one and cast them into FEPs, that's three implementations already. Two if nomadic identity via ActivityPub is involved. And if Hubzilla happens to have it, too, we've got up to four implementations.

Yes, ActivityPub is only an optional add-on on Hubzilla and (streams), but an implementation is an implementation. And whatever they do on Nomad that federates has to get out through ActivityPub one way or another.

It'd be even more hilariously skewed, hadn't Mike discontinued the five apps between Hubzilla and (streams) on New Year's Eve 2022.

CC: @ slyborg @ Evan Prodromou @ Connected Places @ ArneBab @ Alex Chapman

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # ActivityPub # Hubzilla # Streams # (streams) # Forte # Mitra

@ Rob Ricci @ caterpillar @ Stefan Bohacek @ Ericka Simone This is exactly the problem.

I'm on both Hubzilla and (streams) with multiple channels, and I've been on Hubzilla under various guises for longer than the vast majority of Mastodon users have been on Mastodon. I guess you can say that I know both very well.

I can tell you that the possibilities of Hubzilla's permissions system are staggering. It works on up to three levels: for the entire channel (that's "account" in Mastospeak), for individual connections (that's "followers and followed" in Mastospeak), for individual content (posts and and entire conversations, but also images and other uploaded files and documents).

For example, you can grant or deny permission to

• see your public profile (this requires OpenWebAuth magic sign-on which Mastodon has rejected)
• see your connections (this requires OpenWebAuth magic sign-on which Mastodon has rejected)
• see your public posts in your stream (this requires OpenWebAuth magic sign-on which Mastodon has rejected)
• send you their posts (this means public posts that aren't replies because replies are not posts on Hubzilla)
• like (that's "fave" in Mastospeak; you know, the star), dislike and comment on your posts
• send you DMs
• see your uploaded files (this requires OpenWebAuth magic sign-on which Mastodon has rejected, but this also extends to images and other media embedded into posts, comments and DMs)

All in all, Hubzilla has 18 such permissions, but these are the ones that matter from a Mastodon point of view. They can be granted or denied for your entire channel at seven or eight levels, and if they're denied at channel level, they can be granted for individual connections. Imagine that, on Mastodon, you could allow only certain followers to see your profile and your toots. Or you could only allow certain followed accounts to send you their toots. All of this is reality on Hubzilla right now.

Better yet: You know that you can send toots only to mentioned accounts on Mastodon. Hubzilla exceeds and improves upon this in three ways. First of all, you can send posts to individual connections. Or to a certain privacy group (from a Mastodon POV, that's a list on steroids). Or to a custom selection of individual connections and privacy groups while even being able to exclude certain other connections or privacy groups. This goes way beyond Mastodon's "mentioned = allowed to see".

But this doesn't only define who will receive your post. It also defines who is permitted to see your post.

And: The permissions of a post are inherited by the entire conversation. Comments always have the same permissions as the top post. There's no restricting the permissions in a comment, and there's no relaxing the limitations of a comment. It's impossible to pull other Fediverse users into a private conversation by mentioning them if the top post wasn't targetted at them.

Even better yet: You can allow or disallow comments on individual posts (remember that a post on Hubzilla is only a post if it starts a conversation, not if it's a reply).

On top of all this, Hubzilla's filters are both vastly more powerful than Mastodon's filters and easier to use. Mastodon requires you to set up one new filter for each word that you want filtered. It's always blocklisting. And it's always account-wide.

Hubzilla covers Mastodon's entire filter functionality with one or two text fields. You have one blocklist for the whole channel. And you have an optional extra feature named "NSFW" with its own filter list that generated individual, reader-side content warnings for you. The equivalent of defining a new filter on Mastodon is to add a new line to one of these filter lists. Want to back them up? Just copy-paste them into a text file.

But wait, there's more: Hubzilla also has a channel-wide allowlist. If you only want to see certain content in your stream, you can allowlist certain keywords.

Hubzilla even optionally has one blocklist and one allowlist per connection. Imagine you could filter individual followed accounts on Mastodon.

Hubzilla's filter lists support regular expressions. There is also a "filter syntax" that lets you filter by whether a message is a top post or not, whether a message is public or private, whether it's a repeat (that's "boost" in Mastospeak or "retoot" for those of you who still have Twitter on the brain). The filter syntax even lets you use Boolean operators.

(streams) and Forte are similar. Their permissions are somewhat different (you don't need permissions for wikis and websites if you don't have wikis and websites). The permissions system is vastly easier to use because it's no longer template-based. You can simply switch permissions on and off for your channel as well as for connections. And you can choose to have even more options for reply control.

Again, all this exists in the Fediverse right now. And most of it has existed for longer than Mastodon. Some of this dates back to the earliest days of Friendica in May, 2010.

Unfortunately, next to nobody knows.

For most Mastodon features, the features that Mastodon has are the features that the Fediverse has. If Mastodon doesn't have it, the Fediverse doesn't. Not only is Mastodon the default, but there's nothing that strays from this default. That's why Mastodon users keep wishing for "the Fediverse" to introduce features which Friendica has had for almost 16 years already. Or which Hubzilla has had for over a decade.

In addition, probably not even 10% of all Mastodon users have ever heard of Hubzilla. Probably not even 1% of all Mastodon users know what Hubzilla can do. And even only the existence of (streams) and Forte is almost entirely unknown outside of (streams) and Forte themselves and Hubzilla.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # CW # CWs # CWMeta # ContentWarning # ContentWarnings # ContentWarningMeta # Hubzilla # Streams # (streams) # Forte # Permission # Permissions # ReplyControl # ReplyControls # Filter # Filters # MastodonCentricism # MastodonNormativity

@ 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

@ Ben Pate 🤘🏻 Is this limited to moving to Bandwagon? Or from and to Bandwagon?

Or is the plan to ultimately support moving from anywhere in the Fediverse to anywhere in the Fediverse, including e.g. from ActivityPub-based Mastodon to Nomad-based but ActivityPub-enabled (streams) that works drastically different from Mastodon?

# FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Bandwagon # Mastodon # Streams # (streams) # Emissary

@ IFTAS @ Connected Places I don't think it's that easy to develop an external moderation tool that

• ties into Mastodon and the way Mastodon works
• ties into Hubzilla, (streams) and Forte and their highly advanced permissions systems (everything on these three is permission-driven) and self-moderation capabilities all the same, also seeing as such a tool must be capable of moderating groups/forums

I mean, you could try. But be warned: These three work much, much more differently from Mastodon and the rest of the Fediverse than their presence in the Fediverse may indicate. You'll have to work both with permissions (use the permissions system to achieve what you need to achieve) and past permissions (if you bluntly try to latch your tool onto these three from outside, chances are that their permissions systems won't even let you in).

You'll have to deal with enclosed conversations as per FEP-171b "Conversation Containers" in which the start post always forces its permissions on all comments and replies. You'll have to deal with nomadic identity, with channels simultaneously residing on multiple independent servers. On (streams) and Forte, you'll also have to deal with DIDs according to FEP-ef61 "Portable Objects".

On Hubzilla and (streams), you'll have to deal with servers that don't even use ActivityPub as their base protocol and with both servers and channels that have ActivityPub turned off entirely. And on Hubzilla, you'll have to deal with connections that use wholly different protocols yet again, e.g. diaspora* (remember the $200,000 crowdfunding run back in 2010?).

Also, you'll have to deal with three Fediverse server applications that do not have the Mastodon client API implemented, with feature sets that are completely incompatible with the Mastodon client API and with developers who staunchly refuse to implement it because they basically despise Mastodon with a hot, flaming passion.

And no, making server apps that are nothing like Mastodon at all become more like Mastodon, just so that they can be moderated with a tool that's made for Mastodon, is not a solution because it simply won't happen.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla # Streams # (streams) # Forte

@deutrino

Forte

Advantages:

• written in PHP, runs on a LAMP stack
• uses much fewer system resources than Mastodon while being magnitudes more powerful
• comes with a git-based update script
• result of over 15 years of development (traces back to Friendica from 2010)
• developed by a retired professional developer with almost half a century of experience who has made more Fediverse server apps than anyone else and even more decentralised protocols than anyone else
• does not cache everyone's images and media
• Facebook-like; not a microblogging system
• highly configurable Web UI
• your login/account is not your identity; you can have as many fully independent channels/identities (each corresponding to one full-blown Mastodon account) on the same login/account and switch between them without logging out
• nomadic identity; if you run another server (or you find a public server, and Forte doesn't have any), you can clone your channel between multiple servers and make it resilient against server outage
• over 24 million characters
• full set of text formatting, using BBcode, Markdown and HTML
• supports both titles and summaries (Mastodon understands summaries as CWs)
• embed as many images as you want within the post (as in text, image, more text, another image, even more text etc., like a blog post)
• can double as a long-form blog
• can optionally send multiple-paragraph posts as Article-type objects
• the most advanced permissions system in the whole Fediverse
• full support for threaded conversations; see entire conversations by default instead of single-message piecemeal like on Mastodon; supports FEP-171b Conversation Containers
• supports groups; built-in group functionality including moderated groups and private groups as well as hiding groups (and other channels) from directories
• has at least one support group on (streams)
• built-in cloud file storage which is also used for embedded images; ties into the permissions system; WebDAV connectivity
• built-in federating event calendar
• built-in headless CalDAV calendar server
• built-in headless CardDAV addressbook server
• highly modular, comes with lots of add-ons called "apps"

Disadvantages:

• steep learning curve, especially if all you're used to are Twitter and Mastodon (this looks, feels and handles absolutely nothing like Mastodon, so you'll have to relearn everything from the ground up and learn tons of stuff on top)
• does not cosy up to Mastodon at all, makes few to no concessions for more compatibility with Mastodon
• will need configuration before you can really get started
• doesn't post in public by default; configuration needed if you want to always post in public
• poor documentation
• doesn't work with any phone app out there; progressive Web app with the Web interface is the best you can do on a phone

Advantage or disadvantage, decide for yourself:

• implements ActivityPub by the book (whereas other Fediverse server applications "implement Mastodon" rather than implementing ActivityPub)

(streams)

How it compares to Forte:

• direct precursor of Forte which is forked from it
• from the same developer
• officially and intentionally nameless and brandless ("streams" is the name of the code repository)
• has at least two public, open-registration servers, but they're hard to find
• uses the same support group
• based on its own protocol, Nomad, which has even better support for nomadic identity; ActivityPub is optional and on by default on new channels
• cannot clone from or to Forte

Hubzilla

How it compares to (streams):

• older than Mastodon (forked from a Friendica fork in 2011, development started in 2012, became Hubzilla in 2015, still 10 months before Mastodon)
• created by the same developer, now maintained by two other devs
• server lists readily available on FediDB and Fediverse Observer (in case you want to try it first or clone to a public server)
• even steeper learning curve
• ActivityPub is off by default for new channels, must be activated in order for Hubzilla to federate with most of the rest of the Fediverse
• can optionally federate with diaspora* as well
• can subscribe to RSS and Atom feeds
• requires another bit more of configuration before you can get started
• way better documentation written by a user
• one public and multiple private profiles per channel, can be assigned to certain contacts
• over 16.7 million characters
• text formatting only with BBcode
• cannot send Article-type objects, always sends Note-type objects
• the second-most advanced permissions system in the Fediverse (a bit more complicated and less adapted to today's Fediverse; also, not quite as detailed reply control)
• even more configurable UI
• CalDAV calendar can use the event calender UI
• optional non-federating long-form articles
• optional non-federating wikis (as in multiple wikis per channel with multiple pages per wiki)
• optional non-federating "planning cards"
• optional non-federating webpages

Here you can find lists with detailed comparisons between Mastodon, Friendica, Hubzilla, (streams) and Forte.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla # Streams # (streams) # Forte

@ Tokyo Outsider (337ppm) ...which, in turn, came to exist due to @silverpill's plan to implement nomadic identity à la Hubzilla, (streams) and Forte on something that a) only supports ActivityPub, b) is non-nomadic and c) ties the identity to the login.

I've got my doubts that whoever started the FEP draft, like the vast majority of Mastodon users, has ever really heard of silverpill, Mitra, Mike Macgirvin, Hubzilla, (streams), Forte and/or nomadic identity. Nobody in the thread mentions either of these even only once.

Besides, even Mitra still has a long way to go until it's really as fully nomadic as Mike's creations, also because silverpill most likely doesn't want to implement anything that isn't covered by a FEP. And I can't see Mastodon itself ever going nomadic, seeing as the devs have already silently rejected client-side OpenWebAuth support.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Mitra # Hubzilla # Streams # (streams) # Forte # NomadicIdentity

@ Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.

---

Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.

So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.

Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.

First of all, when I clicked the "Share" button, this short code was inserted into the post editor:

[share⁠=1198713][/share]

The number, by the way, is the running number of the message to quote-post on the server.

Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.

[⁠share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]

Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that [zrl][/zrl] is used rather than [url][/url] which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)

At the same time, curiously, (streams) includes the line "rel": "https://misskey-hub.net/ns#_misskey_quote" and a line that starts with "name": "RE: and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.

So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.

---

Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).

This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.

At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)

"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.

And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.

Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.

Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.

The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.

The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.

Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.

The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.

Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.

In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.

So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.

Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the "canQuote" section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Misskey # Forkey # Forkeys # GoToSocial # Hubzilla # Streams # (streams) # Forte # Mitra # QuotePost # QuotePosts # QuoteTweet # QuoteTweets # QuoteToot # QuoteToots # QuoteBoost # QuoteBoosts # QuotedShares # Permission # Permissions # FEP_044f # FEP_171b # FEP_e232 # FEP_ef61

@Decenta Lyzed @your purple friend AFAIK, Mitra has not rolled out full-blown nomadic identity yet (as in, no, you can't clone your Mitra identity between two Mitra servers). Even the development branch is only in a state in which it understands nomadic identity.

As for what nomadic identity is: https://joinfediverse.wiki/Nomadic.identity

There are three Fediverse server applications where you're guaranteed to have solid, proven-to-work nomadic identity:

• Hubzilla
  Fork of fork of (non-nomadic) Friendica by Friendica's creator
  2012/2015
  https://hubzilla.org
  https://en.wikipedia.org/Hubzilla
  https://joinfediverse.wiki/Hubzilla
  Server lists:
  https://hubzilla.fediverse.observer/list
  https://fedidb.com/software/hubzilla?version=latest®istration=open
  No iOS apps
  No Android apps
  Can be installed as a Progressive Web App
• (streams)
  Fork of fork of three forks of fork (of fork?) of Hubzilla by the same creator
  2021
  Intentionally and officially no name, no brand, hence the parentheses around the unofficial name ("(streams)")
  No official website
  https://codeberg.org/streams/streams
  Open-registration server in North America (USA):
  https://rumbly.net/register
  Open-registration server in Europe (Hungary, German admin, speaks German and English):
  https://nomad.fedi-verse.hu/register
  No iOS apps
  No Android apps
  Can be installed as a Progressive Web App
• Forte
  Fork of (streams) by the same creator
  2024
  No official website
  https://codeberg.org/fortified/forte
  No open-registration servers
  No iOS apps
  No Android apps
  Can be installed as a Progressive Web App

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

@Decenta Lyzed I haven't seen Mitra in action yet, so I can't say anything about it.

Hubzilla creator and (streams) and Forte maintainer, that'd be @Mike Macgirvin ?️. By the way, the only one of the three that's actually ActivityPub-based is Forte. It just doesn't have any public, open-sign-up servers right now AFAIK.

Did I show you my Mastodon/Friendica/Hubzilla/(streams)/Forte comparison tables yet? If not, here they are. But lastly, you have to lay your hands on at least one of them to see how the family differs from the microblogging side of the Fediverse.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mitra #Hubzilla #Streams #(streams) #Forte

@silverpill Who are the longformers anyway?

They're those who either are commercial or looking for professional/commercial users or both. Flipboard. Automattic (WordPress). Ghost. These kinds.

They know themselves. They know each other. And they know Mastodon. And that's it.

None of them has ever heard of Pleroma or Akkoma.

None of them has ever heard of Misskey or the Forkeys.

None of them has ever heard of Mitra.

None of them has ever heard of GoToSocial.

None of them has ever heard of Hollo.

None of them has ever heard of Friendica, Hubzilla, (streams) or Forte, even though Friendica and Hubzilla are both older than Mastodon. And apparently, neither has @ Helge. But then again, Friendica and its nomadic, security-enhanced descendants are being overlooked by almost everyone. That's why there's always on-going work for features to be "introduced to the Fediverse" which Friendica has had for a decade and a half.

Granted, the HTML support on Friendica, Hubzilla, (streams) and Forte can be summarised with "yes". But elaborate tables that show what either of them supports how would be very useful.

Also, granted, everything I've mentioned above (normally) uses something else than HTML for formatting in the frontend. For example, Misskey and all Forkeys use MFM ("Misskey-Flavoured Markdown"). Friendica uses extended BBcode with the option to use Markdown instead. Hubzilla uses even more extended BBcode. (streams) and Forte can use the same even more extended BBcode and Markdown and HTML at the same time within the same post, although not all markup languages support all features.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Mastodon # Pleroma # Akkoma # Misskey # Forkey # Forkeys # Mitra # GoToSocial # Hollo # Friendica # Hubzilla # Streams # (streams) # Forte # LongFormContent # BBcode # Markdown # HTML # TextFormatting

@silverpill

The dataset doesn't include some other popular platforms like Friendica, but I am sure they also display long form content just fine.

Friendica and its descendants from the same creator, Hubzilla, (streams) and Forte, can produce long-form content just fine. With just about all bells and whistles from a title plus six levels of headlines to an unlimited number of images embedded within the text.

So yes, they can display it as well. However, outside of their own communities, hardly anyone knows what they're capable of. Thus, Fediverse developers often try to solve problems that aren't even really there because they were solved before they became problems.

Mastodon's lack of support for articles, linking to the originals instead, is not really a lack. It's a deliberate design decision from around 2017 or so.

See, the first ActivityPub implementation was on Hubzilla. That was in July, 2017. And Hubzilla implemented ActivityPub by the book.

Mastodon followed two months later. But Mastodon has always had its own "interpretation" of ActivityPub that was limited by Mastodon's own intentional design limitations in order to remain Twitter-like, purist, minimalist, old-school, original-gangsta microblogging with as few features that Twitter didn't have as possible.

This is also why Mastodon has a HTML "sanitiser" built in. Up until the release of Mastodon 4.0 in October, 2022, that "sanitiser" reduced any and all incoming HTML to plain text. And it did so for all object types, including the Article-type objects which Hubzilla sent. After all, Hubzilla can act as a fully-fledged long-form blogging platform.

However, the ActivityPub spec defines Article-type objects as formatted long-form content. Still, Mastodon defaced Hubzilla's Article-type objects by reducing them to plain text.

So Mike Macgirvin got into contact with Eugen Rochko and told him to adhere to the spec and deactivate Mastodon's "sanitiser" and make it support full HTML rendering for Article-type objects.

And Eugen Rochko said that bold type and italics and bullet-point lists and images in the middle of the content have nothing to do with old-school microblogging, so they have no place on Mastodon, so he won't implement them.

This head-butting went back and forth. Eventually, Eugen presented a "solution". And that was not to render Article-type objects at all anymore. Instead, Mastodon links to them and adds their title above if they have one.

This was only done to shut Mike up so he'd stop complaining about Mastodon defacing Hubzilla posts and breaking the spec by doing so. From Mike's perspective, however, what Eugen did was flip Hubzilla the bird by completely refusing to show actual Hubzilla content and practically lock out a competitor.

Mike's reaction was to break the spec himself and switch Hubzilla from sending Article-type objects to sending Note-type objects, regardless of Mastodon still defacing them.

With the exception of a very short period after the release of Hubzilla 9.0 when Mario Vavti and Harald Eilertsend learned the hard way that Mastodon still links to Article-type objects, Hubzilla has only sent its posts as Note-type objects ever since.

Mike's other creations have different ways of handling object types.

Friendica, by default, sends posts with titles as Article-type objects and posts without titles as well as comments as Note-type objects. This can be deactivated so that Friendica only sends Note-type objects.

CC: @ Laurens Hof

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # Streams # (streams) # Forte # ArticleType # NoteType # LongFormContent

@silverpill

The dataset doesn't include some other popular platforms like Friendica, but I am sure they also display long form content just fine.

Friendica and its descendants from the same creator, Hubzilla, (streams) and Forte, can produce long-form content just fine. With just about all bells and whistles from a title plus six levels of headlines to an unlimited number of images embedded within the text.

So yes, they can display it as well. However, outside of their own communities, hardly anyone knows what they're capable of. Thus, Fediverse developers often try to solve problems that aren't even really there because they were solved before they became problems.

Mastodon's lack of support for articles, linking to the originals instead, is not really a lack. It's a deliberate design decision from around 2017 or so.

See, the first ActivityPub implementation was on Hubzilla. That was in July, 2017. And Hubzilla implemented ActivityPub by the book.

Mastodon followed two months later. But Mastodon has always had its own "interpretation" of ActivityPub that was limited by Mastodon's own intentional design limitations in order to remain Twitter-like, purist, minimalist, old-school, original-gangsta microblogging with as few features that Twitter didn't have as possible.

This is also why Mastodon has a HTML "sanitiser" built in. Up until the release of Mastodon 4.0 in October, 2022, that "sanitiser" reduced any and all incoming HTML to plain text. And it did so for all object types, including the Article-type objects which Hubzilla sent. After all, Hubzilla can act as a fully-fledged long-form blogging platform.

However, the ActivityPub spec defines Article-type objects as formatted long-form content. Still, Mastodon defaced Hubzilla's Article-type objects by reducing them to plain text.

So Mike Macgirvin got into contact with Eugen Rochko and told him to adhere to the spec and deactivate Mastodon's "sanitiser" and make it support full HTML rendering for Article-type objects.

And Eugen Rochko said that bold type and italics and bullet-point lists and images in the middle of the content have nothing to do with old-school microblogging, so they have no place on Mastodon, so he won't implement them.

This head-butting went back and forth. Eventually, Eugen presented a "solution". And that was not to render Article-type objects at all anymore. Instead, Mastodon links to them and adds their title above if they have one.

This was only done to shut Mike up so he'd stop complaining about Mastodon defacing Hubzilla posts and breaking the spec by doing so. From Mike's perspective, however, what Eugen did was flip Hubzilla the bird by completely refusing to show actual Hubzilla content and practically lock out a competitor.

Mike's reaction was to break the spec himself and switch Hubzilla from sending Article-type objects to sending Note-type objects, regardless of Mastodon still defacing them.

With the exception of a very short period after the release of Hubzilla 9.0 when Mario Vavti and Harald Eilertsend learned the hard way that Mastodon still links to Article-type objects, Hubzilla has only sent its posts as Note-type objects ever since.

Mike's other creations have different ways of handling object types.

Friendica, by default, sends posts with titles as Article-type objects and posts without titles as well as comments as Note-type objects. This can be deactivated so that Friendica only sends Note-type objects.

CC: @ Laurens Hof

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # Streams # (streams) # Forte # ArticleType # NoteType # LongFormContent

@Tim Chambers And again, Friendica, Hubzilla, (streams) and Forte are way ahead. They were all made modular right from the start, and they can all be expanded with third-party add-ons and third-party themes (provided someone makes them) by adding third-party git repositories to your server. It helps that they themselves are all installed via git in the first place.

For example, it's possible to add entirely new protocols as add-ons. On Hubzilla, protocols that aren't Zot (ActivityPub, diaspora*, RSS/Atom etc.) are add-ons and off by default for new channels. Hubzilla's counterpart to Mastodon's lists, only vastly more powerful, is called "privacy groups" and an official add-on that's off by default again. CalDAV calendar server? Wikis? Webpages? All add-ons. (streams) and Forte have a somewhat different set of add-ons and a different set of add-ons that are on or off by default for new channels.

You can bolt all kinds of stuff to these four as third-party add-ons. Want a dating platform in the Fediverse? Just write an add-on for one or several of these four that ties into their (main, public) profiles with their dozens of fields, and you've got one.

Better yet: You can upgrade the whole server, the core, the official add-ons, the official themes, third-party add-ons, third-party themes, in one fell swoop. Not first the official stuff and then each third-party repo one by one, but all at once. At least on Hubzilla, (streams) and Forte, util/udall is the little helper that does it all for you.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # Forte # git # ThirdParty # AddOns # PlugIns