Requirement analysis Server - UserXXX/vCom GitHub Wiki

This page gives an overview of the requirements the server shall meet when the project is finished.

Interface

  • uses a console
  • simple to use and
  • easy to configure using commands that all have a similar structure and aren't overloaded with parameters

Configuration

  • human readable config files
  • live editing of configs while server is online (maybe with a restart for some deeper settings)
  • whitelist / blacklist for user identification and / or IP address
  • configurable maximum file size for file transfer
  • configurable count of users in the database
  • configurable count of users that can be online at the same time
  • configurable maximum amount of bytes of messages stored for a user
  • configurable duration of how long messages are stored for forwarding (e.g. messages older than 6 months get deleted)
  • configurable schedule of maintenence(e.g. message cleanup), auto uptade and server restart

Features

  • logging (mainly erros, error protocol)
  • whitelist / blacklist (see above)
  • storing messages for not online users in a database
  • message forwarding to multiple devices that use the same identity (e.g. desktop client and smartphone)
  • finding users by name
  • reporting users for toxical behaviour
  • storing pending reports and sending an reminder(e-mail) to the server admin
  • list of blocked users per user, no message transfer to recipient if sending user is blocked
  • friendlist for each user
  • required settings for message forwarding per user (see client requirements for details)
  • no loss of data (messages etc.) on server restart
  • auto update (optional)
  • notification on available update / done update (via e-mail)
  • restart after running a configurable amount of time (i.e. restart every 24h)
  • password authentication on user login (optional)
  • marking once transmitted messages as "read"
  • user management (stores public keys, profile images, names and group chat information)

Safety and security

  • the server can't decrypt the users messages
  • no logging of online times or writing behaviour
  • verification of user identities
  • preventing SQL injection to underlying database
  • spam / DoS / DDoS detection and prevention
  • minimization of data loss on server crash (depends mainly on the used DBMS)

Efficiency

  • message delivery within 10 seconds after the server received it (if recipient is online)
  • spam / DoS / DDoS blocking to ensure other efficiency constraints
  • runnable on Raspberry PI
  • file transfers only between online users