The email subsystem is designed for apps to send and receive email on behalf of users. We use a driver-architecture to connect with appropriate email systems.

Core Concepts

  • A Hexarc user has 0 or more accounts. For example, a user might have a Gmail account, which is uniquely identified by an email address.
  • An account has a unique ID which encodes both the service and the account ID within the service. For example: gmail:[email protected]. NOTE: Consider storing this account data in Arc.users. One advantage is that we might be able to support sign-in with alternate credentials.
  • A Hexarc user must manually add an account. Adding an account may require authorization (and thus UI) so it generally must be done while the user is on a browser.
  • Once we've received authorization, we store appropriate tokens in Cryptosaur.
  • An account is accessible to one or more Hexarc users (we support multiple users on an account to handle things like companies/group accounts).
  • An account has one or more capabilities. For example, send-email is a capability. We support generic capabilities (send message), type-specific capabilities (send email), and provider-specific capabilities (send Google message).
  • For each capability, we track permissions for each app by capability. For example, a user might allow Ministry to send email but prevent some other app. We don't necessarily need to put up UI when configuring permissions, but at minimum we need a central place to see what apps have what permissions and an audit trail of apps using capabilities.
  • Apps can invoke calls to access capabilities on behalf of a user.

See Also