JMAP and sharing concepts

[Haider Smith]

Loving the momentum which is building up and excited to see JMAP inplementations in both Cyrus and Dovecot - it is less of a chicken and egg scenario now.

The one thing which remains to be discussed in the spec is how shared resources will be handled - ie. mailboxes in a 'shared' namespace, mailboxes belonging to other users, made viewable to other users in the 'other users' namespace and the same going for calendars and contacts.

Whilst different services like Fastmail, Google, Kolab al have different sharing allowances, like some across domain, and some across multi-domain, as well as others which allow a more fine-grained control to sharing like Fastmail (per-folder basis).

Essentially, with JMAP clients springing up soon, there will need to be some concept of how shared resources are handled, so that users have the choice to match whatever client to server as they please.

Whilst this could all get complicated quickly, there needs to be a common way of displaying shared objects client-side. Though different services allow for a variety for different things, there needs to be an api to manage this.

[Neil Jenkins]

This is already defined! Specifically, JMAP can return multiple accounts you have access to (e.g. your own account, and another one that has been shared with you). These may have different permissions (e.g. one may be read only). The server may choose to only return a subset of mailboxes in response to getMailboxes if an account is only partially shared (and similarly return only part of the entire contents of the account for other methods too).

JMAP doesn't define a way of setting up the sharing, as the possibilities are different for each service, as you noted, and this is not needed for clients to be able to access the shared data.

Neil.

[Haider Smith]

So JMAP clients will not be able to define sharing properties of mailbox/calendars? Will this then be restricted to service specific extensions/settings pages in web apps?

Though applications will be able to access all data, going with a per-service approach makes the assumptions that clients and servers will have a one-to-one approach, i.e. that Kube & Roundcube Next will only be used with Kolab servers, and not with Fastmail or another JMAP server, for example. Clients like Airmail, Thunderbird, etc are generic and should be able to have a great experience with all. I think there should be a common approach to setting up sharing, as such that it can be done by any client, even if some options only work on certain servers.

Allowing things to fragmented at an early stage doesn't help in convincing big adopters like Apple to build something, nor would it provide a great experience for clients like iOS/MacOS mail, if they ever get round to implementing JMAP. I don't think it would be good if JMAP ended up like the Android ecosystem. 

Just my 2p worth.

[Neil Jenkins]

On Thu, 9 Feb 2017, at 08:02 AM, Haider Smith wrote:

So JMAP clients will not be able to define sharing properties of mailbox/calendars? Will this then be restricted to service specific extensions/settings pages in web apps?

Probably. It's very server-specific what granularity is supported, and who you may share with. There's no mechanism currently in JMAP for identifying other accounts you might be allowed to share with, and adding it would be hugely complex.

Though applications will be able to access all data, going with a per-service approach makes the assumptions that clients and servers will have a one-to-one approach

Well, you would need to log into a server specific website/application to set up sharing, yes. But the custom bit does not have to do anything else.

Clients like Airmail, Thunderbird, etc are generic and should be able to have a great experience with all.

They can, in terms of accessing shared data. Setting up sharing permissions is a completely separate activity. There's no huge win from generic clients being able to do this (can you set up IMAP sharing in Airmail for example? No.)

Allowing things to fragmented at an early stage doesn't help in convincing big adopters like Apple to build something,

On the contrary, adding complicated (and sharing is always complicated) features that will see very little real-world use is a great way to put people off implementing something.

Neil.