Federation has it’s own base entity classes. When incoming messages are processed, the protocol specific entity mappers transform the messages into our base entities. In reverse, when creating outgoing payloads, outgoing protocol specific messages are constructed from the base entities.

Entity types are as follows below.

Protocol entities

Each protocol additionally has it’s own variants of the base entities, for example Diaspora entities in federation.entities.diaspora.entities. All the protocol specific entities subclass the base entities so you can safely work with for example DiasporaPost and use isinstance(obj, Post).

When creating incoming objects from messages, protocol specific entity classes are returned. This is to ensure protocol specific extra attributes or methods are passed back to the caller.

For sending messages out, either base or protocol specific entities can be passed to the outbound senders.

If you need the correct protocol specific entity class from the base entity, each protocol will define a get_outbound_entity function.

Federation identifiers

All entities have an id to guarantee them a unique name in the network. The format of the id depends on the protocol in question.

  • ActivityPub: maps to the object id (whether wrapped in an Activity or not)
  • Diaspora: maps to guid for the entity.


Profiles are uniquely identified by the id as above. Additionally for Diaspora they always have a handle. ActivityPub profiles can also have a handle but it is optional.

A handle will always be in email like format, without the @ prefix found on some platforms. This will be added to outgoing payloads where needed.

Creator and owner identifiers

All entities except Profile have an actor_id which tells who created this object or activity. The format depends on the protocol in question.

  • ActivityPub: maps to Object attributedTo or Activity actor_id.
  • Diaspora: maps to entity author

Activity identifiers

Entities which are an activity on something, for example creating, updating, deleting, following, etc, should have an activity_id given to be able to send out to the ActivityPub protocol.


Entities store mentions in the list _mentions. The list is a simple list of strings which will be either an URL format or handle, as per above examples.

The syntax for a mention in text is URL format @{<>} or @{<profile.handle>}. The GUID format cannot be used for a mention.


# profile.handle
Hello @{user@domain.tld}!

# in URL format
Hello @{https://domain.tld/user}

It is suggested profile.handle syntax is used always for textual mentions unless handles are not available.


Mentions are added to the entity _mentions list when processing inbound entities. For ActivityPub they will be extracted from Mention tags and for Diaspora extracted from the text using the Diaspora mention format.


Mentions can be given in the _mentions list. If not given, they will be extracted from the textual content using the above formats in the example.

For ActivityPub they will be added as Mention tags before sending. If the mention is in handle format, a WebFinger fetch will be made to find the profile URL format ID.

For Diaspora they will be added to the text in the correct format, if not found. If they are found in the text in non-Diaspora format, they will be converted before sending.


Federation provides many generators to allow providing discovery documents. They have been made as Pythonic as possible so that library users don’t have to meddle with the various documents and their internals.

The protocols themselves are too complex to document within this library, please consult protocol documentation on what kind of discovery documents are expected to be served by the application.


Helper methods

Generator classes


High level utility functions to fetch remote objects. These should be favoured instead of protocol specific utility functions.


High level utility functions to pass incoming messages to. These should be favoured instead of protocol specific utility functions.


High level utility functions to pass outbound entities to. These should be favoured instead of protocol specific utility functions.


Some ready provided views and URL configuration exist for Django.

Note! Django is not part of the normal requirements for this library. It must be installed separately.


To use the Django views, ensure a modern version of Django is installed and add the views to your URL config for example as follows. The URL’s must be mounted on root if Diaspora protocol support is required.

url(r"", include("federation.hostmeta.django.urls")),

Some settings need to be set in Django settings. An example is below:

    "base_url": "https://myserver.domain.tld,
    "federation_id": "",
    "get_object_function": "myproject.utils.get_object",
    "get_private_key_function": "myproject.utils.get_private_key",
    "get_profile_function": "myproject.utils.get_profile",
    "matrix_config_function": "myproject.utils.matrix_config_funct",
    "nodeinfo2_function": "myproject.utils.get_nodeinfo2_data",
    "process_payload_function": "myproject.utils.process_payload",
    "search_path": "/search/?q=",
    "tags_path": "/tags/:tag:",
  • base_url is the base URL of the server, ie protocol://domain.tld.
  • federation_id is a valid ActivityPub local profile id whose private key will be used to create the HTTP signature for GET requests to ActivityPub platforms.
  • get_object_function should be the full path to a function that will return the object matching the ActivityPub ID for the request object passed to this function.
  • get_private_key_function should be the full path to a function that will accept a federation ID (url, handle or guid) and return the private key of the user (as an RSA object). Required for example to sign outbound messages in some cases.
  • get_profile_function should be the full path to a function that should return a Profile entity. The function should take one or more keyword arguments: fid, handle, guid or request. It should look up a profile with one or more of the provided parameters.
  • matrix_config_function (optional) function that returns a Matrix configuration dictionary, with the following objects:
  # Location of the homeserver (not server name)
  "homeserver_base_url": "https://matrix.domain.tld",
  # Homeserver domain and port (not server domain)
  "homeserver_domain_with_port": "matrix.domain.tld:443",
  # Homeserver name
  "homeserver_name": "domain.tld",
  # Appservice details
  "appservice": {
    # Unique ID to register with at the homeserver. Don't change this after creating.
    "id": "uniqueid",
    # Short code (a-z only), used for various things like namespacing
    "shortcode": "federatedapp",
    # Secret token for communication
    "token": "secret_token",
  # (Optional) location of identity server
  "identity_server_base_url": "https://id.domain.tld",
  # (Optional) other keys to include in the client well-known (must be a dictionary)
  "client_wellknown_other_keys": {
    "" "barfoo",
  # (Optional) registration shared secret
  "registration_shared_secret": "supersecretstring",
  • nodeinfo2_function (optional) function that returns data for generating a NodeInfo2 document. Once configured the path /.well-known/x-nodeinfo2 will automatically generate a NodeInfo2 document. The function should return a dict corresponding to the NodeInfo2 schema, with the following minimum items:
  • process_payload_function (optional) function that takes in a request object. It should return True if successful (or placed in queue for processing later) or False in case of any errors.
  • search_path (optional) site search path which ends in a parameter for search input, for example “/search?q=”
  • tags_path (optional) path format to view items for a particular tag. :tag: will be replaced with the tag (without #).


The code for opening and creating protocol messages lives under each protocol module in federation.protocols.

Each protocol defines a protocol.Protocol class under it’s own module. This is expected to contain certain methods that are used by the higher level functions that are called on incoming messages and when sending outbound messages. Everything that is needed to transform an entity into a message payload and vice versa should be here.

Instead of calling methods directly for a specific protocol, higher level generic functions should be normally used.


Various utils are provided for internal and external usage.







Various custom exception classes might be returned.