Technical Considerations

Federation

The decision to use the federated architecture over a distributed one was quite simply that federated networks follow a more traditional model, and are generally easier to implement. Federation is also being widely implemented using social web standards such as the [ActivityPub Protocol allow for disparate applications (such as Mastodon, and GNU Social) to interact with one another. This interoperability is a key aspect for the project as it will encourage adoption.

For a more descriptive explanation check out Why not Distributed?

Handling User Data

User data should not be treated as if it were a commercially produced commodity that can be freely bought, sold, traded, and mishandled. This translates into the following requirements for the project:

• Keep as little user data as absolutely necessary
• Allow users to manage their own data

Minimizing data collection not only reduces server storage requirements, but it also reduces the impact in the event of a server hack or data seizure. Personal data management, a primary concern for privacy advocates, is another feature very high on the priority list. Therefore we are striving to include the following functionality (and make it easilly accessible):

• Full Data Export
• Data migration (move from one server to another)
  • Including friend, group, event information
• Self-service account deletion