mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-01-24 05:30:06 -06:00
docs(groupware): add Groupware related ADRs
This commit is contained in:
Pascal Bleser
343
docs/adr/0002-groupware-authentication-with-stalwart.md
Normal file
343
docs/adr/0002-groupware-authentication-with-stalwart.md
Normal file
@@ -0,0 +1,343 @@
|
||||
---
|
||||
title: "Authentication with Stalwart"
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
In a groupware environment, not every user will always use the OpenCloud UI to read their emails, some will resort to other [MUAs (Mail User Agents)](https://en.wikipedia.org/wiki/Email_client) that support a subset of features, use older protocols (IMAP, POP, SMTP, CalDAV, CardDAV) and lesser authentication methods (basic authentication). Those email clients will talk to Stalwart directly, as opposed to the OpenCloud UI which will make use of APIs of the OpenCloud Groupware service, since those protocols are provided by Stalwart and implementing them in OpenCloud would offer very little benefits, but definitely a lot of (almost completely) unnecessary effort.
|
||||
|
||||
Those protocols and operations that bypass the OpenCloud UI also need to be authenticated, this in and by Stalwart, and we need to find the best fitting approach that fulfills most or all of the following constraints:
|
||||
|
||||
### Single Provisioning
|
||||
|
||||
We want to avoid multiple provisioning of users, groups, passwords and other resources as much as possible.
|
||||
While it is possible to have e.g. OpenCloud's user management also perform [Management API](https://stalw.art/docs/category/management-api/) calls, one still inevitably ends up in situations where users, user passwords, or other resources are not in sync, which becomes complex to debug and fix, and should thus be avoided if possible.
|
||||
|
||||
To do so, we should strive to have a single source of truth regarding users, their passwords, and similar resources and attributes such as groups, roles, application passwords, etc...
|
||||
|
||||
### Attack Detection
|
||||
|
||||
Coordinated attacks such as [denial of service](https://en.wikipedia.org/wiki/Denial-of-service_attack) attempts don't necessarily focus on a single protocol but are commonly multi-pronged, e.g. by brute forcing the [OIDC API](https://www.keycloak.org/docs/latest/authorization_services/index.html#token-endpoint), the OpenCloud Groupware API, IMAP and SMTP, \*DAV protocols, etc...
|
||||
|
||||
In order to detect those as well as to quickly react by blacklisting clients that are identified to attempt such attacks, it is useful to have a single authentication service for all the components of the system, all protocols, all clients (e.g. [PowerDNS Weakforced](https://github.com/PowerDNS/weakforced), [Nauthilus](https://nauthilus.org/), ...)
|
||||
|
||||
Furthermore, such services typically make use of [DNSBL/RBL services](https://en.wikipedia.org/wiki/Domain_Name_System_blocklist) that allow IP addresses of botnets to be blocked across many services of many providers as a shared defense mechanism.
|
||||
|
||||
As a bonus, a centralized authentication component can also provide metrics and observability capabilities across all those protocols.
|
||||
|
||||
### Custom Authentication Implementations
|
||||
|
||||
Some customers might want custom authentication implementations to integrate with their environment, in which case we would want those to be done once and in the technology stack we're all most familiar with (thus as a service in Go in the OpenCloud framework, and not e.g. a Lua script in Nauthilus, or a Rust plugin in Stalwart, etc...)
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
TODO
|
||||
|
||||
*
|
||||
|
||||
## Considered Options
|
||||
|
||||
First off, here is a brief explanation of each of the scenarios that we potentially or absolutely need to support, which we will explore for each implementation option:
|
||||
|
||||
* MUAs with basic authentication
|
||||
* these are external mail clients (Thunderbird, Apple Mail, ...) with which users authenticate using legacy protocols (IMAP, POP3, SMTP) and their primary username and password in clear text (encrypted through the mandatory use of TLS)
|
||||
* MUAs with application password authentication
|
||||
* these are external mail clients (Thunderbird, Apple Mail, ...) with which users authenticate using legacy protocols (IMAP, POP3, SMTP) and one of the application passwords that they created in the OpenCloud UI, which is a useful security mechanism as it reduces the attack surface when one such password is leaked or discovered
|
||||
* MUAs with SASL bearer token authentication
|
||||
* these are more modern external mail clients (Thunderbird) with which users authenticate using legacy protocols (IMAP, POP3, SMTP) but more secure OIDC token based authentication (SASL OAUTHBEARER or SASL XOAUTH2), which closely resembles the OIDC authentication used by the OpenCloud UI towards the OpenCloud backends
|
||||
* JMAP clients with basic authentication
|
||||
* modern mail clients (Thunderbird) that speak the JMAP protocol over HTTP and authenticate using their primary username and password in clear text (encrypted through the use of HTTPS)
|
||||
* JMAP clients with bearer token authentication
|
||||
* modern mail clients (Thunderbird) that speak the JMAP protocol over HTTP and authenticate using an OIDC token (JWT) obtained from an IDP (typically KeyCloak)
|
||||
* OpenCloud Groupware with master authentication
|
||||
* the OpenCloud UI client uses APIs from the OpenCloud Groupware backend (and authenticates using OIDC)
|
||||
* the OpenCloud Groupware backend, in turn, performs JMAP operations with Stalwart, and authenticates using Stalwart's shared secret master authentication protocol
|
||||
* OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud UI client uses APIs from the OpenCloud Groupware backend (and authenticates using OIDC)
|
||||
* the OpenCloud Groupware backend, in turn, performs JMAP operations with Stalwart, and authenticates against Stalwart using bearer authentication with JWTs that it generates itself
|
||||
* in the future, that JWT might also be the JWT that the OpenCloud UI used to authenticate against the OpenCloud Groupware in the first place
|
||||
|
||||
### Stalwart with the LDAP Directory
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
s(Stalwart)
|
||||
l(LDAP)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
c -- JMAP --> s
|
||||
s -- LDAP --> l
|
||||
```
|
||||
|
||||
Clients authenticate directly against Stalwart, that is configured to use an LDAP authentication Directory.
|
||||
An LDAP server (e.g. OpenLDAP) is needed as part of the infrastructure.
|
||||
OpenCloud also has to make use of the same LDAP server.
|
||||
|
||||
* ✅ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin supports plain text authentication by looking up the userPassword attribute in the LDAP server
|
||||
* ❌ MUAs with application password authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin does not support application password as it is hardwired to look up the password in the userPassword attribute in the LDAP server
|
||||
* even if it did support looking up alternative passwords in LDAP, this would hardly be practical as the application passwords are currently created and stored in OpenCloud, which would need to be modified to store them in LDAP in the first place
|
||||
* ❌ MUAs with SASL bearer token authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin does not support verifying OIDC tokens
|
||||
* ✅ JMAP clients with basic authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin supports plain text authentication by looking up the userPassword attribute in the LDAP server
|
||||
* ❌ JMAP clients with bearer token authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin does not support verifying OIDC tokens
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ❌ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart's LDAP Directory plugin does not support verifying OIDC tokens
|
||||
|
||||
### Stalwart with the OIDC Directory
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
s(Stalwart)
|
||||
o(IDP)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
c -- JMAP --> s
|
||||
s -- OIDC HTTP --> o
|
||||
```
|
||||
|
||||
Clients authenticate directly against Stalwart, that is configured to use an OIDC authentication Directory.
|
||||
An OIDC IDP (server) is needed as part of the infrastructure, e.g. KeyCloak.
|
||||
Optionally, an LDAP server (e.g. OpenLDAP) might be used as well, and KeyCloak would look up users and their credentials in LDAP.
|
||||
|
||||
OpenCloud also has to make use of the same LDAP server, or would need to be modified to be capable of only making use of an OIDC IDP (which would include limitations that are yet to be resolved, e.g. the option of using KeyCloak Admin APIs to retreieve groups, group members, ...)
|
||||
|
||||
* ❌ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not support plain text authentication
|
||||
* ❌ MUAs with application password authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not support application passwords
|
||||
* ❓ MUAs with SASL bearer token authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not currently support external IDPs, but is expected to in future versions
|
||||
* as of Stalwart 0.12, this would only work if Stalwart itself is used as the IDP when acquiring a token
|
||||
* ❌ JMAP clients with basic authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not support plain text authentication
|
||||
* ❓ JMAP clients with bearer token authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not currently support external IDPs, but is expected to in future versions
|
||||
* as of Stalwart 0.12, this would only work if Stalwart itself is used as the IDP when acquiring a token
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ❓ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart's OIDC Directory plugin does not currently support external IDPs, but is expected to in future versions
|
||||
* as of Stalwart 0.12, this would only work if Stalwart itself is used as the IDP when acquiring a token, which is not the case with this approach as the tokens are generated by the Groupware backend itself
|
||||
|
||||
### Stalwart with the Internal Directory
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
s(Stalwart)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
c -- JMAP --> s
|
||||
```
|
||||
|
||||
Clients authenticate directly against Stalwart, that is configured to use an Internal authentication Directory.
|
||||
Neither an OIDC IDP nor an LDAP server are needed as part of the infrastructure, as principal resources (users, groups) and their credentials exist in Stalwart's storage.
|
||||
|
||||
OpenCloud would not be capable of accessing those resources, which means that provisioning of groups, users, user passwords must be duplicated and kept in sync between Stalwart and OpenCloud.
|
||||
|
||||
* ✅ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin supports plain text authentication
|
||||
* ✅ MUAs with application password authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin supports application passwords
|
||||
* users are able to create those themselves using the self-service web UI of Stalwart
|
||||
* they are not shared with the OpenCloud application passwords though and would need to be provisioned into Stalwart when created in OpenCloud to provide a single UI
|
||||
* ❌ MUAs with SASL bearer token authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin does not support OIDC token authentication
|
||||
* ✅ JMAP clients with basic authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin supports plain text authentication
|
||||
* ❌ JMAP clients with bearer token authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin does not support OIDC token authentication
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ❌ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart's Internal Directory plugin does not support OIDC token authentication
|
||||
|
||||
### Stalwart with the OpenCloud Authentication API
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
s(Stalwart)
|
||||
o(OpenCloud)
|
||||
l(LDAP)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
c -- JMAP --> s
|
||||
s -- REST --> o
|
||||
o -- LDAP --> l
|
||||
```
|
||||
|
||||
Clients authenticate directly against Stalwart, that is configured to use an "External" authentication Directory, that is yet to be developed. (warning)
|
||||
Its protocol is currently not defined, but not particularly relevant at this time, as long as it supports accepting basic and bearer authentication in order to authenticate both username and password credentials as well as OIDC tokens.
|
||||
|
||||
That External Directory implementation forwards the basic or bearer credentials to an endpoint in the OpenCloud backend, that the responds with whether the authentication is successful or not, as well as with additional information that is needed for Stalwart (email address, display name, groups, roles, ...)
|
||||
|
||||
* ✅ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's External Directory supports plain text authentication by relaying the authentication operation to the OpenCloud backend, which can then authenticate users by username and password using an LDAP server
|
||||
* note that this option requires having an LDAP server in the environment, including having it accessible by OpenCloud
|
||||
* if that is not the case, then a viable option is also to support OIDC tokens and application passwords
|
||||
* to clarify: this scenario is only about supporting authentication using the "primary" username and password
|
||||
* ✅ MUAs with application password authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's External Directory supports application password authentication by relaying the authentication operation to the OpenCloud backend, which can then authenticate against its list of application passwords
|
||||
* this is the ideal scenario for application passwords, since they are already supported by OpenCloud, and can be created and managed using the OpenCloud UI
|
||||
* relaying the authentication operation to OpenCloud also prevents the need for duplicate provisioning of application passwords
|
||||
* ✅ MUAs with SASL bearer token authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's External Directory supports OIDC token authentication by relaying the authentication operation to the OpenCloud backend, which can then either perform local token inspection and authentication by verifying the token's signature, or use the OIDC IDP's token introspection endpoint
|
||||
* ✅ JMAP clients with basic authentication
|
||||
* JMAP clients authenticate directly against Stalwart
|
||||
* Stalwart's External Directory supports plain text authentication by relaying the authentication operation to the OpenCloud backend, which can then authenticate users by username and password using an LDAP server
|
||||
* the same limitations/requirements as for the "MUAs with basic authentication" scenario apply here as well
|
||||
* ✅ JMAP clients with bearer token authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's External Directory supports OIDC token authentication by relaying the authentication operation to the OpenCloud backend, which can then either perform local token inspection and authentication by verifying the token's signature, or use the OIDC IDP's token introspection endpoint
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ✅ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* in the worst case, the External Directory plugin in Stalwart would also perform a forwarding of the authentication operation to OpenCloud, which would obviously be able to verify a token it has created
|
||||
* an optimization might be possible here, if the External Directory implementation permits for the configuration of specific issuers which should then be verifying against a JWK set directly, whereas the fallback behaviour would be to query the OpenCloud Authentication API
|
||||
|
||||
### Stalwart with Nauthilus and LDAP
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
s(Stalwart)
|
||||
n(Nauthilus)
|
||||
l(LDAP)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
c -- JMAP --> s
|
||||
s -- REST --> n
|
||||
n -- LDAP --> l
|
||||
```
|
||||
|
||||
In this scenario, we introduce the [Nauthilus authentication service](https://nauthilus.org/), which has its own API but also a KeyCloak integration plugin.
|
||||
It supports various backends and can also be scripted for more complex combinations.
|
||||
|
||||
⚠️ It would require the implementation of a Stalwart Nauthilus Directory, **that is yet to be developed**.
|
||||
|
||||
We do not make use of any OpenCloud Authentication API but, instead, attempt to have everything go through Nauthilus instead, backed by an LDAP server that then contains the users, groups, and user passwords.
|
||||
|
||||
The upside of using Nauthilus is that it does brute force attack detection and can provide metrics across multiple protocols and clients in a centralized fashion.
|
||||
|
||||
* ✅ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's Nauthilus Directory supports plain text authentication by relaying the authentication operation to Nauthilus, e.g. using its JSON API
|
||||
* Nauthilus provides a response that contains user attributes from LDAP (display name, email addresses, ...)
|
||||
* ❓ MUAs with application password authentication
|
||||
* Nauthilus has no support for application passwords in itself
|
||||
* a Lua plugin could potentially be used in Nauthilus to detect whether the clear text password matches a regular expression for application passwords and, if that is the case, first attempt to verify it through an API call (that does not exist yet) to the OpenCloud backend, but that would definitely be more complex and less elegant than having a single API
|
||||
* ❓ MUAs with SASL bearer token authentication
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication
|
||||
* ✅ JMAP clients with basic authentication
|
||||
* Stalwart's Nauthilus Directory supports plain text authentication by relaying the authentication operation to Nauthilus, e.g. using its JSON API
|
||||
* Nauthilus provides a response that contains user attributes from LDAP (display name, email addresses, ...)
|
||||
* ❓ JMAP clients with bearer token authentication
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ❓ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication
|
||||
* an optimization might be possible here, if the Nauthilus Directory implementation permits for the configuration of specific issuers which should then be verifying against a JWK set directly, whereas the fallback behaviour would be to query the Nauthilus API, but that does sound like a stretch to fit into the concept
|
||||
|
||||
### Stalwart with Nauthilus and an OpenCloud Authentication API
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
c(client)
|
||||
j(client)
|
||||
s(Stalwart)
|
||||
n(Nauthilus)
|
||||
o(OpenCloud)
|
||||
l(LDAP)
|
||||
k(Keycloak)
|
||||
|
||||
c -- IMAP/SMTP --> s
|
||||
j -- JMAP --> s
|
||||
s -- REST --> n
|
||||
subgraph internal auth
|
||||
n -- REST --> o
|
||||
o -- LDAP --> l
|
||||
o -- OIDC --> k
|
||||
end
|
||||
```
|
||||
|
||||
This option also makes use of the [Nauthilus authentication service](https://nauthilus.org/), but instead of it using LDAP to resolve users, we would either make use of its Lua scripting abilities to implement a backend that performs HTTP calls to an OpenCloud Authentication API, or implement an additional Nauthilus backend that uses the Nauthilus API to delegate to another instance, which would then be the OpenCloud Authentication API with support for the Nauthilus API.
|
||||
|
||||
⚠️ As with the previous option, it would require the implementation of a Stalwart Nauthilus Directory, **that is yet to be developed**.
|
||||
|
||||
Interestingly, if the OpenCloud Authentication API follows the Nauthilus API, this scenario can easily be degraded by dropping Nauthilus and, instead, having all services talk to the OpenCloud Authentication API directly.
|
||||
|
||||
* ✅ MUAs with basic authentication
|
||||
* MUAs authenticate directly against Stalwart
|
||||
* Stalwart's Nauthilus Directory supports plain text authentication by relaying the authentication operation to Nauthilus, e.g. using its JSON API
|
||||
* Nauthilus provides a response that contains user attributes from LDAP (display name, email addresses, ...)
|
||||
* ✅ MUAs with application password authentication
|
||||
* Nauthilus would forward the authentication request to the OpenCloud Authentication API, which would support application passwords
|
||||
* ❓ MUAs with SASL bearer token authentication
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication and whether it would be able to forward such requests to the OpenCloud Authentication API
|
||||
* ✅ JMAP clients with basic authentication
|
||||
* Stalwart's Nauthilus Directory supports plain text authentication by relaying the authentication operation to Nauthilus, e.g. using its JSON API
|
||||
* Nauthilus then forwards that request to the OpenCloud Authentication API
|
||||
* the OpenCloud Authentication API, and then Nauthilus, provides a response that contains user attributes from LDAP (display name, email addresses, ...) or claims from the JWT
|
||||
* ❓ JMAP clients with bearer token authentication
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication and whether it would be able to forward such requests to the OpenCloud Authentication API
|
||||
* ✅ OpenCloud Groupware with master authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* Stalwart detects and supports clear text password master authentication regardless of the Directory that is being used, and verifies it against the shared secret password that is configured in the server
|
||||
* ❓ OpenCloud Groupware with generated token authentication
|
||||
* the OpenCloud Groupware backend authenticates directly against Stalwart
|
||||
* it is currently unclear whether Nauthilus supports OIDC token authentication and whether it would be able to forward such requests to the OpenCloud Authentication API
|
||||
|
||||
> [!IMPORTANT]
|
||||
> We need to clarify whether the Nauthilus API allows for a JWT to be submitted for the authentication request, and not only username and password – not to secure the request in itself, but to forward an OIDC token based authentication attempt as part of the payload.
|
||||
|
||||
### Comparing Options
|
||||
|
||||
| | MUA basic | MUA app password | MUA sasl | JMAP clients with basic auth | JMAP clients with JWT auth | Groupware Middleware with master auth | Groupware Middleware with JWT auth |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| Stalwart 0.12 with LDAP Directory | ✅ MUA → Stalwart | ❌ not supported with LDAP | ❌ not supported with LDAP | ✅ | ❌ | ✅ | ❌ |
|
||||
| Stalwart 0.12 with OIDC Directory | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ |
|
||||
| Stalwart 0.12 with Internal Directory | ✅ MUA → Stalwart, must be provisioned in Stalwart | ✅ MUA → Stalwart, must be provisioned in Stalwart | ❌ | ❌ | ❌ unless using Stalwart as IDP | ✅ | ❌ |
|
||||
| Stalwart + OpenCloud Authentication API | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ | ✅ |
|
||||
| Stalwart + Nauthilus + LDAP | ✅ MUA → IMAP proxy → Nauthilus → LDAP | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ |
|
||||
| Stalwart + Nauthilus + OpenCloud Authentication API | ✅ MUA → IMAP proxy → Nauthilus → OpenCloud | ✅ MUA → IMAP proxy → Nauthilus → OpenCloud | ✅ MUA → IMAP proxy → Nauthilus → OpenCloud | ✅ MUA → IMAP proxy → Nauthilus → OpenCloud | ✅ MUA → IMAP proxy → Nauthilus → OpenCloud | ✅ | ✅ |
|
||||
| Stalwart + Nauthilus-like OpenCloud Authentication API | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ MUA → Stalwart → OpenCloud | ✅ | ✅ |
|
||||
64
docs/adr/0003-groupware-microservice-vs-oc-integration.md
Normal file
64
docs/adr/0003-groupware-microservice-vs-oc-integration.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
status: proposed
|
||||
date: 2025-06-24
|
||||
author: Pascal Bleser <p.bleser@opencloud.eu>
|
||||
decision-makers:
|
||||
consulted:
|
||||
informed:
|
||||
title: "Implementing Groupware as a separate Microservice vs integrated in the OpenCloud Stack"
|
||||
template: https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
Should the Groupware backend be an independent microservice or be part of the OpenCloud single binary framework?
|
||||
|
||||
The OpenCloud backend is built on a framework that
|
||||
|
||||
* implements token based authentication between services
|
||||
* allows for a "single binary" deployment mode that runs all services within that one binary
|
||||
* integrates services such as a NATS event bus
|
||||
|
||||
This decision is about whether the Groupware backend service should be implemented within that framework or, instead, be implemented as a standalone backend service.
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
* single binary deployment strategy is potentially important (TODO how important is it really? stakeholders:?)
|
||||
|
||||
## Considered Options
|
||||
|
||||
* have the Groupware Middleware as an independent microservice
|
||||
* have the Groupware Middleware implemented within the existing OpenCloud framework
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
TODO
|
||||
|
||||
### Consequences
|
||||
|
||||
TODO
|
||||
|
||||
### Confirmation
|
||||
|
||||
TODO
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
### Independent Microservice
|
||||
|
||||
* (potentially) good: be free from technical decisions made for the existing OpenCloud stack, to avoid carrying potential technical baggage
|
||||
* (potentially) good: make use of a framework that is more fitting for the tasks the Groupware backend needs to accomplish
|
||||
* bad: re-implement framework components that already exist, with the need to maintain those in two separate codebases, or the added complexity of a shared library repository
|
||||
* bad: not have the ability to include the Groupware backend in the single binary deployment
|
||||
* neutral: a separate code repository and delivery for the Groupware backend, which might or might not be of advantage
|
||||
* neutral: may be implemented on a completely different technology stack, including the programming language
|
||||
|
||||
### Part of the framework
|
||||
|
||||
* good: fit into the opinionated choices that were made for the OpenCloud framework so far
|
||||
* good: many aspects are already implemented in the current framework and can be made use of, potentially enhanced for the needs of the Groupware backend
|
||||
* good: the ability to include the Groupware backend in the single binary deployment
|
||||
* neutral: be in the same code repository and part of the same delivery as other services in OpenCloud
|
||||
* neutral: must be implemented in Go on top of the same technology stack
|
||||
294
docs/adr/0004-groupware-resource-linking.md
Normal file
294
docs/adr/0004-groupware-resource-linking.md
Normal file
@@ -0,0 +1,294 @@
|
||||
---
|
||||
status: proposed
|
||||
date: 2025-06-24
|
||||
author: Pascal Bleser <p.bleser@opencloud.eu>
|
||||
decision-makers:
|
||||
consulted:
|
||||
informed:
|
||||
title: "Resource Linking"
|
||||
template: https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
Which semantic and technical approach to take in order to provide strong integration of the various products and capabilities of OpenCloud, OpenTalk, and potentially other products as well?
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
* a strong integration that allows users to access resources and relationships without having to switch views, which translates into a "mental switch" as well
|
||||
* an innovative approach that differs from the traditional way groupware applications have been designed in the past
|
||||
* TODO more decision drivers from PM
|
||||
* a model that is open and generic enough to integrate many different types of resources and relationships
|
||||
* a model that allows for independent and incremental upgrades to the resources and relationships that can be contributed by each service
|
||||
|
||||
## Considered Options
|
||||
|
||||
* resource linking
|
||||
* application launchers
|
||||
* TODO? can we come up with more ideas?
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
TODO
|
||||
|
||||
### Consequences
|
||||
|
||||
TODO
|
||||
|
||||
### Confirmation
|
||||
|
||||
TODO
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
### Resource Linking
|
||||
|
||||
This concept primarily resides on the idea of having resources, which have attributes, and relations between them, pretty much as [RDF (Resource Description Framework)](https://www.w3.org/RDF/) does, where the Groupware backend provides services to explore relations of a given resource.
|
||||
|
||||
* good: decoupling of UI, backends as well as other participants, as backends can gradually evolve the relationships and resources they understand and can contribute to over time, as well as for the UI that may just silently ignore resources it does not support yet or does not want to present to the user
|
||||
* good: potential for an asynchronous architecture that would enable the UI to present some resources early without having to wait for those that require more processing time or are provided by services that happen to be under heavier load
|
||||
* good: it should provide ammunition for a modern and original UI that is centered around resources and relationships rather than the usual visual paradigms
|
||||
* bad: it might be a challenge to implement this approach in a performant way with rapid response times, as it could cause additional complexity and storage services (e.g. to denormalize reverse indexes, cache expensive resource graphs, etc...)
|
||||
|
||||
#### URNs
|
||||
|
||||
Each resource has a unique identifier, for which [URNs (Uniform Resource Names)](https://www.rfc-editor.org/rfc/rfc1737) seem the best representation.
|
||||
|
||||
URNs are composed of
|
||||
|
||||
* a namespace identifier
|
||||
* a namespace-specific string
|
||||
|
||||
As a convention, we will use the following:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><code>urn:</code></th>
|
||||
<th>ns</th>
|
||||
<th colspan="2">namespace specific string</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>urn:</code></td>
|
||||
<td><code>oc:</code></td>
|
||||
<td><code><type>:</code></td>
|
||||
<td><code><unique identifier>:</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
##### Examples
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><code>urn:</code></th>
|
||||
<th>namespace</th>
|
||||
<th>type</th>
|
||||
<th>unique id</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>urn:</code></td>
|
||||
<td><code>oc:</code></td>
|
||||
<td><code>user:</code></td>
|
||||
<td><code>camina.drummer</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>urn:</code></td>
|
||||
<td><code>oc:</code></td>
|
||||
<td><code>contact:</code></td>
|
||||
<td><code>klaes.ashford</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>urn:</code></td>
|
||||
<td><code>oc:</code></td>
|
||||
<td><code>event:</code></td>
|
||||
<td><code>dd4ea520-e414-41e1-b545-b1c7d4ce57e7</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>urn:</code></td>
|
||||
<td><code>oc:</code></td>
|
||||
<td><code>mail:</code></td>
|
||||
<td><code><1e8074e8-cd56-4358-9f9e-f17cb701b950@opa.org></code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### Exploration API
|
||||
|
||||
Whenever the user puts a resource into focus in the OpenCloud Groupware UI (i.e. by selecting/clicking that resource, e.g. the sender of an email), it may send a request to the Groupware service API to inquire about related resources.
|
||||
|
||||
What those related resources are still stands to be determined, but examples could be along the lines of
|
||||
|
||||
* unread emails from the same sender
|
||||
* emails exchanged with that sender in the last 7 days
|
||||
* files recently shared with that user
|
||||
* spaces or groups in common with that user
|
||||
* OpenTalk meetings planned within the next 3 days
|
||||
|
||||
In order to decouple the Groupware service from which resources and relations are supported,
|
||||
|
||||
* whenever such an exploration request is received, the Groupware service forwards it to all known services, in a "fan-out" model
|
||||
* each service can understand the focused resource, or not, but if it does it may return related resources that it is capable of providing using its data model (e.g. OpenTalk providing related meeting resources, OpenCloud Groupware providing related calendar events, contacts, mails, etc...)
|
||||
* ideally, that happens in an asynchronous fashion, using e.g. [SSE (Server Side Events)](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) to push results to the OpenCloud UI to avoid having to wait for the slowest contributor, although that pushes the "reduce" part of this ["map-reduce" operation](https://en.wikipedia.org/wiki/MapReduce) to the client
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
c(client)
|
||||
subgraph backend
|
||||
a(opencloud api)
|
||||
g(groupware)
|
||||
ot(opentalk)
|
||||
u(users)
|
||||
s(stalwart)
|
||||
k(keycloak)
|
||||
end
|
||||
subgraph storage
|
||||
ots@{ shape: cyl, label: "opentalk\nstorage"}
|
||||
ss@{ shape: cyl, label: "stalwart\nstorage"}
|
||||
l@{ shape: cyl, label: "ldap"}
|
||||
end
|
||||
c-->|/related/urn:oc:user:camina.drummer|a
|
||||
a-->|/related/urn:oc:user:camina.drummer|g
|
||||
g-->s
|
||||
s-->ss
|
||||
a-->|/related/urn:oc:user:camina.drummer|ot
|
||||
ot-->ots
|
||||
a-->|/related/urn:oc:user:camina.drummer|u
|
||||
u-->k
|
||||
k-->l
|
||||
|
||||
ot-.->|urn:oc:meeting:232403bc-b98f-4643-a917-80bdcfc7aaba|a
|
||||
g-.->|urn:oc:event:e5193ad3-8f1c-4162-8593-69fe659bcc08|a
|
||||
```
|
||||
|
||||
This allows a decoupling of all the participants, enabling each service to add, remove or alter relationships that it is able to contribute for a given resource type.
|
||||
|
||||
Obviously, the UI needs to be able to understand resource types to know how to represent them, but if it silently ignores resource types that it does not know of, backends can evolve independently from the UI.
|
||||
|
||||
#### JSON-LD
|
||||
|
||||
[JSON-LD (JSON for Linking Data)](https://json-ld.org/) seems like a potent representation format for those relationships in a REST environment.
|
||||
|
||||
It could look something like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"@context": {
|
||||
"@user": "https://schema.opencloud.eu/user.jsonld",
|
||||
"link": "https://schema.opencloud.eu/linked.jsonld"
|
||||
},
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:cdrummer",
|
||||
"name": "Camina Drummer",
|
||||
"email": "camina@opa.org",
|
||||
"roles": ["admin", "pirate"],
|
||||
"link:rooms": [
|
||||
{
|
||||
"@context": {
|
||||
"@room": "https://meta.opencloud.eu/room.jsonld",
|
||||
"link": "https://schema.opencloud.eu/linked.jsonld"
|
||||
},
|
||||
"@id": "urn:oc:room:a3f19df6-6c7d-45fa-b16c-6e168e2a2a43",
|
||||
"name": "OPA Leadership Standup 2355-02-27",
|
||||
"start": "2355-02-27T10:58:15.918Z",
|
||||
"end": "2355-02-27T13:52:59.010Z",
|
||||
"started_by": {
|
||||
"@context": "https://meta.opencloud.eu/user.jsonld",
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:adawes",
|
||||
"name": "Anderson Dawes",
|
||||
"email": "anderson@opa.org"
|
||||
},
|
||||
"link:events": [
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/event.jsonld",
|
||||
"@type": "urn:oc:type:event",
|
||||
"@id": "urn:oc:event:3e041c88-088c-4015-a32e-5560561f6e26",
|
||||
"start": "2355-02-27T11:09:15.918Z",
|
||||
"end": "2355-02-27T13:52:59.010Z",
|
||||
"status": "confirmed",
|
||||
"invited": [
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/user.jsonld",
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:adawes",
|
||||
"name": "Anderson Dawes",
|
||||
"email": "anderson@opa.org"
|
||||
},
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/user.jsonld",
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:kashford",
|
||||
"name": "Klaes Ashford",
|
||||
"email": "klaes@opa.org"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"members": [
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/contact.jsonld",
|
||||
"@type": "urn:oc:type:contact",
|
||||
"@id": "urn:oc:contact:9ccb247d-a728-4d8f-9259-c28cf6cef567",
|
||||
"name": "Naomi Nagata",
|
||||
"email": "naomo@opa.org"
|
||||
},
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/user.jsonld",
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:adawes",
|
||||
"name": "Anderson Dawes",
|
||||
"email": "anderson@opa.org"
|
||||
},
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/user.jsonld",
|
||||
"@type": "urn:oc:type:user",
|
||||
"@id": "urn:oc:user:kashford",
|
||||
"name": "Klaes Ashford",
|
||||
"email": "klaes@opa.org"
|
||||
}
|
||||
],
|
||||
"chat": {
|
||||
"@context": "https://meta.opencloud.eu/file.jsonld",
|
||||
"@type": "urn:oc:type:file",
|
||||
"@id": "urn:oc:file:OPA:chatlogs/2355/02/27/a3f19df6-6c7d-45fa-b16c-6e168e2a2a43.md",
|
||||
"href": "https://cloud.opencloud.eu/spaces/OPA/chatlogs/2355/02/27/a3f19df6-6c7d-45fa-b16c-6e168e2a2a43.md"
|
||||
}
|
||||
}
|
||||
],
|
||||
"link:mails": [
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/mail.jsonld",
|
||||
"@type": "urn:oc:type:mail",
|
||||
"@id": "583b9b66-c0b3-41ba-bf6c-a02ec5f4a638@smtp-07.opa.org",
|
||||
"subject": "About bosmang Fred Johnson",
|
||||
"date": "2355-01-03T09:39:44.919Z"
|
||||
},
|
||||
...
|
||||
],
|
||||
"link:shares": [
|
||||
{
|
||||
"@context": "https://meta.opencloud.eu/share.jsonld",
|
||||
"@type": "urn:oc:type:share",
|
||||
"@id": "841ef259-584d-4ce6-827f-b53f900c988d",
|
||||
"filename": "remember the cant.jpg"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Application Launchers
|
||||
|
||||
Have a UI that is comprised of multiple more-or-less separate applications, with an application launcher bar, with each application being an icon in itself in that launcher.
|
||||
|
||||
Similar to what e.g. Google does, or Open-Xchange App Suite.
|
||||
|
||||
* bad: does not make for an integrated application paradigm since users still have to context switch between those applications/views to perform tasks
|
||||
|
||||
62
docs/adr/0005-groupware-software-stack.md
Normal file
62
docs/adr/0005-groupware-software-stack.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
status: proposed
|
||||
date: 2025-06-25
|
||||
author: Pascal Bleser <p.bleser@opencloud.eu>
|
||||
decision-makers:
|
||||
consulted:
|
||||
informed:
|
||||
title: "Groupware Software Stack"
|
||||
template: https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
Which software stack to choose for the implementation of the OpenCloud Groupware service?
|
||||
|
||||
## Considered Options
|
||||
|
||||
* [Go](https://go.dev/) with the OpenCloud framework, as it is used in OpenCloud
|
||||
* Rust, as it is a similarly modern language, with know-how in Opentalk
|
||||
* Java with an opinionated microservice framework (e.g. [Micronaut](https://micronaut.io/))
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
The decision was taken to go with the existing Go technology stack used in OpenCloud, since it allows for
|
||||
|
||||
* everyone in the Groupware backend team to contribute
|
||||
* having a single technology stack across all OpenCloud backend features
|
||||
* having the option of a single binary deployment
|
||||
|
||||
### Consequences
|
||||
|
||||
TODO
|
||||
|
||||
### Confirmation
|
||||
|
||||
TODO
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
### Go
|
||||
|
||||
* good: established in the OpenCloud team, with expertise, potentially broadening the team that can contribute to Groupware development
|
||||
* good: make use of the existing infrastructure and framework, including the single binary deployment option
|
||||
* bad: less mature and capable technology stack, potentially problematic with regards to lack of asynchronous I/O and streamed HTTP processing
|
||||
|
||||
### Rust
|
||||
|
||||
* good: shared knowledge with the team of developers at OpenTalk
|
||||
* bad: little to no experience in the current OpenCloud team
|
||||
|
||||
### Java
|
||||
|
||||
* bad: little to no experience in the current OpenCloud team, with exception of the Groupware members
|
||||
* good: extensive experience with Micronaut with one OpenCloud developer
|
||||
* good: opinionated and well documented
|
||||
* good: cloud native
|
||||
* good: mature technology stack
|
||||
* good: asynchronous I/O and virtual threads make for efficient resource usage
|
||||
* potentially bad: likely to not fit well into low resource environments (although native compilation using GraalVM is possible)
|
||||
* potentially bad: prevents the single binary deployment option from including Groupware
|
||||
73
docs/adr/0006-groupware-stalwart-as-backend.md
Normal file
73
docs/adr/0006-groupware-stalwart-as-backend.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
status: proposed
|
||||
date: 2025-06-25
|
||||
author: Pascal Bleser <p.bleser@opencloud.eu>
|
||||
decision-makers:
|
||||
consulted:
|
||||
informed:
|
||||
title: "Stalwart as Groupware Backend"
|
||||
template: https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
Which Groupware backend should be used?
|
||||
|
||||
## Considered Options
|
||||
|
||||
* [Stalwart](https://stalw.art/), contains not only mail but also collaborative features in an integrated package
|
||||
* traditional IMAP/POP/SMTP stacks (e.g. [Dovecot](https://www.dovecot.org/) + [Postfix](https://www.postfix.org/))
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
The decision was made to go with Stalwart, as it reduces the implementation effort on our end, allowing us for a much faster time-to-market with a significantly smaller team of developers.
|
||||
|
||||
### Consequences
|
||||
|
||||
We will most probably not need to develop much of a calendar or contact stack ourselves, as Stalwart is planning to implement those as part of the upcoming [JMAP](https://jmap.io/spec-core.html) specifications for [contacts](https://jmap.io/spec-contacts.html) and [calendars](https://jmap.io/spec-calendars.html).
|
||||
|
||||
The Groupware API will largely consist of a translation of high-level operations for the UI into JMAP operations sent to Stalwart.
|
||||
|
||||
#### Risks
|
||||
|
||||
On the flip side, there are a number of risks associated with that decision.
|
||||
|
||||
* Stalwart underdelivers on its promises
|
||||
* calendaring provides insufficient features for our implementation (e.g. event series handling being too basic)
|
||||
* not scaling for large deployments
|
||||
* necessary adaptations (e.g. for authentication integration) are rejected upstream
|
||||
* etc...
|
||||
|
||||
### Confirmation
|
||||
|
||||
TODO
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
### Stalwart
|
||||
|
||||
* good: integrated package that contains IMAP/POP, SMTP, anti-spam, AI, encryption at rest and many other features in one
|
||||
* good: modern stack
|
||||
* good: capable of fault tolerance in large deployments through its use of [FoundationDB](https://www.foundationdb.org/)
|
||||
* bad: relatively new project with few to no large scale productive deployments (yet)
|
||||
* bad: significant human [SPoF](https://en.wikipedia.org/wiki/Single_point_of_failure)/[bus factor](https://en.wikipedia.org/wiki/Bus_factor) issue as the development team currently consists of one
|
||||
* good: supports and drives the JMAP protocol ([JMAP Core](https://jmap.io/spec-core.html), [JMAP Mail](https://jmap.io/spec-mail.html), [JMAP Contacts](https://jmap.io/spec-contacts.html), [JMAP Calendars](https://jmap.io/spec-calendars.html), [JMAP Tasks](https://jmap.io/spec-tasks.html), ...),
|
||||
* which provides more high-level operations that we don't need to implement ourselves,
|
||||
* as well as a much cleaner specification that reduces efforts too,
|
||||
* and additionally can be implemented with an efficient stateless HTTP I/O stack
|
||||
* bad: no viable broad JMAP implementation alternatives in case Stalwart does not deliver ([Apache James](https://james.apache.org/) only seems to support a basic subset of JMAP)
|
||||
* good: implements a lot of Groupware "business logic" on its own, reducing the implementation effort on our end,
|
||||
* most notably by not having to deal with IMAP extensions and quirks,
|
||||
* or the complexity of calendar events
|
||||
|
||||
### IMAP/SMTP
|
||||
|
||||
* good: there are a number of alternatives in case a specific implementation does not deliver
|
||||
* good: the best implementation candidates are well-established, used in large amounts of productive deployments, supported by teams of developers
|
||||
* bad: more complex stack composed of numerous components as opposed to an all-in-one implementation
|
||||
* bad: the effort and complexity of having to deal with IMAP,
|
||||
* its complexity due to its extensions and its many quirks,
|
||||
* as well as a significantly less efficient I/O stack that requires stateful session handling
|
||||
* bad: requires the complete implementation of contacts, calendars and tasks in our own stack, as none of those services are provided by IMAP/SMTP backends
|
||||
512
docs/adr/0007-groupware-webui-api.md
Normal file
512
docs/adr/0007-groupware-webui-api.md
Normal file
@@ -0,0 +1,512 @@
|
||||
---
|
||||
status: accepted
|
||||
date: 2025-07-22
|
||||
author: pbleser-oc
|
||||
consulted: AlexAndBear, butonic, dragotin, fschade, JammingBen, kulmann, martinherfurth, micbar, rhafer
|
||||
title: "API for the Groupware Web UI"
|
||||
---
|
||||
<!-- markdownlint-disable-file MD024 MD033 -->
|
||||
|
||||
## Context
|
||||
|
||||
We need a comprehensive HTTP API for the OpenCloud Web UI to provide access to the following (upcoming) modules and Groupware functionalities:
|
||||
|
||||
* Mail
|
||||
* Contacts
|
||||
* Calendar
|
||||
* Tasks
|
||||
* Chat
|
||||
* Configuration
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph clients
|
||||
ui(OpenCloud UI)
|
||||
muas(Other<br>MUAs)
|
||||
end
|
||||
subgraph Backend
|
||||
subgraph OpenCloud
|
||||
direction TB
|
||||
groupware("OpenCloud<br>Groupware")
|
||||
drive("OpenCloud<br>Drive")
|
||||
end
|
||||
stalwart(Stalwart)
|
||||
end
|
||||
subgraph Storage
|
||||
drive_storage[(drive<br>storage)]
|
||||
stalwart_metadata[(metadata<br>storage)]
|
||||
stalwart_storage[(object<br>storage)]
|
||||
end
|
||||
ui x@==>|?|groupware
|
||||
x@{ animate: true }
|
||||
ui-->|Graph|drive
|
||||
muas-->|IMAP,SMTP,*DAV|stalwart
|
||||
groupware-->drive
|
||||
groupware-->|JMAP|stalwart
|
||||
drive-->drive_storage
|
||||
stalwart-->stalwart_metadata
|
||||
stalwart-->stalwart_storage
|
||||
```
|
||||
|
||||
Additionally, the API must also be able to provide information about related resources and their relationships, as outlined in [the Resource Linking ADR](./0003-groupware-resource-linking.md).
|
||||
|
||||
For the OpenCloud Drive services, the communication between UI client and backend services is performed via the [LibreGraph API](https://github.com/opencloud-eu/libre-graph-api), which is based on [Microsoft Graph](https://developer.microsoft.com/en-us/graph). The goal of this ADR is **not** to question or change that decision, and the choice of an option is merely for the communication with the Groupware backend.
|
||||
|
||||
Communication between the OpenCloud Groupware and Stalwart will make use of the [JMAP (JSON Meta Application Protocol) protocol](https://jmap.io/spec-mail.html).
|
||||
|
||||
The API for the OpenCloud Web UI is **not** supposed to be an abstraction of that and thus may use JMAP data formats.
|
||||
|
||||
Other [MUAs (Mail User Agents)](https://en.wikipedia.org/wiki/Email_client) converse directly with Stalwart using [IMAP](https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol) or [POP3](https://en.wikipedia.org/wiki/Post_Office_Protocol), [SMTP](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol), [CalDAV](https://en.wikipedia.org/wiki/CalDAV), [CardDAV](https://en.wikipedia.org/wiki/CardDAV), or JMAP itself.
|
||||
|
||||
This ADR concerns the decision regarding which API approach/process/technology/specification to use, not the details of the data model and such, which will need to be fleshed out following the requirements and priorities of the OpenCloud UI Client development, regardless of the selected approach.
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
### UI Driven
|
||||
|
||||
The decision must be significantly driven by the OpenCloud UI Client developers, since they are the primary consumers of the API.
|
||||
|
||||
They will also be the sole consumers for a foreseeable while until the OpenCloud Groupware UI reaches a stable feature-complete milestone, which is the earliest point in time for the APIs to be considered stable as well and potentially be consumed by third parties.
|
||||
|
||||
Backend developers are stakeholders in that aspect as well though, as the choice of API approach has an impact on the complexity, costs and maintainability of the backend services as well.
|
||||
|
||||
### Economic Awareness
|
||||
|
||||
Reduction of complexity and implementation efforts, albeit not at all costs, and not only on the short run.
|
||||
|
||||
It is obviously of advantage when an option requires less implementation, or less complexity in its implementation.
|
||||
|
||||
### Efficiency
|
||||
|
||||
Regarding efficiency, the goal is to design an API that is tailored to providing responsiveness ([pagination](https://apisyouwonthate.com/blog/api-design-basics-pagination/), [SSEs (Server-Side Events)](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events), ...) and good network performance.
|
||||
|
||||
The latter is achieved by minimizing the number of roundtrips between the client and the servers, which, in turn, is typically achieved through the use of higher level APIs as opposed to a granular API that provides more flexibility but also, by its very nature, requires the combination of multiple request-response roundtrips over the wire.
|
||||
|
||||
### Third Party Consumption
|
||||
|
||||
We are assuming that the APIs are public APIs (not just technically) and may be consumed by SDKs and third parties.
|
||||
|
||||
Implications are that care must be put into providing an API that is stable, versioned, has a changelog, and potentially provided as a product with [LTS (Long-term Support)](https://en.wikipedia.org/wiki/Long-term_support) options.
|
||||
|
||||
This also hints at the necessity of a capability exchange/discovery protocol between clients and the Groupware backend, as we will have different versions of clients and servers in the wild, and they need to be able to understand each other. Crucially, if locally running clients are developed, they can go a long time without being updated.
|
||||
|
||||
## Considered Options
|
||||
|
||||
* [LibreGraph](#libregraph)
|
||||
* [JMAP](#jmap)
|
||||
* [custom REST API](#custom-rest-api) (albeit potentially based on standards, at least partially)
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
The decision was made to go with the custom REST implementation option, mainly due to
|
||||
|
||||
* the use of LibreGraph providing little benefits
|
||||
* if would provide us with a fleshed out API for groupware
|
||||
* but we would not implement it fully
|
||||
* and it is really an API for Outlook and Exchange, not a generic groupware standard
|
||||
* furthermore, a significant blocker is that it does not provide for a way to support multiple accounts for a user
|
||||
* the experience of implementing and using the LibreGraph API for the Drive components has made light of some challenges that we would not like to repeat
|
||||
* using JMAP directly
|
||||
* is a very interesting option in terms of standards, as it is an RFC,
|
||||
* but we currently see that approach as too risky as per the potential complexity of parsing payloads of JMAP commands and their backreferences, plugging those across commands that must be forwarded as-is to Stalwart and others that need to be handled by the Groupware middleware itself, but also the potential need to reverse engineer the high-level meaning of chained low-level JMAP commands in order to implement enrichment, caches, reverse indexes, etc...
|
||||
* however, it might be a better path forward in the future, especially if JMAP becomes a viable option for replacing the current use of LibreGraph as well
|
||||
|
||||
### Consequences
|
||||
|
||||
* we will need to design an API on our own, from scratch, albeit maximally making use of JMAP data structures
|
||||
* that API will need to be maintained as a product, with documentation, versioning, LTS
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
* [LibreGraph](#proscons-libregraph)
|
||||
* [JMAP](#proscons-jmap)
|
||||
* [Custom REST API](#proscons-custom)
|
||||
|
||||
### <a id="proscons-libregraph"/>LibreGraph
|
||||
|
||||
[LibreGraph](https://github.com/opencloud-eu/libre-graph-api) is an API specification that is heavily inspired by and based on [Microsoft Graph](https://developer.microsoft.com/en-us/graph), of which it is a partial implementation, but also with modifications where necessary.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
GET /v1.0/me/messages?$select=sender,subject&$count=50&$orderby=received
|
||||
```
|
||||
|
||||
#### Good
|
||||
|
||||
* is already in use as the API for OpenCloud Drive operations, with a small stack to use it in the OpenCloud Web UI
|
||||
* provides an API and data model that has already been thought out and used in production (albeit with only few different implementations)
|
||||
|
||||
#### Neutral
|
||||
|
||||
* does not have to follow the Microsoft Graph API, can be customized to our own needs, but in which case it becomes doubtful that there is any benefit in mimicking the Graph API in the first place if we diverge from it
|
||||
* there is no compatibility benefit
|
||||
* the only MUA that uses the Microsoft Graph API is Microsoft Outlook, and it is not a goal to support Microsoft Outlook as a MUA beyond standard IMAP/SMTP/CalDAV/CardDAV services (and that would be Microsoft Graph, not LibreGraph nor any customizations we would require)
|
||||
* we will not implement all of the Microsoft Graph API
|
||||
* we will not implement parts of the Microsoft Graph API as-is either, but will require to make modifications
|
||||
* if there is a requirement for considering that API as a public API for third party integrators, then the API also needs to be documented, maintained, versioned, and kept stable as much as possible (this is neutral because it is a requirement that exists with every option)
|
||||
|
||||
#### Bad
|
||||
|
||||
* not an easy API to implement
|
||||
* although we have libraries that take care of some of the more complex parts, such as parsing [OData](https://www.odata.org/) expressions
|
||||
* really only easy to use when backed by a relational database and an object relational mapping framework using [ASP.NET](https://dotnet.microsoft.com/en-us/apps/aspnet) or [JPA](https://en.wikipedia.org/wiki/Jakarta_Persistence)/[Hibernate](https://hibernate.org/)
|
||||
* its data model and peculiar interpretation of REST are really not [idomatic](https://en.wikipedia.org/wiki/HATEOAS) at all, and are clearly the result of reverse engineering the capabilities of Microsoft SQL Server and Exchange into a "standard" from the back, and then Microsoft Outlook's features and capabilities from the front
|
||||
* not tailored to our needs
|
||||
* we will most probably have a lot of cases in which we have to twist the Graph API to express what the UI needs
|
||||
* will require using complex filters, which then require complex parsing in the backend in order to translate them into JMAP
|
||||
* as opposed to directly using an expressive and maximally matching API in the first place
|
||||
* we are likely to encounter use-cases that are not covered by the Graph API (especially due to our resource linking approach)
|
||||
* does not support multiple accounts per user
|
||||
* would require the addition of an account parameter, as a query parameter or as part of the path, which would make every URL in the API incompatible with Microsoft Graph
|
||||
* more implementation effort than JMAP
|
||||
* the JMAP RFCs already provides a data model, and we would end up converting between them all the time, with incompatibilities (Graph has attributes JMAP doesn't, and the other way around)
|
||||
* possibly (probably?) more implementation effort than a custom REST API, due to its complexity
|
||||
|
||||
#### Decision Drivers
|
||||
|
||||
* UI Driven
|
||||
* some members the OpenCloud Web Team strongly prefers not to use LibreGraph due to its complexity and to the fact that we would have to reftrofit operations into an existing API that was designed by a third party
|
||||
* one upside is that there is already a client stack for performing LibreGraph operations, which could be reused to some degree for the Groupware APIs as well; it does not amount to all that much code though
|
||||
* Economic Awareness
|
||||
* more complexity and more effort as the other options due to the inherent complexity of the specification
|
||||
* a data model is already specified in full, which might save us some time on that front
|
||||
* although probably not really either since the actual data model we will work with on the backend is prescribed by JMAP, and we will only be looking to map attributes betsween JMAP and LibreGraph
|
||||
* the data model is not necessarily thorougly documented either, which will leave room for interpretation, also due to incompatibilities between JMAP and Graph
|
||||
* there will be attributes that are defined in JMAP and that we will receive from Stalwart that will not have a corresponding attribute in Graph (or be a list of values as opposed to a single value), and those will require to either lose some data by squashing it into the Graph data model, or extending the Graph data model which renders us incompatible with it
|
||||
* Efficiency
|
||||
* since the API is not tailored to our needs, we are much more likely to end up performing multiple roundtrips for single high level operations
|
||||
* Third Party Consumption
|
||||
* for some of the operations, we could point to the Microsoft Graph documentation, although that would not make for a great experience either, we would probably need to replicate it
|
||||
* our deviations and extensions will have to be maintained just like the other options
|
||||
* LibreGraph doesn't help with API stability either since
|
||||
* we don't implement all of it, and need to document what we implement and what we don't,
|
||||
* won't be compatible either due to modifications (additional parameters, unsupported parameters, different interpretations),
|
||||
* and will just as equally need to evolve it as the other options, requiring the documentation of changes as well
|
||||
* will be required to be maintained as a public API
|
||||
* documentation
|
||||
* LTS
|
||||
* versioning
|
||||
|
||||
### <a id="proscons-jmap"/>JMAP
|
||||
|
||||
[JMAP (JSON Meta Application Protocol)](https://jmap.io/spec.html) is a set of specifications that are codified in RFCs:
|
||||
|
||||
* [RFC 8620](https://tools.ietf.org/html/rfc8620): core JMAP protocol
|
||||
* [RFC 8261](https://tools.ietf.org/html/rfc8621): JMAP Mail
|
||||
* [RFC 8887](https://www.rfc-editor.org/rfc/rfc8887.html): JMAP subprotocol for WebSocket
|
||||
* [RFC 9404](https://www.rfc-editor.org/rfc/rfc9404.html): JMAP Blob Management Extension
|
||||
* [RFC 9425](https://www.rfc-editor.org/rfc/rfc9425.html): JMAP Quotas
|
||||
* [RFC 9553](https://www.rfc-editor.org/rfc/rfc9553.html): uses JSContact
|
||||
* [RFC 8984](https://www.rfc-editor.org/rfc/rfc8984.html): uses JSCalendar
|
||||
|
||||
of which some are still in development at the time of writing:
|
||||
|
||||
* [JMAP Contacts](https://jmap.io/spec-contacts.html)
|
||||
* [JMAP Calendars](https://jmap.io/spec-calendars.html)
|
||||
* [JMAP Sharing](https://jmap.io/spec-sharing.html)
|
||||
* [JMAP Tasks](https://jmap.io/spec-tasks.html)
|
||||
|
||||
To exemplify the JMAP protocol, the following code block is a JMAP request that
|
||||
|
||||
* fetches the 30 last received emails from a mailbox (folder)
|
||||
* the threads of those emails
|
||||
* email metadata of all of those threads, including a preview
|
||||
|
||||
<details open>
|
||||
<summary>Click here to toggle the display of this example.</summary>
|
||||
|
||||
```json
|
||||
[[ "Email/query", {
|
||||
"accountId": "ue150411c",
|
||||
"filter": {
|
||||
"inMailbox": "fb666a55"
|
||||
},
|
||||
"sort": [{
|
||||
"isAscending": false,
|
||||
"property": "receivedAt"
|
||||
}],
|
||||
"collapseThreads": true,
|
||||
"position": 0,
|
||||
"limit": 30,
|
||||
"calculateTotal": true
|
||||
}, "0" ],
|
||||
[ "Email/get", {
|
||||
"accountId": "ue150411c",
|
||||
"#ids": {
|
||||
"resultOf": "0",
|
||||
"name": "Email/query",
|
||||
"path": "/ids"
|
||||
},
|
||||
"properties": [
|
||||
"threadId"
|
||||
]
|
||||
}, "1" ],
|
||||
[ "Thread/get", {
|
||||
"accountId": "ue150411c",
|
||||
"#ids": {
|
||||
"resultOf": "1",
|
||||
"name": "Email/get",
|
||||
"path": "/list/*/threadId"
|
||||
}
|
||||
}, "2" ],
|
||||
[ "Email/get", {
|
||||
"accountId": "ue150411c",
|
||||
"#ids": {
|
||||
"resultOf": "2",
|
||||
"name": "Thread/get",
|
||||
"path": "/list/*/emailIds"
|
||||
},
|
||||
"properties": [
|
||||
"threadId",
|
||||
"mailboxIds",
|
||||
"keywords",
|
||||
"hasAttachment",
|
||||
"from",
|
||||
"subject",
|
||||
"receivedAt",
|
||||
"size",
|
||||
"preview"
|
||||
]
|
||||
}, "3" ]]
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### Good
|
||||
|
||||
* flexible protocol that can easily be implemented by clients
|
||||
* potentially does not require implementation efforts on the backend side
|
||||
* would obviously support the full potential of JMAP and Stalwart
|
||||
* we could potentially extend JMAP with our own data models and operations based on the [JMAP Core Protocol](https://jmap.io/spec-core.html), possibly even propose them as RFCs
|
||||
* we can start with JMAP request objects that contain only a few or even only one JMAP methods (indicated by the [maxCallsInRequest capability](https://datatracker.ietf.org/doc/html/rfc8620#section-2)), allowing more calls as we need
|
||||
* clients could implement the funtionality they need using multiple requests in the beginning, then we implement missing functionality on the server
|
||||
* this would allow us to speed up requests that we need while at the same time giving clients the ability to make any necessary individual calls
|
||||
* probably only a partially useful approach since chaining JMAP requests is necessary for even the most mundane operations, to avoid the inefficiency of multiple roundtrips
|
||||
|
||||
#### Neutral
|
||||
|
||||
* the [existing JMAP specifications](https://jmap.io/spec.html) will not cover 100% of the Web UI API needs (e.g. configuration settings[^config], [resource linking](./0003-groupware-resource-linking.md), ...), but that does not prevent us from implementing additional custom APIs, either as non-JMAP REST APIs, or as extensions of JMAP
|
||||
* we would need to gauge whether JMAP communication
|
||||
* should occur directly between the OpenCloud UI and Stalwart,
|
||||
* or whether an OpenCloud Groupware service should be used as an intermediary and as an [anti-corruption layer](https://ddd-practitioners.com/home/glossary/bounded-context/bounded-context-relationship/anticorruption-layer/)
|
||||
* if there is a requirement for considering that API as a public API for third party integrators, then the API also needs to be documented, maintained, versioned, and kept stable as much as possible (this is neutral because it is a requirement that exists with every option)
|
||||
|
||||
[^config]: although Stalwart will most likely have a [JMAP API for application configuration settings as well](https://matrix.to/#/!blIcSTIPwfKMtOEWcg:matrix.org/$CD9C6IZN28bbmN0Arb_Y-RapgsS4XqAqnDgf15yJahM?via=matrix.org&via=mozilla.org&via=chat.opencloud.eu)
|
||||
> Message from [Mauro](https://github.com/mdecimus):
|
||||
>
|
||||
> Hi everyone, I'm curious what you think about standardizing a simple protocol/extension for users to easily manage certain account settings directly from their email clients. For instance, such a protocol could handle:
|
||||
>
|
||||
> * Passwords, app passwords, and MFA settings
|
||||
> * Locale preferences
|
||||
> * Timezone configuration
|
||||
> * Basic email forwarding (without needing custom Sieve scripts)
|
||||
> * Vacation/auto-responses
|
||||
> * Blocking specific email addresses
|
||||
> * Spam reporting (though not strictly a setting)
|
||||
> * Calendar-related preferences
|
||||
> * Encryption-at-rest settings
|
||||
> * Mail auto-expunge policies
|
||||
> * ... and potentially more.
|
||||
>
|
||||
> My initial thought is to implement this as a JMAP extension rather than inventing another protocol similar to ManageSieve, which feels somewhat like a "Frankenstein" IMAP extension.
|
||||
>
|
||||
> Many mailbox providers already offer some or all of these settings through their web interfaces, but a standardized JMAP-based extension could let users adjust these directly within their preferred email clients or via APIs.
|
||||
|
||||
#### Bad
|
||||
|
||||
* potentially bad: most probably too flexible for its own good, as it makes it difficult to reverse-engineer the high-level meaning of a set of JMAP requests in order to capture its semantics, e.g. to implement caching or reverse indexes for performance
|
||||
* since the OpenCloud Drive backends use the LibreGraph API, using a JMAP based API for Groupware bears the risk of having multiple APIs to do the same thing, which we need to be careful about, and avoid if possible
|
||||
|
||||
> [!NOTE]
|
||||
> This seems like a mild "bad" item, but the risk risk here is significant: if it turns out that we need to capture the semantics of API requests to perform additional operations (e.g. caching or indexing for performance reasons, or to decorate the data from Stalwart with information from other services), then we would have to re-implement the whole API as JMAP is too complex to parse to extract semantics from.
|
||||
|
||||
#### Two Approaches
|
||||
|
||||
There are two approaches as to how to implement our protocol based on JMAP:
|
||||
|
||||
* either our clients must split JMAP operations and send some to Stalwart, and others to the Groupware backend (depending on which endpoint is in charge of which API)
|
||||
* or our clients send all the JMAP operations to the Groupware backend, which is then in charge to relay JMAP commands that are to be handled by Stalwart to Stalwart
|
||||
|
||||
##### Directly to Stalwart
|
||||
|
||||
If the OpenCloud UI Client communicates directly with Stalwart (using JMAP), then
|
||||
|
||||
* good: we don't need to implement any sort of "bridge" in the OpenCloud Groupware service (although the implementation effort is likely to be low)
|
||||
* good: we avoid an additional hop in the network, gaining on performance and potentially on throughput
|
||||
* bad: it will have to perform additional API requests for data and features that are not provided by Stalwart with the OpenCloud Groupware service (e.g. [Resource Linking](./0003-groupware-resource-linking.md)) as well, which is likely to lead to an increase in the number of network roundtrips
|
||||
* bad: would be unable to extend the protocol with OpenCloud Groupware specific models and data
|
||||
* bad: would be unable to implement caching or similar performance improvements if necessary
|
||||
* bad: prevents us from implementing infrastructure features that are not present in Stalwart and might never be in the way we would need them, e.g. sharding across multi-site redundancy
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph clients
|
||||
ui(OpenCloud UI)
|
||||
muas(Other<br>MUAs)
|
||||
end
|
||||
subgraph Backend
|
||||
subgraph OpenCloud
|
||||
direction TB
|
||||
groupware("OpenCloud<br>Groupware")
|
||||
drive("OpenCloud<br>Drive")
|
||||
end
|
||||
stalwart(Stalwart)
|
||||
end
|
||||
subgraph Storage
|
||||
drive_storage[(drive<br>storage)]
|
||||
stalwart_metadata[(metadata<br>storage)]
|
||||
stalwart_storage[(object<br>storage)]
|
||||
end
|
||||
ui x@==>|JMAP|stalwart
|
||||
x@{ animate: true }
|
||||
ui y@==>|JMAP or REST|groupware
|
||||
y@{ animate: true }
|
||||
ui-->|Graph|drive
|
||||
muas-->|IMAP,SMTP,*DAV|stalwart
|
||||
groupware-->drive
|
||||
groupware-->|JMAP|stalwart
|
||||
drive-->drive_storage
|
||||
stalwart-->stalwart_metadata
|
||||
stalwart-->stalwart_storage
|
||||
```
|
||||
|
||||
##### Groupware intermediary
|
||||
|
||||
Alternatively, if the OpenCloud UI Client exclusively communicates with the OpenCloud Groupware service (using JMAP), then
|
||||
|
||||
* good: the OpenCloud Groupware service acts as a anti-corruption layer, which would allow us to
|
||||
* implement caching and similar performance improvement measures if necessary (e.g. reverse indexing of costly data)
|
||||
* implement infrastructure features that are not present in Stalwart and might never be in the way we would need them, e.g. sharding across multi-site redundancy
|
||||
* extend the JMAP protocol
|
||||
* good: it enables us to minimize network roundtrips between the OpenCloud UI Client and the OpenCloud Groupware backend as there is no need to perform additional requests elsewhere
|
||||
* bad: we have an additional intermediary hop that "just" relays operations to Stalwart most of the time
|
||||
* due to Go HTTP stack limitations (lack of zero-copy asynchronous I/O),
|
||||
* that might incur a cost of "needlessly" copying data in memory
|
||||
* as well as performing blocking I/O (at the very least since JMAP requests first need to be read in full by te OpenCloud Groupware before they then can be sent to Stalwart more or less as-is, and the same applies to the responses)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph clients
|
||||
ui(OpenCloud UI)
|
||||
muas(Other<br>MUAs)
|
||||
end
|
||||
subgraph Backend
|
||||
subgraph OpenCloud
|
||||
direction TB
|
||||
groupware("OpenCloud<br>Groupware")
|
||||
drive("OpenCloud<br>Drive")
|
||||
end
|
||||
stalwart(Stalwart)
|
||||
end
|
||||
subgraph Storage
|
||||
drive_storage[(drive<br>storage)]
|
||||
stalwart_metadata[(metadata<br>storage)]
|
||||
stalwart_storage[(object<br>storage)]
|
||||
end
|
||||
ui y@==>|JMAP|groupware
|
||||
y@{ animate: true }
|
||||
ui-->|Graph|drive
|
||||
muas-->|IMAP,SMTP,*DAV|stalwart
|
||||
groupware-->drive
|
||||
groupware-->|JMAP|stalwart
|
||||
drive-->drive_storage
|
||||
stalwart-->stalwart_metadata
|
||||
stalwart-->stalwart_storage
|
||||
```
|
||||
|
||||
#### Decision Drivers
|
||||
|
||||
* UI Driven
|
||||
* the UI team did not express any particular preference for this option, but the JMAP protocol is simple to implement on any client
|
||||
* Economic Awareness
|
||||
* there would be less of a need to develop an API, but that doesn't put much into the balance
|
||||
* developing a generic inbound JMAP command processing engine that is capable of resolving backreferences with requests that can be sent out to different backends (Stalwart, Drive, Groupware, OpenTalk, ...) seems risky in terms of complexity, also since Go doesn't have much of a [well-supported Reactive framework](https://github.com/ReactiveX/RxGo)
|
||||
* Efficiency
|
||||
* the ability of the JMAP protocol to chain multiple low-level commands provides for a very efficient way to compose higher-level operations without the need for multiple round-trips
|
||||
* Third Party Consumption
|
||||
* for some of the operations, we could point to the JMAP documentation and RFCs, although that would not make for a great experience either, we would probably need to replicate it
|
||||
* our protocol extensions will have to be maintained just like the other options
|
||||
* will be required to be maintained as a public API
|
||||
* documentation
|
||||
* LTS
|
||||
* versioning
|
||||
|
||||
### <a id="proscons-custom"/>Custom REST API
|
||||
|
||||
A custom REST API would implement the resources and semantics as they are needed by the UI, and would be strongly if not fully UI-driven.
|
||||
|
||||
The data model should remain close or equal to JMAP's, to avoid data loss by converting back and forth.
|
||||
|
||||
We might look into existing specifications for formatting JSON payloads, such as [JSON:API](https://jsonapi.org/) or partial ones such as such as [JSON-LD](https://json-ld.org/) for relationships between resources, but this is currently outside of the scope of this ADR.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph clients
|
||||
ui(OpenCloud UI)
|
||||
muas(Other<br>MUAs)
|
||||
end
|
||||
subgraph Backend
|
||||
subgraph OpenCloud
|
||||
direction TB
|
||||
groupware("OpenCloud<br>Groupware")
|
||||
drive("OpenCloud<br>Drive")
|
||||
end
|
||||
stalwart(Stalwart)
|
||||
end
|
||||
subgraph Storage
|
||||
drive_storage[(drive<br>storage)]
|
||||
stalwart_metadata[(metadata<br>storage)]
|
||||
stalwart_storage[(object<br>storage)]
|
||||
end
|
||||
ui y@==>|REST|groupware
|
||||
y@{ animate: true }
|
||||
ui-->|Graph|drive
|
||||
muas-->|IMAP,SMTP,*DAV|stalwart
|
||||
groupware-->drive
|
||||
groupware-->|JMAP|stalwart
|
||||
drive-->drive_storage
|
||||
stalwart-->stalwart_metadata
|
||||
stalwart-->stalwart_storage
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
GET /groupware/startup/1/?mails=50
|
||||
```
|
||||
|
||||
#### Good
|
||||
|
||||
* completely tailored to the needs of the OpenCloud UI
|
||||
* a higher-level API allows for easily understanding the semantic of each operation, which enables the potential for keeping track of data in order to implement reverse indexes and caching, if necessary to achieve functional or performance goals, as opposed to using a lower-level API such as JMAP which is maximally flexible and difficult to reverse-engineer the meaning of the operation and data
|
||||
* can also be tailored to the capabilities of JMAP without exposing all of its flexibility
|
||||
* provides the potential for expanding upon what JMAP provides
|
||||
* would support the full potential of JMAP and Stalwart since the API would be designed accordingly
|
||||
* allows learning how to use and cache individual JMAP method call responses, allowing to make a better decision in the future if JMAP should be used by clients
|
||||
|
||||
#### Neutral
|
||||
|
||||
* if there is a requirement for considering that API as a public API for third party integrators, then the API also needs to be documented, maintained, versioned, and kept stable as much as possible (this is neutral because it is a requirement that exists with every option)
|
||||
|
||||
#### Bad
|
||||
|
||||
* only partially follows any standards (REST, JSON, JMAP for data models)
|
||||
* requires designing the API from scratch, as opposed to using the Graph API which already prescribes one
|
||||
* although it probably makes sense to re-use the data model of JMAP, which is prescribed in RFCs, also to avoid data loss and copying things around needlessly
|
||||
* since the OpenCloud Drive backends use the LibreGraph API, using a custom REST API for Groupware bears the risk of having multiple APIs to do the same thing, which we need to be careful about, and avoid if possible
|
||||
|
||||
#### Decision Drivers
|
||||
|
||||
* UI Driven
|
||||
* favoured solution for the OpenCloud Web UI team
|
||||
* Economic Awareness
|
||||
* designing a new custom API is not much effort since it is UI requirements driven
|
||||
* maintaining a new custom API or JMAP extensions is not more effort either, since the exact same thing needs to be done with LibreGraph, as it will have numerous exceptions and will require documenting those, as well as which parts of the Microsoft Graph API are implemented and which aren't
|
||||
* Efficiency
|
||||
* the most efficient approach since it is tailored to what is actually needed for the OpenCloud UI, which will allow us to reduce the roundtrips to a minimum
|
||||
* Third Party Consumption
|
||||
* a custom API will be required to be maintained as a public API
|
||||
* documentation
|
||||
* LTS
|
||||
* versioning
|
||||
52
docs/adr/0008-configuration-settings.md
Normal file
52
docs/adr/0008-configuration-settings.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
status: proposed
|
||||
date: 2025-07-07
|
||||
author: Pascal Bleser <p.bleser@opencloud.eu>
|
||||
decision-makers:
|
||||
consulted:
|
||||
informed:
|
||||
title: "Groupware Configuration Settings"
|
||||
template: https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md
|
||||
---
|
||||
|
||||
* Status: draft
|
||||
|
||||
## Context
|
||||
|
||||
User Preferences need to be configurable through the UI and persisted in a backend service in order to be reliably available and backed up.
|
||||
|
||||
Such configuration options have default values that need to be set on multiple levels:
|
||||
|
||||
* globally
|
||||
* by tenant
|
||||
* by sub-tenant
|
||||
* by group of users
|
||||
* by user
|
||||
|
||||
Some options might even be client-specific, e.g. differ between the OpenCloud Web UI on desktop and the OpenCloud Web UI on mobile.
|
||||
|
||||
Furthermore, some options might be enforced and may not be overridden on every level (e.g. only globally or by tenant, by not modifiable by users.)
|
||||
|
||||
Ideally, the configuration settings have an architecture that permits pluggable sources.
|
||||
|
||||
This level of necessary complexity has a few drawbacks, the primary one being that it can become difficult to find out why a user sees this or that behavior in their UI, and thus to trace down where a given configuration setting is made (globally, on tenant level, etc...). It is thus critical to include tooling that allows to debug them.
|
||||
|
||||
## Considered Options
|
||||
|
||||
TODO
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
TODO
|
||||
|
||||
### Consequences
|
||||
|
||||
TODO
|
||||
|
||||
### Confirmation
|
||||
|
||||
TODO
|
||||
|
||||
## Pros and Cons of the Options
|
||||
|
||||
TODO
|
||||
Reference in New Issue
Block a user