#fep_ef61 — Public Fediverse posts on home.social

silverpill @[email protected] · 2026-07-12 · 06:44 UTC

Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883

I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.

No, there are 3 options:

- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.

Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-07-12 · 06:44 UTC

Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883

I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.

No, there are 3 options:

- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.

Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-07-12 · 06:44 UTC

Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883

I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.

No, there are 3 options:

- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.

Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-07-12 · 06:44 UTC

Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883

I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.

No, there are 3 options:

- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.

Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-06-29 · 19:45 UTC

Regarding the validity of at:// URIs in atproto:

https://bnewbold.leaflet.pub/3mph4hzvbdc2v

We have a similar problem with FEP-ef61 'ap' URIs. In their canonical form, they are not valid RFC-3986 URIs.

I think if atproto devs decide to move away from ://did:.. syntax, we'll have to do that as well.

#fep_ef61

silverpill @[email protected] · 2026-06-29 · 19:45 UTC

Regarding the validity of at:// URIs in atproto:

https://bnewbold.leaflet.pub/3mph4hzvbdc2v

We have a similar problem with FEP-ef61 'ap' URIs. In their canonical form, they are not valid RFC-3986 URIs.

I think if atproto devs decide to move away from ://did:.. syntax, we'll have to do that as well.

#fep_ef61

silverpill @[email protected] · 2026-06-28 · 11:48 UTC

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

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-06-28 · 11:48 UTC

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

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-06-28 · 11:48 UTC

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

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2026-06-28 · 11:48 UTC

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

#nomadicidentity #fep_ef61

Jupiter Rowland @[email protected] · 2026-06-21 · 13:29 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #fediverse

Jupiter Rowland @[email protected] · 2026-06-21 · 13:29 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #fediverse

Jupiter Rowland @[email protected] · 2026-06-21 · 13:29 UTC

@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

#red #long #mitra #forte #cwlong #fep_ef61

silverpill @[email protected] · 2026-05-02 · 17:00 UTC

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

#p2p #fep_ef61

silverpill @[email protected] · 2026-05-02 · 17:00 UTC

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

#p2p #fep_ef61

silverpill @[email protected] · 2026-04-25 · 17:54 UTC

FEP-ef61 now recommends semantic routing (FEP-ae49) for gateways: https://codeberg.org/fediverse/fep/pulls/840

#fep_ef61

silverpill @[email protected] · 2026-04-25 · 17:54 UTC

FEP-ef61 now recommends semantic routing (FEP-ae49) for gateways: https://codeberg.org/fediverse/fep/pulls/840

#fep_ef61

Jupiter Rowland @[email protected] · 2026-04-20 · 17:32 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-04-20 · 17:32 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-04-20 · 17:32 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-04-20 · 17:32 UTC

@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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-03-14 · 22:37 UTC

@@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

#cwfediversemeta #fediversemeta #cwlongpost #cwfedimeta #streams #longpost

Jupiter Rowland @[email protected] · 2026-03-14 · 22:37 UTC

@@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

#cwfediversemeta #fediversemeta #cwlongpost #cwfedimeta #streams #longpost

silverpill @[email protected] · 2026-03-08 · 21:18 UTC

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

silverpill @[email protected] · 2026-03-08 · 21:18 UTC

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

Jupiter Rowland @[email protected] · 2026-02-27 · 12:21 UTC

@洪民憙 (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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-02-27 · 12:21 UTC

@洪民憙 (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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-02-27 · 12:21 UTC

@洪民憙 (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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #streams

Jupiter Rowland @[email protected] · 2026-02-06 · 11:02 UTC

@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

#nichtnurmastodon #cwfediversemeta #fediversemeta #cwlangerpost #cwlongpost #langerpost

silverpill @[email protected] · 2026-01-26 · 18:59 UTC

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

silverpill @[email protected] · 2026-01-26 · 18:59 UTC

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

Jupiter Rowland @[email protected] · 2025-12-19 · 08:49 UTC

@Strypey

That's a pretty major UX fail right there.

Any progress on finalising an FEP for using nomadic identity with AP?

I think it'll take more than that one FEP (FEP-ef61 Portable Objects) to do that. I expect @silverpill to whip up more FEPs in the on-going process of turning Mitra from something like most Fediverse software (non-nomadic, account equals identity) into something that's every bit as nomadic as Forte.

Thing is, Mitra still has a long way to go, also because it aims to have an implementation of nomadic identity that's entirely covered by FEPs. Forte has nomadic identity via ActivityPub, but that's technology adopted from Zot/Nomad that needed to be made to work first and foremost with no regards for FEPs.

Besides, the existence of FEPs doesn't matter as long as Mastodon refuses to adopt them. And Mastodon has already silently rejected client-side support for OpenWebAuth magic sign-on by refusing to merge an existing, ready-to-merge pull request that would have implemented it immediately.

This means we'll probably never even see Mastodon become capable of recognising nomadic channels. And I'm not talking about Mastodon going nomadic itself (which, by the way, would also give Mastodon the easy account moving that its users have been craving for for so long).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Mitra #Forte #NomadicIdentity #FEP_ef61

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #longpost

Jupiter Rowland @[email protected] · 2025-12-19 · 08:49 UTC

@Strypey

That's a pretty major UX fail right there.

Any progress on finalising an FEP for using nomadic identity with AP?

I think it'll take more than that one FEP (FEP-ef61 Portable Objects) to do that. I expect @silverpill to whip up more FEPs in the on-going process of turning Mitra from something like most Fediverse software (non-nomadic, account equals identity) into something that's every bit as nomadic as Forte.

Thing is, Mitra still has a long way to go, also because it aims to have an implementation of nomadic identity that's entirely covered by FEPs. Forte has nomadic identity via ActivityPub, but that's technology adopted from Zot/Nomad that needed to be made to work first and foremost with no regards for FEPs.

Besides, the existence of FEPs doesn't matter as long as Mastodon refuses to adopt them. And Mastodon has already silently rejected client-side support for OpenWebAuth magic sign-on by refusing to merge an existing, ready-to-merge pull request that would have implemented it immediately.

This means we'll probably never even see Mastodon become capable of recognising nomadic channels. And I'm not talking about Mastodon going nomadic itself (which, by the way, would also give Mastodon the easy account moving that its users have been craving for for so long).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Mitra #Forte #NomadicIdentity #FEP_ef61

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #longpost

silverpill @[email protected] · 2025-11-05 · 10:30 UTC

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

- Added a section explaining how to compare 'ap' URIs.
- Origin tuples are replaced with "cryptographic origins". The result is the same, but now we don't have to use port 0.
- Outboxes and FEP-ae97 are not required anymore. This means implementers can use a different activity synchronization mechanism.

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2025-11-05 · 10:30 UTC

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

- Added a section explaining how to compare 'ap' URIs.
- Origin tuples are replaced with "cryptographic origins". The result is the same, but now we don't have to use port 0.
- Outboxes and FEP-ae97 are not required anymore. This means implementers can use a different activity synchronization mechanism.

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

Jupiter Rowland @[email protected] · 2025-09-22 · 20:08 UTC

@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

#cwfediversemeta #fediversemeta #quotedshares #quotetweets #quoteboosts #permissions

Jupiter Rowland @[email protected] · 2025-09-22 · 20:08 UTC

@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

#cwfediversemeta #fediversemeta #quotedshares #quotetweets #quoteboosts #permissions

silverpill @[email protected] · 2025-09-17 · 23:39 UTC

FEP-ae97: Client-side activity signing has been updated: https://codeberg.org/fediverse/fep/pulls/682

I added a new section describing Media API after implementing it in Mitra v4.10.0.

The API is somewhat similar to Blossom API used by Nostr apps: media objects are identified by their SHA-256 digests, and can be mirrored to other gateways.

I also specified status codes for error responses.

#fep_ae97 #fep_ef61

#fep_ef61 #fep_ae97

silverpill @[email protected] · 2025-09-17 · 23:39 UTC

FEP-ae97: Client-side activity signing has been updated: https://codeberg.org/fediverse/fep/pulls/682

I added a new section describing Media API after implementing it in Mitra v4.10.0.

The API is somewhat similar to Blossom API used by Nostr apps: media objects are identified by their SHA-256 digests, and can be mirrored to other gateways.

I also specified status codes for error responses.

#fep_ae97 #fep_ef61

#fep_ef61 #fep_ae97

silverpill @[email protected] · 2025-09-12 · 23:49 UTC

Notes on the implementation of Data Portability in #tootik

https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability

#fep_ef61 #NomadicIdentity

#nomadicidentity #tootik #fep_ef61

silverpill @[email protected] · 2025-09-12 · 23:49 UTC

Notes on the implementation of Data Portability in #tootik

https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability

#fep_ef61 #NomadicIdentity

#nomadicidentity #tootik #fep_ef61

silverpill @[email protected] · 2025-08-24 · 19:14 UTC

#tootik implemented FEP-ef61

We have 3 independent implementations now:

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#status

@dimkr #fep_ef61 #NomadicIdentity

RE: https://hd.206267.xyz/post/0198d701-8bdd-71f2-bd56-9f381e18f15f

#nomadicidentity #tootik #fep_ef61

silverpill @[email protected] · 2025-08-24 · 19:14 UTC

#tootik implemented FEP-ef61

We have 3 independent implementations now:

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#status

@dimkr #fep_ef61 #NomadicIdentity

RE: https://hd.206267.xyz/post/0198d701-8bdd-71f2-bd56-9f381e18f15f

#nomadicidentity #tootik #fep_ef61

silverpill @[email protected] · 2025-08-20 · 17:52 UTC

I've made several changes to FEP-ef61: Portable Objects

https://codeberg.org/fediverse/fep/pulls/668

Section "Authentication and authorization" explains the differences between portable objects and non-portable objects (FEP-fe34):

- Cryptographic origins are used instead of RFC-6454 web origins.
- Portable objects can't be fetched from their origins.

Activities delivered to an inbox MUST NOT be forwarded more than once (to avoid infinite loop). Requirements related to outbox implementation has been clarified.

Gateways SHOULD implement FEP-ae97 actor registration process (previously it was MAY).

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2025-08-20 · 17:52 UTC

I've made several changes to FEP-ef61: Portable Objects

https://codeberg.org/fediverse/fep/pulls/668

Section "Authentication and authorization" explains the differences between portable objects and non-portable objects (FEP-fe34):

- Cryptographic origins are used instead of RFC-6454 web origins.
- Portable objects can't be fetched from their origins.

Activities delivered to an inbox MUST NOT be forwarded more than once (to avoid infinite loop). Requirements related to outbox implementation has been clarified.

Gateways SHOULD implement FEP-ae97 actor registration process (previously it was MAY).

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61

Jupiter Rowland @[email protected] · 2025-08-17 · 06:31 UTC

@Ben Pate 🤘🏻

I've looked through FEP-ef61 in the past, and will give it another go. I think I struggled to see how this would be compatible with Mastodon, or other servers without them requiring a pretty big rewrite to support portable objects.

It won't. Especially not with Mastodon.

At the very least, they would have to start to understand portable objects and the concept of nomadic identity, e.g. that [email protected] and [email protected] may be on two different accounts, but the exact same channel with the exact same identity, the exact same connections, the exact same content etc.

Mastodon has been flipping the bird both at the ActivityPub standard and at FEPs and at the whole rest of the Fediverse since it was made. Eugen Rochko has been trying to EEE the Fediverse since he created Mastodon, the very same thing that people on Mastodon feared that Threads would do. The only time he ever makes compromises is when he is put under pressure by even more powerful players like Automattic or Flipboard, and even then he only throws them tiny bones.

As @Mike Macgirvin ?️ gradually built his nomadic and ActivityPub-based Forte from his own nomadic and Nomad-based streams repository (itself a Hubzilla descendant), and as @silverpill started making his non-nomadic and ActivityPub-based Mitra nomadic, their goal was to expand ActivityPub into something that supports nomadic identity via FEPs and, at the same time, make their own software compatible to these FEPs.

Their goal was not to make their software and these FEPs fully compatible with the Fediverse as it was in 2023/2024 and especially not to build them against Mastodon as it was in 2023/2024 or as it is now.

Especially Mike would never build anything explicitly against Mastodon. Rather, he'd make it possible to block Mastodon from an entire (streams) or Forte server, and he did. To Mike, Mastodon is not the heart and the core and the centre of the Fediverse around everything else orbits and justifiedly so. He rather sees it as a nuisance.

Seriously, nothing that Mike has created will ever be fully compatible with Mastodon, not as long as Mastodon's politics don't change greatly. I mean, client-side support for Mike's own OpenWebAuth magic sign-on was proposed for Mastodon. It went as far as an actual merge request in 2023. They core devs never even looked at that merge request, much less merged it. They silently rejected it.

@Contraquestão

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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #fediverse

Jupiter Rowland @[email protected] · 2025-08-17 · 06:31 UTC

@Ben Pate 🤘🏻

I've looked through FEP-ef61 in the past, and will give it another go. I think I struggled to see how this would be compatible with Mastodon, or other servers without them requiring a pretty big rewrite to support portable objects.

It won't. Especially not with Mastodon.

At the very least, they would have to start to understand portable objects and the concept of nomadic identity, e.g. that [email protected] and [email protected] may be on two different accounts, but the exact same channel with the exact same identity, the exact same connections, the exact same content etc.

Mastodon has been flipping the bird both at the ActivityPub standard and at FEPs and at the whole rest of the Fediverse since it was made. Eugen Rochko has been trying to EEE the Fediverse since he created Mastodon, the very same thing that people on Mastodon feared that Threads would do. The only time he ever makes compromises is when he is put under pressure by even more powerful players like Automattic or Flipboard, and even then he only throws them tiny bones.

As @Mike Macgirvin ?️ gradually built his nomadic and ActivityPub-based Forte from his own nomadic and Nomad-based streams repository (itself a Hubzilla descendant), and as @silverpill started making his non-nomadic and ActivityPub-based Mitra nomadic, their goal was to expand ActivityPub into something that supports nomadic identity via FEPs and, at the same time, make their own software compatible to these FEPs.

Their goal was not to make their software and these FEPs fully compatible with the Fediverse as it was in 2023/2024 and especially not to build them against Mastodon as it was in 2023/2024 or as it is now.

Especially Mike would never build anything explicitly against Mastodon. Rather, he'd make it possible to block Mastodon from an entire (streams) or Forte server, and he did. To Mike, Mastodon is not the heart and the core and the centre of the Fediverse around everything else orbits and justifiedly so. He rather sees it as a nuisance.

Seriously, nothing that Mike has created will ever be fully compatible with Mastodon, not as long as Mastodon's politics don't change greatly. I mean, client-side support for Mike's own OpenWebAuth magic sign-on was proposed for Mastodon. It went as far as an actual merge request in 2023. They core devs never even looked at that merge request, much less merged it. They silently rejected it.

@Contraquestão

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

#cwfediversemeta #nomadicidentity #fediversemeta #cwlongpost #cwfedimeta #fediverse

silverpill @[email protected] · 2025-06-30 · 19:53 UTC

Added Nomadic ActivityPub page to the ap-next repository:

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md

This is a brief summary of the work we've done. Feedback is welcome!

#NomadicIdentity #fep_ef61

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2025-06-30 · 19:53 UTC

Added Nomadic ActivityPub page to the ap-next repository:

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md

This is a brief summary of the work we've done. Feedback is welcome!

#NomadicIdentity #fep_ef61

#nomadicidentity #fep_ef61

silverpill @[email protected] · 2025-03-19 · 14:21 UTC

FEP-ef61 "Portable Objects" update:

https://codeberg.org/fediverse/fep/pulls/529

The role of decentralized identifiers in FEP-ef61 is similar to "servers" in vanilla ActivityPub: they control all actors within a certain namespace.
When multiple actors exist under DID's authority, they will likely use same gateways. I added a sentence saying that gateways can be advertised via DID document as DID services (an example of that can be found in did:fedi spec). This is not possible with did:key, but might be useful with other DID methods.
I am also considering moving gateways property to actor's endpoints mapping, where server-wide endpoints such as sharedInbox are usually defined (in our case they are "DID-wide").

#fep_ef61 #NomadicIdentity

#nomadicidentity #fep_ef61