Email addresses and folders

[Home] (https://github.com/Structural/conversate/wiki) > [Design Write-ups] (https://github.com/Structural/conversate/wiki/Design-Writeups)

---

This is an attempt to document a minimum but complete-for-critical-tasks feature-set for email. Anything in this document is still debatable. Anything that is definitely unresolved should be marked tbd.

User Story

As a Water Cooler user, I want to be able to converse smoothly with my WC contacts, as well as other people who are not as tech savvy (or who I might only need to converse with on one or a few occasions) and therefore aren't using WC yet. I am aware of the social burden of asking people to sign up for a service and I do not want to be that guy unless I really think they're going to like WC and they would get a lot out of using it.

Features

For the sake of this story, assume that sending messages in and out of a conversation works just fine.

1. Sending email from my root identity account, ex: joe@amce.edu
2. Receiving email to my root identity email address, ex: joe@amce.edu
3. Receiving email to 2nd, a non-root-identity email address joe@eng.acme.edu
4. Receiving email to a WC email address that I create ex: eng-102-project@mail.watercooler.io
5. Managing a high volume of email coming into Water Cooler

Sending email from a root identity account

• As soon as a user has signed up and verified their email address, sending messages (which always occurs in the context of a conversation) should be possible.

Sending email from my root identity account, ex: joe@amce.edu

• Once a user has verified their email address, we can easily offer to set up a forwarding situation (because a user's root-identity email address is special, it might make sense to be able to configure this from both a settings/profile page, and the user's default folder inspector, tbd)

• joe@acme.edu's default folder could have the email address joe-at-acme.edu@watercooler.io generated (because he has verified ownership of it) and he would would have instructions for forwading some or all of his existing mail into this folder if he so desires. (Depending on Joe's email volume, this might actually suck. See managing high volume for caveats).

• If technically possible and not problematic, we might prevent mail from being sent to joe-at-acme.edu@watercooler.io unless it is forwarded through joe@acme.edu. However, this may be dangerous in terms of a false negative rate that makes the inbox unreliable for Joe. (perhaps we would filter mail we beleived was directly sent, but not drop it on the floor. tbd)

Receiving email to 2nd, a non-root-identity email address joe@eng.acme.edu

This example uses an academic context, but the logic should hold the same for a corporate shared address. If any differences arise, please note them

• If Joe has access to a second email account (either his or shared, but one he can verify) then he would able to add it as a secondary inbox.

• Once verified, we would create a special user account with some sort not-a-real-person:true flag set. This account would somehow be bound to Joe's and administered as such. He would not need to log in as this real user and in order to configure things. Access to and control over secondary accounts could be shared similar to sharing folders. details tbd.

• The default folder for joe@eng.acme.edu would be shared with Joe, and he would not be able to leave the folder in the traditional way.

• Any WC user who has joe@eng.amce.edu` in their contact list would be able start a WC conversation with that user account and it would be in that folder.

• There are some more edge cases to consider, for example: shared folders of joe@eng.acme.edu that joe is not a participant of would be dubious because convos could be started in them without joe's knowledge. It may be prudent to insure that any folder of a not-a-real-user user is shared with at least one person who has administration rights over the not-a-real-user user.

• Joe would need an indicator that a new conversations have been started with joe@eng.acme.edu. One way to handle this would be that any messages in the default folder which do not have a real human folder participant attached would be highlighted in a way similar to (or the same as, tbd) the general unread message indicators. This would be true for all humans with access to the folder.

Receiving email to a WC email address that I create ex: eng-102-project@mail.watercooler.io

• If WC users want to create email endpoints, but do not have a forwarding address that they wish to use, then we may optionally create unique endpoints for them. In order to minimize the degree to which we are "just running an regular email provider", we may want to make these email endpoints work differently, or charge for them to both offset their cost and/or disincentivize their general usage.

• These accounts would work basically the same as the above joe@eng.acme.edu, but without the verification step and with any of our imposed limits.

• Anyone may send email to eng-102-project@mail.watercooler.io directly.

Examples:

• sa-dev@mail.watercooler.io (shared with the dev team)
• fall-chemistry-201-lab-group22@mail.watercooler.io (shared with that group)
• sa-dev-jira@mail.watercooler.io (shared with whoever needs jira notifications)

We should probably do something polite like autogenerate a vCard that we can blast out for email users.

Managing a high volume of email coming into Water Cooler

There will be limitations to receiving arbitrary email into water cooler. We've already seen that auto-generated notification mail (ex: JIRA notifications, paper-trail, likely WC messages if someone was receiving them back into WC) ends up filling up the folder pretty quickly.

An attempt at the general problem:

Messages which are not conversational in nature do not map well into Water Cooler.

A naive attempt at a solution:

• Allow certain contacts (perhaps at the per-folder level) to be specified as bots or notification-addresses or something. Messages from these address are not treated (by the UI, actually data model tbd) as new conversations but instead appear in something like a single conversation.

• For example, the sa-dev-notifications@mail.watercooler.io folder might have only a few conversations: Lobby, JIRA, jenkins, etc.

• Human users would then have the ability to break specific messages out in order to discuss them. So thlist may actually be: Pinned: Lobby, JIRA, Jenkins; My Convos: (the 5 branch convos I've disucsed); Shared: lots of other convos that other people are discussing.

• Branched convos that become more important (ex: 1 failing test vs. the server is down) could then be moved by humans into other folders.

A separate naive attempt at a solution:

• Allow messages from specific contacts to be filtered into either other folders, or something like sub-folders or sub-labels.