Notes on the implementation of Data Portability in #tootik
https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability
fep_ef61
FEP-ef61 now recommends semantic routing (FEP-ae49) for gateways: https://codeberg.org/fediverse/fep/pulls/840
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).
#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
I updated "Authentication and authorization" section of FEP-ef61 (Portable objects): https://codeberg.org/fediverse/fep/pulls/497.
Authentication requirements in FEP-ef61 differ depending on the object class. Actors, activities and objects must always be signed (i.e. have an integrity proof). Signing collections may be impractical, so we make an exception for them, and trust the gateway if that gateway is trusted by actor. Links are not supposed to have an id, and there is no requirement to sign them.
This would not be possible without FEP-2277 which provides a classification of ActivityPub objects based on their shape.
FEP-2277 also got a small update. The algorithm now gives Link a higher priority: https://codeberg.org/fediverse/fep/pulls/496
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!
Edited 1y ago
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!
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).
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-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-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).
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.
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.
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