#fep_ae97 — Public Fediverse posts

FEP-ae97 update: https://codeberg.org/fediverse/fep/pulls/813

This update includes several minor changes and clarifications. Mitra Mini was added to the implementation list. I also added a sequence diagram for actor registration process:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md#registering-an-actor

#fep_ae97

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

I created a simple FEP-ae97 web client:

https://codeberg.org/silverpill/fep-ae97-web-client

It is written in #Rust using Leptos and APx. Everything is compiled to WebAssembly and the application can be served as a static website.

This technology stack is very promising, but I think it is not yet ready for anything serious. The development process is slower compared to JavaScript/TypeScript, and the resulting binary is huge - it's 4.5 MB already (without optimizations). So I am going to keep an eye on it, but focus on building another FEP-ae97 client using a different approach.

#fep_ae97

FEP-ae97 update: https://codeberg.org/fediverse/fep/pulls/691

- GET /.well-known/apgateway endpoint for discovering whether the server supports FEP-ae97 clients or not.
- DELETE /.well-known/apgateway-media/{hashlink} endpoint for deleting media.

#fep_ae97

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

Starting with version 4.5.0, Mitra expands collections when it distributes activities submitted to FEP-ae97 outboxes. That means portable actors like @nomad can create public posts, and they will be delivered to all their followers.

#fep_ae97

RE: https://mitra.social/objects/019784da-f56f-c1ee-b0f5-79f2dd9cb5de

Published the code of my tiny FEP-ae97 server:

https://codeberg.org/silverpill/fep-ae97-server

I used this project to test some ideas before implementing them in Mitra, so it is unlikely to be developed into a finished product. But maybe someone will find the code interesting.

The server is built using apx_sdk and is compatible with fep-ae97-client.

#fep_ae97

An update to C2S authentication mechanism in FEP-ae97:

https://codeberg.org/fediverse/fep/pulls/618/files

Signing requests with a DID is easy, but it doesn't work for access control, because for that we need to know the exact actor (same-origin policy can't be used for access control because proxyUrl ActivityPub endpoint allows making requests with server's authority).
Therefore we need to add a verification method to the actor object, but it is important to use plain ap URIs for its id. If a client controls a key with the server's origin, it can impersonate other actors on that server (in origin-based security model).

fep-ae97-client was updated to sign requests with actor's key.

#fep_ae97

FEP-ae97 security audit: https://codeberg.org/fediverse/fep/pulls/595

I added a new section, "Security considerations", and a new requirement: compatible identifiers of server-generated keys MUST have the server's origin. Here's how that looks in practice:

https://mitra.social/.well-known/apgateway/did:key:z6MknVmyPtQmD2SaGnqyGgTVEqfqkkJJnY3YVKBmbzSUNCcX/actor

This FEP update goes together with two others:

- FEP-2277: ActivityPub core types - The VerificationMethod class has the highest priority now, because servers must be able to identify a verification method even if it has other class-defining properties (e.g. href).
- FEP-fe34: Origin-based security model - clarifying the base assumptions of the model

#fep_ae97

I did a thorough security review of my FEP-ae97 implementation, and hardened the server side to prevent potential impersonation of other actors on the same server by malicious clients.

As of version 4.2.1, everything is working again, including cloned accounts (latest fep-ae97-client is required).

#fep_ae97

Following the FEP-fe34 update, I am publishing a new version of FEP-ae97: Client-side activity signing

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

The registration process is completely different now. Keys for signing S2S requests are generated on the server and only public parts are shared with the client.

When FEP-ae97 client retrieves activities from the inbox, it signs GET requests with a key associated with actor's DID authority.

For example, this actor:

ap://did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK/actor"

Will generate an HTTP signature with this keyId parameter:

keyId="did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"

Implementations have been updated too (Nomadic AP Client and Mitra).

#fep_ae97

did:dns might be a good choice for FEP-ae97 clients.
It supports key rotation, but a web service is not required, so people don't need to deploy anything to create an identity. Just generate a secret key in your client, add a resource record to your domain and start posting.

#fep_ef61 #fep_ae97