---
# System prepended metadata

title: SnapMail tech specs

---

# SnapMail tech specs

## Functional Overview

Remake SnapMail with Holochain.

### Use Case

In at least some cases this is also going to eliminate the idea of users, and focus more on either location or device. Of course that could accommodate users, but I think at least our lead use case at this point has non-user stations as nodes on SnapMail.

### Key features
* P2P asynchronous messaging (send and receive messages even when offline)
* Store & organize received messages (folders, icon/type, search)
* Compose and read messages (spellchecker)
* Contact management (groups)
* Message templates
* Reminders & autoreplies
* Snap & SnapBacks

### *Outstanding functional questions*

* Web or desktop happ?
* Supported languages?
* Revenue model tech considerations? (subscription, premium features...)
* Private DHTs?
* HasBeenRead status? => yes
* "server volunteering"?  => no
* system tray?

other questions:
- deadline
- UX + design worm
- holochain version (dht-triggers, versioning, etc)

## Tech overview

### UI (web)
- [Electron + webcomponent + Material](https://github.com/gaurav-nelson/material-web-components-electron-starter)
- https://vaadin.com/

Copy gmail UX and use Material + Vue.js
> EHB: Investigate using: WebComponents and [litelement](https://lit-element.polymer-project.org/)
> SSC: agree we should copy something, or parts of multiple somethings, and I am not clear that should be gmail; my belief is that this needs to be exceptionally lightweight, even at the loss of functionality and features, to appeal to much of the market that SnapMail is a much better alternative to email; landing in a lighter touch point-to-point messaging space (think radio handset?) seems where we want to be to differentiate from email (gmail) and chat (Slack/Mattermost, Telegram, text/SMS/WhatsApp/etc.).  In at least some cases this is also going to eliminate the idea of users, and focus more on either location or device.  Of course that could accommodate users, but I think at least our lead use case at this point has non-user stations as nodes on SnapMail.

`hc_client` is used for data binding.
All settings and ui preferences are stored in a source chain entry (which makes it browser agnostic).

### Data Layer

#### Messages
An agent only stores in it's source chain the messages it sends and receives.
It will also store reminders and autoreplies it has sent on behalf of other agents (see [Reminders](https://hackmd.io/nCYcnsmETwSdVLkXow6bNg#Reminders)).
If recepient is online, message is sent directly with direct n2n communication.
Asynchronous messaging is done by encrypting and storing messages and attachments in *weekly* [Throwaway DHTs](https://forum.holochain.org/t/throwaway-dht/1098).
A Message is first modeled as an `OutMessage` in the senders source chain.
`OutMessage` is stored in the DHT and a link to it is added at the recepient's agentID address.
Once the recepient is online it looks up all the links and retrieves the messages. They are converted as `InMessage` on the recepient's source chain. On the DHT the `OutMessage` is marked `deleted` (or `read`?).
Every *week* a new DHT is created and DHT agents migrate only the none-deleted data.

#### Attachments
An attachment is a source-chain entry holding binary data.
Over time this might be too heavy for the source-chain, several strategies could be looked into:
 - Weekly dna-version/chain migration and purge sent attachments.
 - Move attachments to some other p2p service as discussed [here](https://forum.holochain.org/t/large-files/1519) (IPFS, Storage Zome...)

#### Reminders
Reminders are stored on the DHT and foundable by links at one (or many) known anchors. Any agent will periodically check reminders on the DHT. If the time condition is met, the agent will generate a message out of the reminder and store it on the DHT. The recepient will see it on its next inbox check. Time calculation is based on agent's local time, peers validate with there own local time.
Reminder checking interval can be determined in real-time depending on how many peers are online.

Autoreplies can be handled in a similar fashion.

#### Snap & SnapBacks

Snap can be done only with browser notifications.
SnapBacks are simple source chain entries.

## Roadmap

First several *Proof of concepts* must be tested:
- PoC v1: Basic UI + N2N messaging
- PoC v2: Asychronous messaging
- PoC v3: Throwaway DHT + migration
- PoC v4: Reminders


| Feature  | Prototype | MVP | V2 | V3 |
| -------- | -------- | -------- |-- |-- |
| Supported languages     | english     | english     |english| all latin |
| Message type | string | string | html | html |
| Message Status| no | yes | yes | yes |
| Filebox | *system* folders | custom folders | custom subfolders | custom subfolders |
| Compose | text box | text box  | WYSIWYG editor | + spell checking | 
| Contacts| single list | groups| sharable groups | subgroups|
| Reminders| none | once (delayed send) | periodic | periodic & aperiodic|
| Snap | no | yes | snapbacks | sharable snapbacks |
| Attachments | no | source-chain | deletable | deletable |
| Message templates| no | no | yes | yes |
| Search | subject match | subject + content keyword | indexing | adv. search|
| autoReply| no | no | yes | yes|
| Export| none | pdf | html | csv & JSON |
| Import/Replay| none | csv & JSON | csv & JSON | csv & JSON |







## discussion 2020-03-03

Pattern from customer centric view


quick to customer ; release process


Templates: tab between to colons ; like a form (streamscape proto)

web components instead of vue.js and electron

asynchronous and attachments: transient data to neighbors

no asynchronous message or small only

160k size limit

hasbeenRead to plan but not in the mvp

background research

Toggl routine: track time during month ; send invoice at end of month ;
HBE pays 15 to 30 days after.


# Design

{%hackmd -Y3hW9aqS4SU15OBPfTK1w %}

#### Check if Message has been read

```
bool has_been_read = 'pendings' link count == 'receipts' link count
```

When adding receipt link, must validate that there is a pending link or that receipt is authored by one of the receipients and that there are no other valid receipt link from that author.


# August

RSM time
Add a way to retrigger an attachment
Standalone

Like july: 20 + more (30h)

beeps
