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 195d ago
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.