@Jupiter Rowland
Trouble is, things that are technically capable, are socially difficult to deploy.
Trouble is, things that are technically capable, are socially difficult to deploy.
Comment on Nomad-capable server for an NGO
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
(@Everyone: Can you please refrain from repeating my forum comments to your Mastodon followers? I'm commenting here without safeguards.)
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
- 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.)
kubaurbanowicz@zotum.net 1 day ago
pepecyb@hub.hubzilla.hu@hub.hubzilla.hu 20 hours ago
@Jupiter Rowland
I’ll throw in one more thought here about Forte’s nomadic identity: it’s theoretical!
Yes, it’s supposed to work. But I don’t know myself whether it actually does. Even though I run a Forte Hub myself.
Why?
Because there are probably very few Forte Hubs; you simply can’t find them (in any of the usual Fediverse databases). Because you can search for them (if you know where and how, you might even find a few, but virtually none where registration is open).
So, with my Forte channel on my own Forte Hub (which, incidentally, is open for registrations), I have a nomadic channel, but simply no account where I could clone it (even just to test it out).
For me, therefore, the nomadic identity is purely theoretical.- @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. - @Der Pepe (Hubzilla) ⁂
bluenomad@forte.hubzilla.net – is that you? I have found about a dozen streams/forte instances using Google search including https://forte.hubzilla.net
I remote-logged on them and read some posts. The post on installing Forte from Yunohost was quite interesting to me, because that's what I was planning to do.
On thing threw me: after remote login you are presented with a list of applications. Strange.lotfi@hub.volse.no 19 hours ago
@Jakub UrbanowiczThe post on installing Forte from Yunohost was quite interesting to me
In this regard, you can contact the maintainer of the Forte repository on Yunohost here: @Papa Dragon (now on Forte)- Yes, forte.hubzilla.net is my hub (open for registrations) and my channel there is called Blue Nomad.
On Fediverse Observer, you can actually find quite a few Forte hubs. But without the option to register, that doesn’t really help either.
I don’t use Google. But tell me, how (using which search term) did you search? Probably not just ‘Forte’, because you’re hardly likely to spot the hubs amongst all the medicines 😉😂.
My hub runs on YunoHost… and at the moment, the update frequency is going relatively well too.
- @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.
As far as I understand it, Forte should not be viewed as "(streams) without Nomad". It is better understood as an attempt to reimplement the capabilities of Nomad on top of ActivityPub, using a collection of emerging Fediverse Enhancement Proposals (FEPs) and a few project-specific mechanisms.
1. Nomadic identity
This is clearly the primary goal.
Historically:
The OpenNomad project explicitly states that the long-term objective is to bring technologies such as:
into the ActivityPub ecosystem rather than keeping them exclusive to the Nomad protocol.
2. FEP-ef61 (Portable Objects)
This appears to be one of the key building blocks.
The idea is simple:
Instead of identifying an actor solely by
the actor receives a portable identity based on a cryptographic identifier (conceptually similar to DID).
The URL becomes just one representation of that identity.
Isn't it exactly the direction Mike has wanted for many years?
FEP-ef61 is still a draft, but Forte is frequently mentioned in discussions around its implementation.
3. Object integrity proofs
Another major piece.
Nomad always relied heavily on cryptographic identity.
ActivityPub originally did not.
Several FEPs now introduce:
Without these, portable identities are difficult to secure.
4. Client-side signing
This is another important change.
Traditionally:
The proposed direction is:
That makes identity independent of the server.
Again, this is very much aligned with Nomad's philosophy.
5. OpenWebAuth
This one is already much more concrete.
OpenWebAuth (formerly Magic Sign-On) has now been documented as its own FEP.
It provides federated login between independent sites without relying on OAuth providers such as Google.
The specification explicitly mentions compatibility with Hubzilla, (streams), Forte and ActivityPub-based deployments.
6. Conversation containers
This one is interesting.
One weakness of ActivityPub is that conversations are reconstructed heuristically.
Nomad had a much richer conversation model.
There are now proposals for "conversation containers" intended to preserve discussion context much more reliably across servers.
These are still evolving.
7. Channel cloning
This is the part that is not yet solved.
Today:
Hubzilla can clone Hubzilla channels.
(streams) can clone (streams) channels.
But ActivityPub software generally cannot.
The Hubzilla documentation still explicitly says that AP contacts cannot participate fully in Nomad cloning because ActivityPub lacks the necessary concepts.
So this remains one of the major gaps.
8. Cross-platform nomadic identity
The "holy grail", IMHO.
The goal becomes:
with a single portable identity moving between all of them.
That is what several of the current FEP discussions are trying to enable.
So, the effort appears to be:
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.
I was hoping for more history up to the present…
So it feels like Forte is still not ready to serve as a work-horse in heavy-use scenarios.