#fep_ef61

The biggest problem for peer to peer ActivityPub is the fact that ActivityPub is primarily a "pull" protocol. You need to fetch a remote actor before interacting with it. This is not feasible in the environment where nodes are intermittently online. What if we used a special activity to request objects? I've described this idea in more detail in Asynchronous object retrieval: https://codeberg.org/silverpill/feps/src/branch/main/aef6/fep-aef6.md I think this mechanism, if combined with self-authenticating objects, should make ActivityPub compatible with store and forward protocols. #p2p #dtn #fep_ef61

Proposal: Replace gateways query parameter in 'ap' URIs with @gateway, which can be used multiple times https://codeberg.org/fediverse/fep/pulls/890 Before: ?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example After: ?@gateway=https%3A%2F%2Fserver1.example&@gateway=https%3A%2F%2Fserver2.example Query parameters are often used to specify collection filters. The @ prefix will make it clear that gateway parameter is special. #fep_ef61

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

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@hollo.social whose maintainers decided to use the ap+ef61 scheme until the specification is finalized. #fep_ef61 #nomadicidentity

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-ef61 now recommends semantic routing (FEP-ae49) for gateways: https://codeberg.org/fediverse/fep/pulls/840 #fep_ef61

@@reiver@mastodon.social @@silverpill@mitra.social 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

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

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