coi-dev / coi-specs Goto Github PK

Hi,

I live the concept of encrypted messaging over Email, but find the execution not good enough to gain adoption.

As I understand, as of today, to establish an encrypted communication, there should be a 2 ways handshake to exchange the PGP keys, as required by the AutoCrypt protocol.

From an usability and privacy point of view, it's not good.

Can't we take inspiration from QUIC and allow 0 RoundTrip Time encrypted messaging ?

https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/

If an client app sync last (n) messages , is better just to refer to the last know message?
The server has full thread info , so could add that info on behalf of the client and capability "ENABLE COI" is enabled ?

Seems there is a typo? "ammend" should certainly be "amend"

pretty unimportant - anyways: the link in the readme to https://coi-dev.org is not working, since a redirect to https://www.coi-dev.org is not working properly:

$ curl -v https://coi-dev.org
*   Trying 137.74.127.233:443...
* TCP_NODELAY set
* connect to 137.74.127.233 port 443 failed: Connection refused
* Failed to connect to coi-dev.org port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to coi-dev.org port 443: Connection refused

I hope this is the best place to leave feedback for the push spec in its current form; if not let me know where to put it.

This spec looks broadly fine. Given servers may well be implementing both, it would make a lot of sense to align the specification with JMAP where the semantics are the same, specifically:

1. Align the naming/structure of the subscription object with the JMAP PushSubscription object

   • Consider renaming "endpoint" to "url" and moving that property and the "keys" property to the top level of the object instead of in a "resource" sub-object.
   • Consider replacing "client" and "device" with "deviceClientId" – to preserve the privacy of the user, we deliberately made this an opaque id in JMAP. If not doing this, it will need to at least be discussed in the security considerations.

2. Use the same structure for the push verification object; this is a no brainer, given it's the same data. It makes sense to use the same structure as described in section 7.2.2.

3. Rather than setting the verification code at a separate path, instead update the PushSubscription object with the code (as the "verificationCode" property); if successful, the subscription is now valid (so the presence of this replaces the need for the "validated" property). This method is no better or worse than the current spec, but it does make it align closely with JMAP which seems worthwhile when there is no good reason not to.

4. Unless tied to a session-based authorisation mechanism (which it almost certainly won't), the server will want to automatically expire push subscriptions after a certain amount of time if the client does not refresh them. This spec seems to be missing that; I suggest adding it. See the "expiry" property on the PushSubscription object in JMAP. (The client refreshes in JMAP by updating this property; I would suggest something similar in IMAP.)

5. The payload for push notifications is a JSON-formatted subset of the message. JMAP Mail RFC8621 already has a well-defined structure for this, I would again suggest using it, at least for "from", "subject", "receivedAt" (internal date) or "sentAt" (for the date header in the email), and "messageId". What to do for the body ("content") is more interesting. I would suggest "preview" from the JMAP spec, but it looks like you want to be able to send text/html or something else too. The current specification is underspecified regarding what is meant to be returned here, so more discussion needed at least.

6. As a general note, the use of hyphens in JSON property names is very unusual. JMAP uses camelCase, so I would recommend using that, although snake_case is also not uncommon.

Presuming you're bringing this to IETF106, I look forward to discussing this further there or on the EXTRA mailing list.

I hope I'm not late to the party, but this definitely looks like a smaller brother of the widely used production-level software package DeltaChat (native clients for Android & iOS, electron app for Windows, *nix, macOS).

How about aligning both projects?

DeltaChat is much much more mature, is well funded with quite large user base and established developer base, so aligning both seems like a good idea.