@silverpill

I am curious about #Mitra, so here are a few questions; hope you don’t mind.

(continues)

@ 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

@ Johannes Ernst The first step is already done:

Forte, @ Mike Macgirvin ?️ most recent project from the same family that started with Friendica 15 years ago, is the first and only stable Fediverse server application that uses ActivityPub for nomadic identity. Nomadic identity itself is a concept created by Mike in 2011 and first implemented by himself in 2012 in a very early version of Hubzilla which he called Red back then.

This means that you can have the exact same channel/identity (think Mastodon account, but without its own login) on multiple server instances with one account each. If one server goes down, you still have at least one clone (depending on how many clones you make).

@silverpill is working on implementing this on Mitra. It's still only available in development versions, though. The difference is that Mike had already created a whole bunch of Fediverse server applications with nomadic identity since 2012; he "only" had to port nomadic identity from the Zot or Nomad protocol to ActivityPub. Silverpill, on the other hand, has to implement nomadic identity in something that was built upon ActivityPub with no nomadic identity.

Both recognise each other's nomadic identities. (For comparison: Mastodon doesn't recognise any nomadic identities. It takes the two instances of this Hubzilla channel of mine for two fully separate identities.) But that's all for now.

The next step, and that's way into the future, would be to be able to clone from Forte to Mitra or from Mitra to Forte. This would give you one identity on at least two server instances of two separate Fediverse server applications.

The obvious downside is that you won't be able to take everything with you everywhere when you clone to other server types. For example, if you clone a Forte channel to Mitra, you won't be able to take your permissions settings, your permission roles, your friend zoom settings, the contents of your cloud storage, your CalDAV calendars and your CardDAV addressbook with you over to Mitra. That's simply because Mitra doesn't have any of these features.

What you envision is another step further. And that's the adoption of nomadic identity via ActivityPub and ideally also OpenWebAuth magic single sign-on, another one of Mike's creations, by all Fediverse server applications. And I mean all of them. Including extremely minimalist stuff like snac2 or GoToSocial. Including stuff that isn't actively being worked on like Plume. Including stuff that's dead, but that still has running servers, like Calckey, Firefish or /kbin. And including Mastodon which stubbornly refuses to make itself more compatible with the "competition" in the Fediverse and adopt technologies created by anyone else in the Fediverse, even more so if that someone is Mike Macgirvin.

In other words, this won't happen. Mastodon would rather turn itself into its own federated walled garden by becoming incompatible with all other ActivityPub implementations.

What many Mastodon users who know nothing about decentralisation wish for is another step further. And that's to create one account on one server instance of one Fediverse server software, no matter which, and then to have full-blown user permissions on any instance of any Fediverse server software.

Like, create one account on mastodon.social, go to a Pixelfed instance, post pictures Instagram-style, go to a PeerTube instance, upload videos, go to a WriteFreely instance, blog away, go to a Hubzilla hub, build a webpage, all with only your mastodon.social login.

Of course, this is impossible to do. This would mean that if you create an account on one Fediverse server instance, it would have to be cloned to all 30,000+ servers in the whole Fediverse instantaneously. And if you start your own instance, it would have to trigger 30,000+ servers to clone their tens of millions of accounts and channels over to your instance.

Usually, when I explain this to people who want to use everything with one login, they tell me that they don't want to use every server in the Fediverse. No, but they want to use any server in the Fediverse. Any one of the 30,000+.

And they want to use it immediately. Like, go there, use it with full-blown local user permissions right away, no delay.

Now you may argue that their account or channel could be cloned to that server when they visit it for the first time. Drive-by cloning, so-to-speak. Still, won't happen. Cloning takes time. I myself have cloned enough Hubzilla and (streams) channels over the years to be able to estimate just how long it takes. And none of my channels has ever contained tens of thousands of posts and thousands of pictures.

Besides, drive-by cloning would inflate Fediverse instances senselessly, not to mention bog them down with extra network traffic. Whenever you visit a Fediverse server instance for whichever reason (like, you want to look at a post on Friendica or Hubzilla to see what it looks like without being botched by Mastodon), your account or channel would automagically be cloned to that server instance. Another account (and channel, if necessary) on that server instance, another deluge of posts and files flooding into the database, and that clone would have to be synced with your 600 other previous drive-by clones on the 600 Fediverse server instances you've visited before.

Extra nefarious: Some "websites" that have to do with Hubzilla or a certain aspect of Hubzilla are parts of Hubzilla channels themselves. This includes the official Hubzilla website. If you visited them, you'd create a drive-by clone on the Hubzilla hub which hosts that website.

So if someone set up a single-user Hubzilla hub with their personal channel and a website channel on it, and the website is interesting enough, and 10,000 Fediverse users visit it, it'll end up bigger than the biggest current Hubzilla hub within days. It'll have 10,001 accounts, namely the owner's account with two channels and 10,000 accounts with drive-by clones, automatically created by the 10,000 external visitors.

But this will remain utopic not only because it's technologically pretty much impossible and very much not feasible at all. It also requires a mechanism for one Fediverse server to recognise logins on other Fediverse servers. You know, like OpenWebAuth. You want your Mastodon account to drive-by clone itself, Mastodon will have to implement OpenWebAuth, and I mean fully implement it.

There actually is a pull request in Mastodon's GitHub code repository that would have implemented client-side OpenWebAuth support (= Hubzilla, (streams) and Forte would recognise Mastodon logins). This isn't even about full-support that'd include login recognition on Mastodon's own side. This pull request has been there for two years. It was never merged. And it probably will never be merged.

This means that the Mastodon devs have practically rejected OpenWebAuth as a feature to implement. Won't come. Ever. Not even half of it.

And this should say everything about the chances that Mastodon will ever implement nomadic identity.

CC: @ william.maggos @ Richard MacManus @Tim Chambers @ Ben Pate 🤘🏻

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