FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872

The ap+ef61 URI scheme is now allowed, while ap remains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use the ap+ef61 scheme until the specification is finalized.

#fep_ef61 #nomadicidentity

FEP-ef61: Update proposal

- Allowed `ap+ef61` URI scheme. - Clarified the relationship between `verificationMethod` and object's identifier. - Added FEP-9f9f to references. - Added a warning about HTTP origins. - Removed "Compatibility" sub-section from "Discussion". - Fixed typos.

Codeberg.org
@InnocentZero FEP-ef61 all by itself isn't a magical solution. It's just one element in implementing full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) via ActivityPub, but it's far from being the only one.

See, nomadic identity wasn't invented just a few years ago or so, and it wasn't invented for, on and with ActivityPub either. It was first introduced in Fediverse software that works vastly, vastly different from Mastodon and from most of the rest of the Fediverse. I'm daily-driving what became of this software.

The beginning of nomadic identity: the Zot protocol, Red and Hubzilla


Nomadic identity was invented in 2011 by @Mike Macgirvin who had made Friendica (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica, https://joinfediverse.wiki/Friendica) as early as 2010. (Friendica is the oldest still existing Fediverse software, by the way.)

To put this into perspective: The concept of nomadic identity is over four years older than Mastodon. And it predates the first ActivityPub implementation by some six years. (Ironically, the software that first implemented ActivityPub is essentially the same software that first implemented nomadic identity.)

One issue that plagued Friendica is an issue that plagues everything decentralised: Servers shut down out of the blue, and users lose everything. That's why Mike had the idea to make identities not only portable (as in, easy to move from one server to another), but nomadic (as in, absolutely identical clones of the same identity exist on multiple independent servers at the same time, so if one server shuts down, you lose nothing).

Still in 2011, Mike designed a wholly new federated protocol named Zot to implement nomadic identity. Mind you, he had already designed a brand-new protocol from scratch for Friendica.

In 2012, Mike took his own Red, a development-grade fork of his own official development fork of Friendica. He pretty much ripped the whole backend out and also most of the frontend, and he basically developed an entirely new server application, now built against Zot. This was necessary because Red would have to handle identities completely differently from Friendica in order to make them nomadic.

See, Friendica handles identities just like Mastodon and almost the entire rest of the Fediverse: Your identity is your account, your login. You have one identity per login, you have one identity per server. All your data, all your stuff is stored directly in your account.

But you can't clone accounts. It's way too tedious to separate the stuff that must be cloned (contacts, messages, settings etc.) from the stuff that mustn't be cloned (login credentials).

So Mike created the concept of "channels" (https://joinfediverse.wiki/Channels_(Hubzilla_%26_(streams))). They're basically containers for your identity that contain everything except the login credentials on the servers. They can easily be cloned and moved as a whole.

Red still exists in a way: Later the same year, it was renamed the Red Matrix. And in 2015, it was completely refactored, it was greatly expanded in features and functionality, and it was renamed Hubzilla (https://hubzilla.org, https://en.wikipedia.org/wiki/Hubzilla, https://joinfediverse.wiki/Hubzilla). Hubzilla is where I'm commenting from right now, and this channel has been cloned for longer than most Mastodon users have known that Mastodon exists.

Nomadic identity via only ActivityPub: (streams), Mitra and forte


FEP-ef61 was created by @silverpill, developer of Mitra (https://codeberg.org/silverpill/mitra) in 2023. The goal was to take non-nomadic, account-equals-identity Mitra and make it every bit as nomadic as Hubzilla. Not by rewriting the entire backend against Zot (or its newest version known as Nomad) and then bolting ActivityPub support back on, but by using nothing but ActivityPub itself without rewriting the backend.

Development and sparrings partner became Mike Macgirvin himself who, at that time, was working on the streams repository (https://joinfediverse.wiki/(streams), https://codeberg.org/streams/streams), a Nomad-based fork of a fork of three forks of a fork (of a fork) of Hubzilla, somewhat slimmed down in features (it isn't a full-blown, jack-of-all-trades CMS unlike Hubzilla), but every bit as nomadic as Hubzilla.

The two worked out a way of using ActivityPub and only ActivityPub to establish nomadic identity. Not only to made Fediverse identifiers independent from servers, but to actually use ActivityPub to clone identities with everything attached to them between servers.

Eventually, FEP-ef61 was defined, and (streams) and Mitra became the first Fediverse server applications to understand portable identities as per FEP-ef61. (streams) was the first nomadic Fediverse server application to understand them, but it still uses its native Nomad protocol for its own nomadicity. Mitra, all by itself, still isn't nomadic to this day; it uses a client named Minimitra for nomadicity.

The first Fediverse server application that actually uses only ActivityPub for nomadicity, all the way to cloning and syncing channels, is Forte (https://codeberg.org/fortified/forte). It came to exist in mid-August 2024, essentially as a byproduct of an accident. (streams) had to juggle so many identities already, ActivityPub identities, Nomad identities, Zot6 identities, that when FEP-ef61 was merged into its release branch, it confused all these identities and didn't connect or federate with anything anymore. In order to find and fix the issue, Mike Macgirvin himself forked his own streams repository and ripped out any and all support for protocols that weren't ActivityPub. This required Forte to use ActivityPub for everything that (streams) used Nomad for.

Where we are now


So as of now, there are exactly three still existing server applications with full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity: Zot-based Hubzilla from 2012/2015, Nomad-based (streams) from 2021 and ActivityPub-based Forte from 2024.

There is only one of this kind that uses ActivityPub for everything, including nomadicity, and that's Forte.

Forte is the youngest member of the same software family as Hubzilla and (streams). They were all created by the same developer, and they were all born nomadic.

There is no case of a typical, classic, non-nomadic, account-equals-identity, ActivityPub-based Fediverse server application that was successfully converted to full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity. Forte itself wasn't converted from non-nomadic to nomadic; it was converted from Nomad-based to ActivityPub-based while having a nomadic legacy that dated back a dozen years at that point.

I'm not saying that it's impossible to turn non-nomadic software into fully nomadic software. But it's a huge undertaking that will require rewriting large parts of the server backend.

Essentially: You can't just add FEP-ef61 support to Mastodon and immediately clone your account over to other servers the same way that I can clone my Hubzilla channel.

CC: @Rob Ricci @Christine Lemmer-Webber

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Red #RedMatrix #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity
Nomadic identity - Join the Fediverse

Fediverse & P2P

Nomadic identity is a nice feature, but FEP-ef61: Portable Objects is not limited to that. The intention was always to allow peer to peer communication without servers. This is why the protocol was designed to be transport-agnostic: you can use fediverse servers to deliver activities, but you can also use emails, torrents or USB sticks.

To explore these possibilities, I added a simple P2P synchronization mode to Mitra Mini, which allows clients to exchange activities via a shared directory. This doesn't mean that clients should run on the same machine. Syncthing is a tool for P2P file synchronization that can be used to share a directory between multiple machines, and it should work well for our use case.

The P2P mode is available in Mitra Mini v0.4.0. You can use a pre-compiled binary, which is now self-contained and includes the mitra-web frontend. See installation instructions in the readme. To enable P2P mode, add the following block to your configuration file:

[federation] p2p_shared_outbox = "/path/to/shared/directory"

Registering on a web gateway is not necessary when working in P2P mode, but you need to specify it in the config, because a lot of legacy code still depends on that.

If you'd like to connect, DM me your Syncthing device ID (it can be used in a Whonix VM to prevent IP address leaks).

#fep_ef61 #p2p

fep/fep/ae49/fep-ae49.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org
@ValorZard No dice.

First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.

I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.

Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.

Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.

Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.

It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.

The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.

I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.

Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.

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

@@reiver ⊼ (Charles) :batman: @silverpill This is simply because little is written about Forte on the Web.

However, I was there when Forte was born back in September, 2024. I was on (streams) back then. Mike Macgirvin had implemented FEP-ef61 in the "nomad" branch of the streams repository a few months ago to test it. When he was confident enough, he merged the "nomad" branch into the regular "dev" branch. In July, 2024, he merged the "dev" branch into the "release" branch, causing the FEP-ef61 implementation to be rolled out to daily-driver (streams) servers.

However, it was a maze of Nomad and Zot6 and non-nomadic ActivityPub and FEP-ef61 identities for everything that boiled over. (streams) wouldn't federate with anything anymore, not even with itself. My two still existing (streams) channels, @Jupiter Rowland's (streams) outlet and @Jupiter's Fedi-Memes on (streams), were both affected by this. They were amongst the very first (streams) channels created on an account with FEP-ef61 DID support.

Mike would spend half of the summer trying to figure out what had happened and how to fix it. Even while (streams) was still broken, Forte was born in August, 2024 when Mike forked the streams repository and ripped all traces of Nomad and Zot6 support out, probably also in order to get rid of the corresponding IDs and facilitate debugging.

This means that FEP-ef61, which had literally caused this whole mayhem and which has to be considered responsible for Forte's very existence, was a) implemented in the streams repository when it was forked into Forte and b) not removed from Forte post-fork. It would not have made any sense to remove FEP-ef61 when one reason why Forte was made at that point in history was in order to debug FEP-ef61.

Sidenotes: Mike managed to fix (streams). This whole issue burned him out so much that he officially quit developing Fediverse software, effective September 1st, 2024, midnight. He still carries on working on both (streams) and Forte because nobody else does, what with how many people even use them.

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

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/773

Gateways can now remove integrity proofs from collections when they generate collection views. This enables filtering and pagination and is compatible with client-side signing (FEP-ae97).

#fep_ef61

FEP-ef61: Collections

- Dynamic collections are supported. - Clarify when unsecured collections can be trusted. - Do not require to return 404 Not Found on authorization failure.

Codeberg.org
@洪 民憙 (Hong Minhee) :nonbinary: Two people you may consider consulting in this case:
  • @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
    His streams repository, a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, is the place where he laid the foundations of FEP-ef61 out of necessity because he was working on nomadic identity via ActivityPub (Hubzilla and (streams) use their own protocols for that), and it was the first nomadic server software that had it implemented.
    Also, his Forte, itself a fork of the streams repository, is the only Fediverse server software that uses nothing but ActivityPub to establish nomadic identity and relies on FEP-ef61 to do that. Basically, it's (streams) with no Nomad and Zot6 support, and syncing between clones is triggered by a cronjob because, unlike Zot6 and Nomad, ActivityPub doesn't provide any ways to trigger immediate, near-real-time syncs.
    Mike hasn't been caught online for quite a while, though, although he's still working on both (streams) and Forte.
  • @silverpill is gradually turning Mitra from a typical non-nomadic, account/login-equals-identity, one-identity-per-account Fediverse software into something that's every bit as nomadic as Hubzilla, (streams) and Forte while casting everything necessary for this process into FEPs.
    I'm not sure whether this will include containerising identities like the channels on Hubzilla, (streams) and Forte and allowing multiple fully independent identities on the same account, just like the same identity (channel) would be able to exist on independent accounts on different servers.

That said, is your goal only to use FEP-ef61 for identities that are tied to their accounts and their servers? Or is your goal fully-fledged nomadic identity on the same level as on Forte?

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

@Marcus Rohrmoser 🌻 @Matthias @Lioh Das Problem ist, daß häufig der einzige Standard, an den sich Fediverse-Drittentwickler halten, Mastodon ist. Die bauen ihre Kreationen also nicht gegen als solche definierte Standards, sondern hart gegen Mastodon und nur gegen Mastodon. Vielfach wissen sie nicht mal, daß es außerhalb von Mastodon noch was anderes im Fediverse gibt.

So gehen sie dann felsenfest davon aus, daß jede Profil-URL im Fediverse so aussieht: https://server.tld/users/kurzname.

Und dann wundern sie sich, wenn sich Leute beschweren, daß ihre Kreation nicht mit $SERVERSOFTWARE funktioniert, von der sie noch nie etwas gehört haben.

Nur gibt's eben nicht nur Mastodon und Mastodon-Forks und Software, die gegen Mastodon gebaut wurde. Misskey ist älter als Mastodon, also sind Misskey und die Forkeys da anders aufgebaut. Friendica ist viel älter als Mastodon, also ist es wieder anders, ebenso seine Nachfahren.

A propos: Spätestens seit der Red Matrix, auf jeden Fall aber seit Hubzilla, wird unterschieden zwischen dem eigentlichen Kanal (mit dem Stream, wo man die Posts sieht, also z. B. https://hubzilla.org/channel/jupiter_rowland, und dem Profil, wo man die auch schon mal mehreren Dutzend Profilfelder sieht (wenn man das darf), aber keine Posts, also z. B. https://hubzilla.org/profile/jupiter_rowland. Der Kanal wird meines Wissens als Akteur erkannt, beim Profil bin ich mir nicht sicher.

Auf (streams) und Forte wird es noch wilder, weil die FEP-ef61 "Portable Objects" unterstützen und DIDs verwenden. Das war nötig, um nomadische Identität über ActivityPub zu unterstützen eine zukünftige nomadische Identität über mehrere Serveranwendungen hinweg vorzubereiten. Da gibt's dann

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NichtNurMastodon #Hubzilla #Streams #(streams) #Forte #FEP_ef61

I am working on a new project, called minimitra.

It's a FEP-ae97 client that implements Mastodon API. Minimitra is similar to Mitra, but it is designed to run as a desktop application and supports portable accounts. That means: offline-first, full identity/data ownership, Tor/I2P friendly.

Currently minimitra can only send and receive public messages, but I expect that porting features will not be difficult because most of the code will be shared.

Other limitations / downsides:

- Requires postgresql server.
- Can't post to multiple gateways.
- No cross-client portability.

Fortunately, all of that can be fixed!

#fep_ef61 #fep_ae97 #minimitra

minimitra

Headless ActivityPub client

Codeberg.org