Notes on the implementation of Data Portability in #tootik
https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability
fep_ef61
#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 232d 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).
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.