Documentation
⚡️ Introduction
This project is still at concept stage and aims to brainstorm the intersection of micro services and the fediverse.
🎨 Design
Microfed follows a modular design approach, ensuring flexibility and maintainability. The high-level design focuses on the interaction between microservices and the fediverse.
The idea is that each component of a fediverse server can be composed from smaller services.
These include:
✍️ Profile
Your Profile page is the starting point for microfed services. It will generally be an HTTP page, but the data should be agnostic to HTTP or any other protocol so that it can live in a database, or run over a P2P network.
The Profile will be in HTML, with the data in in JSON(-LD). It will contain:
✓ The Profile page
✓ The User / Actor / Agent
✓ Attributes about the User
✓ Ability to store a public key
✓ A list of connections (friends, knows, followers etc.)
✓ Endpoint for Inbox
✓ Endpoint for Outbox
✓ Authentictation endpoints
✓ Arbitrary fields specified by the user
The Profile can be self-hosted, or part of a multi user service. It should be able to run on a mobile device, or in the browser.
📬 Inbox
The Inbox should be a place where people can send messages in JSON. The micro service can filter out messages based on user preferences. The message format should be as far as possible compatible with Activity Pub JSON. Signatures can be used to verify the authenticity of a message.
📤 Outbox
The Outbox is a service that allows messages to be sent to other inboxes. It should also have to ability to store a private key on behalf of a user, in order to sign outgoing messages. It should be able to route messages to the right endpoints.
🔐 Authentication
Initially, strong authentication via PKI will be supported. Delegated authentication, such as OAuth and OIDC may be considered desirable. A loosely coupled authentication suite will allow the user to add different authentication modules. This could also work with enterprise authentication.
⚖️ License
- MIT