Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

Installation

Configuration

Technical introduction

Technical architecture

User’s device

  • runs the engine as a background process
    • for example as systemd service or a Windows service
  • has the app binary, acts as an interface for managing the engine
  • uses protocol for communication between them
  • on initial startup: engine generates a device identity (keypair) and then registers with the ProtectASM server

ProtectASM server

  • runs the server behing a reverse proxy or something
  • configured with a matrix bot account for notifications (possibly more providers later)
  • requires no user information for registration
  • automatically removes devices after 30 days if there’s no communication in that time
    • option to extend the time by some amount (Assembly events are 6 months apart so it could get annoying to always set it up again)
    • it should be a separate option to enable/disable the device but still keep the configuration stored
  • notification targets need to be verified somehow (possibly send a code and then ask for the code?)
  • only accepts signed messages from devices using their keypair
    • if a device has lost its private key, it must register as a new device and the old data will be deleted according to the settings
  • ratelimits!

Contributors

  • midka – development and documentation