> The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant.
In point of argument, it should not be relevant - beyond metadata exposure or failure to provide service. Metadata exposure is mentioned in the post, and is a rather important aspect to consider. Having service turned off when you need it also might be an important consideration depending on the threat model. If I were cabinet members planning military operations, it is quite likely that I would care about both of those.
Beyond that, the 2025 table stakes for a 'secure' messaging service are: "a totally compromised server should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages." [1]
In point of argument, it should not be relevant - beyond metadata exposure or failure to provide service. Metadata exposure is mentioned in the post, and is a rather important aspect to consider. Having service turned off when you need it also might be an important consideration depending on the threat model. If I were cabinet members planning military operations, it is quite likely that I would care about both of those.
Beyond that, the 2025 table stakes for a 'secure' messaging service are: "a totally compromised server should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages." [1]
[1] https://www.rfc-editor.org/rfc/rfc9750.html#name-delivery-se...