jupiter_rowland@hub.netzgemeinde.eu

@Jakub Urbanowicz Keep that account. At the very least, you'll need somewhere to clone to.

Yup, you have the registration option on the login form, you even have the registration form, but you get a pop-up that tells you that registration is closed.

At the same time, registration on @Der Pepe (Hubzilla) ⁂'s server is open, but nodeinfo seems to say otherwise.

If the one (streams) server that I'm on wasn't currently offline (I hope it'll come back because I've got no clones), I could check which Forte servers it knows, for it seems to know half the Fediverse.

@Jakub Urbanowicz That's weird.

https://forte.fediverse.observer/list (yes, this exists) only lists one server with open registration, and that's one that you haven't found yet.

Either the servers you've found actually don't have open registration, but they still have the option on the login form. Or it's nodeinfo spurting nonsense when it isn't supposed to.

@Der Pepe (Hubzilla) ⁂ In a sense, the same applies to (streams)' post-FEP-ef61 nomadic identity.

I've managed to clone a few (streams) channels, but all my (streams) accounts are pre-FEP-ef61. Most accounts registered post-FEP-ef61 were registered into a (streams) ecosystem that barely offered any servers to clone to.

I guess that (streams) and Forte have fewer than 50 users combined, most of whom run their own private servers for exactly one user and with probably exactly one or two channels, depending on whether or not they daily-drive the admin channel.

What's really standing in the way of both testing nomadic identity on (streams) and Forte and for either to succeed is the lack of people willing and able to run public servers with open registration, regardless of how big these servers will be. Not just set them up, keep them running and peek in every three to six months, but actually pay attention to them and keep them well-maintained.

But then again, we've only got a small handful of such people on Hubzilla. Not many beyond Mark and you, which is why Mark holds most of Hubzilla on his two hubs. And because Scott doesn't really get his planned hubs going, even Americans join Mark's two German hubs.

Vice versa, if a German wants to try out (streams), they may have to join Waitman's American server. Ping times from hell included.

Nomadic identity as a whole is a purely theoretical construct as long as you've got nowhere to clone to.

@Jakub Urbanowicz Mastodon users would cheer if they got nomadic identity. Maybe unless it made things significantly more difficult for them because their identity was channelised.

Mastodon developers, however, would only implement nomadic identity under pressure, if at all. That pressure would be most of the rest of the Fediverse being nomadic and at least one nomadic microblogging/social networking application offering a fairly easy import of Mastodon accounts.

They would only implement nomadic identity if people started running away from Mastodon because it doesn't have nomadic identity. In all other cases, they'd refuse to implement it, at least pan-Fediverse nomadic identity, out of fear that Mastodon users would run away from Mastodon because it's so easy now. If anything, they'd implement nomadic identity in a way that still makes it impossible to move or clone from Mastodon to elsewhere.

But they probably wouldn't implement it if they didn't have to. After all, they refused to implement client-side OpenWebAuth support as well. There's literally a merge request on Mastodon's GitHub that'd implement client-side OpenWebAuth support, and that has been lingering since 2023, completely ignored by the devs. Back then, one merge would have been sufficient to give Mastodon client-side OpenWebAuth support.

So much about whether the Mastodon devs are willing to implement something that Mike Macgirvin has invented. Especially if they can't sell it to their faithful followers as their own original invention, and if they can't sell it to their faithful followers without admitting that there's something else than Mastodon out there in the Fediverse.

But even if Mastodon's devs wanted to implement full server-side nomadic identity, that doesn't mean it'll be easy. Basically, large parts of Mastodon's server backend would have to be rewritten. I guess this is why silverpill threw in the towel, gave up trying to implement nomadic identity on Mitra server-side and built a nomadic client instead.

There is no case of Hubzilla-level nomadic identity having been implemented in non-nomadic, ActivityPub-only, login-equals-identity Fediverse software after the fact. And there won't be any for quite a while.

@Jakub Urbanowicz Forte literally is (streams) without Nomad and Zot6.

I was there when Mike created Forte. I saw why Mike created Forte. I felt the consequences of why Mike created Forte. And I was one of Mike's contacts.

Ca. 2023

Mike got into contact with silverpill who wanted to make Mitra every bit as nomadic as Hubzilla and (streams), but only using ActivityPub. Both figured out that this was actually doable, as in, that even something like (streams) could one day be re-based on ActivityPub.

Mike started dreaming of a nomadic Fediverse in which everything could be cloned to everything.

He created a "nomadic" branch of the streams repository for research and development purposes.

Around early 2024

One key element for nomadic identity via ActivityPub was to have server-independent, decentralised Fediverse identities. These, however, would have to be up front. Thus, FEP-ef61 "Portable Objects" was created.

Both Mike and silverpill started implementing it; Mike did so in already nomadic software, namely the "nomadic" branch of the streams repository.

Channels created on accounts that were registered before (streams) supported FEP-ef61 would continue to use the old IDs internally, but decentralised IDs outward.

June, 2024

Mike was confident enough in the "nomadic" branch which worked reasonably well from his perspective. So he merged the "nomadic" branch into the normal "dev" branch.

July, 2024

I created a new (streams) account with two channels.

Shortly after, Mike merged the "dev" branch into the "release" branch. This caused decentralised IDs as per FEP-ef61 to be rolled out to production servers.

But what had worked under controlled lab conditions completely blew up in the real world: (streams) channels on accounts that were registered before FEP-ef61 did not properly federate with anything anymore, mine included. Content wasn't delivered anywhere anymore, not even within (streams). Mike had no idea at first what had happened.

August, 2024

Mike had figured out that (streams) had to juggle so many different IDs that it had started confusing them. He had to sort out the mess.

Mid-August, 2024

Mike announced the creation of Forte in a restricted message to his contacts. He had basically taken (streams) and ripped out any and all Nomad and Zot6 support to get at least some IDs out of the way so he could fix the bug.

Nonetheless, Forte was fully nomadic at this point.

The other reason why Mike had created Forte was because he had learned that it was foolish in today's Mastodon-dominated Fediverse to deprive (streams) of a name, a brand identity, an actual license and nodeinfo code. The latter had made it next to impossible to find (streams) servers.

Late August, 2024

(streams) had started working again. Everyone was relieved.

But Mike was burned out. In another restricted message to his contacts, he announced his retirement from Fediverse software development, effective August 31st, 2024. (streams) and Forte were up for grabs.

September, 2024

Nobody was found who could continue. Waitman Gobble said he'd like to, and he could, but he had no time. Bill Statler said he'd like to, and he had the time, but he didn't know how to code.

So Mike had to carry on, but at a slower pace.

Mid-September 2024

Mike officially announced the existence of Forte in public as opposed to only to his bubble. He would not have done that if Forte hadn't been fully nomadic.

From what I've read, limitations of ActivityPub kept Forte from real-time syncing, so a timer had to be used to trigger the syncing.

April, 2025

Mike publicly announced the first stable relase of Forte. Apparently, at this point, Forte was capable of real-time syncing, i.e. of syncs being triggered by changes in the channel rather than by a timer.

The only limitations now was that it wasn't possible to move or sync between Forte and something else due to how different other nomadic Fediverse software is, and that Forte didn't have an ActivityPub switch as a last-resort anti-Mastodon drawbridge anymore.

@Alfred Bühler I guess ?verb == Question should do the trick, too.

Question is correct according to the W3C ActivityStreams vocabulary (the stuff that I stash away...).

Forte doesn't even support the Nomad protocol or any protocol other than ActivityPub.

Basically, Forte is (streams) without Nomad and Zot6 support and a few other minor differences which elude me right now.

(streams) is Hubzilla

• with easier permission handling
• with four channel types for groups that partially provide features absent from Hubzilla (moderated posts for certain members, permitting vs not permitting members to upload content to the group channel)
• with better comment control
• with OCAP override permanently on
• with an even higher character limit
• with Markdown and HTML available for formatting messages
• with summaries in comments that actually work as Mastodon CWs
• with multiple profiles per channel
• able to verify external identities
• with easier alt-text support (alt-text field in the Photo app)
• able to block entire servers at channel level
• able to block entire server applications (e.g. Threads, Mastodon) at admin level
• with ActivityPub built into the core and on by default
• understanding decentralised identities as per FEP-ef61
• optionally able to receive entire conversations around comments made by contacts

but

• without diaspora* support
• without an RSS/Atom aggregator
• without crossposters to Dreamwidth, Libertree, LiveJournal and WordPress
• without articles
• without planning cards
• without wikis
• without webpages
• without OpenStreetMap support
• without a QR code generator
• without support for the CalDAV calendar in the event calendar frontend
• without modern third-party themes like AdminLTE or Solidified (for now)

(@Everyone: Can you please refrain from repeating my forum comments to your Mastodon followers? I'm commenting here without safeguards.)

Here's one option:

First go through your existing contact roles and manually grant permission to send you posts in each one of them. Disregard that this permission is inherited from the channel role. Soon it will no longer be, and we don't want there to be any disruption, right?

Next, change your channel role to Custom if you haven't already done that. Adjust your channel role as required.

But, and here comes the important part: Grant permission to send you posts only to those whom you explicitly allow.

Next step: Make at least one new contact role that matches whatever contact role the spammers have. This time, however, don't grant them permission to send you posts.

Finally: Assign this new contact role to the spammers.

Enjoy the silence. They can still send you DMs, you still receive their comments in both your own and other people's conversations, but they can no longer bomb you with posts.

If it's only repeats (boosts) that they spam you with, it's easier:

Activate the option to have filters per contact.

Then go to everyone who spams you with repeats and add the following to the blacklist:
?verb == Announce

This keeps repeats from these contacts out.

@Der Pepe (Hubzilla) ⁂ It reminds me of those Mastodon users who have been wishing for "the Fediverse" to finally introduce certain very desirable features since 2022. And these features have been available in the Fediverse since 2015 or 2012 or 2010.

On the other hand, thousands upon thousands of Mastodon users would have rioted, had they known that the Fediverse has had quote-posts since 2010.

@Ferret Bonfire is Hubzilla ordered from wish.com.

The only ones who are utterly impressed about Bonfire are those who don't know Hubzilla.

Those who have been daily-driving Hubzilla since the 2010s can only laugh about how pathetic Bonfire really is.

Bonfire promises a lot. But most of what Bonfire promises is only a promise and has yet to be implemented. Most of what is implemented appears to be barely functional.

At the same time, just about all of it is readily available as rock-solid stable features on Hubzilla. Right. Now. It usually has been since Hubzilla was launched, ten months before Mastodon was launched. Even Mistpark had some of it as early as May, 2010.

But Bonfire's propaganda claims that Bonfire is a pioneering software that's the first to invent all of this from scratch and the first to bring any of this into the Fediverse. And thousands of Mastodon users believe them because they don't know any better.

@Der Pepe (Hubzilla) ⁂ has actually tried Bonfire. I guess he can tell you a lot about his first-hand experiences. Or lack thereof.

@Mario Vavti Come to think of it, (streams) and Forte don't even have Superblock anymore. You can block anyone with the "white triangle" menu. You can also block anyone's server with the "white triangle" menu.

For some reason, though, (streams) and Forte don't have ignoring anymore either. I guess "blocking" does what ignoring does on Hubzilla, and Mike must have thought that blocking non-contacts from receiving your content on your side makes little sense.

On a sidenote, although this probably isn't related: Mastodon servers (and servers running Mastodon forks like Glitch) cause another side-effect whenever they upgrade to 4.7.x Alpha.

Let's suppose someone on Mastodon (or Glitch or whatever fork) has followed you in the past. You had to make it a full contact so they were allowed to follow you, and their follow request was flagged as confirmed on their side.

However, you didn't really want to follow them. You didn't want them to clutter your stream with their uninteresting cruft. Instead of just not granting them permission to send you their stuff, you deleted the contact. From a Mastodon POV, this meant you unfollowed them, but you did not make them unfollow you. Hubzilla itself has a page with no link in the UI that lists your following contacts, and they remain there as well.

Interestingly, if they unfollow you, they still remain on the following contacts list.

Anyway, whenever a Mastodon server or a Mastodon fork server upgrades to 4.7 Alpha, and you have "following contacts" on that server that used to be full contacts (regardless of whether or not they actually still follow you), they all appear as new connection requests.

This has happened to me with "following contacts" on infosec.exchange (Glitch) when it upgraded. This has happened to me with "following contacts" on mastodon.online (vanilla) when it upgraded. This has happened to me with a few more servers when they upgraded.

Mind you, at least most of them didn't even actually follow me anymore. I've checked their following lists whenever I could, and I was not listed there.

@Harald Eilertsen It's Glitch-soc, a soft fork of Mastodon with the goal of adding features to "the Fediverse" which the Fediverse outside of Mastodon has had for ages.

More specifically, infosec.exchange is running Glitch-soc based on the Mastodon 4.7.0 Alpha development version.

Glitch has been known to act up in combination with Mastodon, but not in this way. It'd be interesting to know if the same things happen in interactions with mastodon.online which is running vanilla Mastodon 4.7.0 Alpha.

Infosec.exchange is a Glitch server running a 4.7.1.something dev version that appears to be acting up in federation with Hubzilla a whole lot lately.

Either Mastodon 4.7 dev is breaking cross-application federation, or Glitch is doing so by bolting out-of-whack stuff onto Mastodon 4.7 dev.