Pour la version française voir ici.

A Caliop service must be able to process any private exchange, incoming or outgoing, in the most safe way (restricted only by state of the art security knowledge and users preferences).

Its main interface is a web application under a still to be defined free license.

A contact is an email address, linked to whatever data is entered at creation time. These data can be extended at anytime by the user (to add name, phone, etc.), tags, keywords et categories.

An incoming message can be any kind of private exchange (with or without files attached); to allow a easy sorting process, a message type will be associated with it. According to transport and signature data available to Caliop, a confidentiality indicator is also attached to the message (the user must be able to easily understand its meaning).

By default and according to the protocol used by the message sender, a reception acknowledgement (not a reading acknowledgement) is issued (the user need to be able to disable this feature).

Spam processing is managed directly at Caliop level, but Caliop must ensure that spam-filtered messages are always available, at least for some to-be-defined time. Caliop must not entirely rely on Real-time Blackhole Lists (RBL) that it can not fully control (RBL may be used to pre-sort messages but should not be able to completely blacklist an IP).

Incoming messages sorting is done according to some predefined criteria, which can be modified by the user. These criteria include tags associated with the sender(s), message metadata (subject, sender, date, attachment file type, etc.), message type (Twitter DM, SMS, email, etc.), confidentiality level, predefined or user defined filters, and so on. When the message is encrypted (and can not be decrypted at Caliop level), content-based sorting is naturally unavailable.

Configurable filters are available to the user. A simple interface allows the user to defined the process to applied to the message according the above mentioned criterias.

Once the sort is done, the message is moved in on or more destinations (more or less similar to folders of classical webmail). A destination can be a folder (invoice, mailing lists, etc.), a shared space (images, files, etc.) a “timeline” counterpart (private, limited to some contacts), an instant messaging interface or a forum (public or private). Some of these destinations may be duplicated on some devices defined by the user (a message detected as urgent by a defined filter may be redirected to a smartphone or a tablet). This list is nor definitive, nor closed.

A destination is not unique: a same message can be distributed in an inbox as well as a an instant messaging tool, for instance.

destinations can, whenever possible, move from one kind to another: for instance a thread started in an asynchronous way (email) may, if Caliop detect a contact is online and if everybody accept it, be transformed in instant messaging or mailing lists (by adding contact to a thread, who may or not have access to thread history).

Caliop offer social tools: a user may share not only messages or contents with all or subset of its contacts, but also share a sort filter, a public key, a black list, a calendar (to allow to find a shared date for an event). This share can not be open to someone not in the user contacts.

A “Caliop account” is not limited to a single user. The Caliop account creator can decide to share it with anyone. In that case the will have access to the same tools but using their own identity (inside the account). Outgoing messages are send using the shared identity.

The search of documents is global, but can be limited according to the associated type, confidentiality level, tags, categories, or keywords.

Their may be some tools allowing managing documents: downloading (with or without removing from server), enciphereing, forwarding, definitive deletion (to be completed).

Enciphering is systematically smoothed, at all level. When creating an account, the user must easily be able to create (locally on his device) a pair of public/private key (or point to a path where his PGP key is available if it is online). Caliop must then ask him to upload his public key in order to easily encipher all or part of his messages online. Focus is given on the importance of the private key, consequences of passphrase loss/forget/

This operation may be done through a free software embedded on a usb stick, given by Caliop service et freely downloadable. This USB stick becomes the main user's private key storage support (we will advice him to copy it and store that copie in a safe place) which will allow him to access his messages from any device.

Identification on a Caliop service is done by this “certificate” embedded on the client side. Access to another Caliop service can be done by a chain of inter-Caliop certification to be defined (service association) or through an oauth in order to limit this chain.

Client side, the application always shows the state of the passphrase (in memory or not). User is encouraged to clear it as soon as it leaves the screen.

Message input is done the same way whatever its type. The same interface is used to send asynchroneous email, instant message, post in a forum, etc.

At input time the user can attach a file, choose one or more destination contact (or even create one if needed), define a subject (which will be used or not according to the message type), etc. It's only at emission time that Caliop offers, according some elements, a type for the message.

For instance, one can imagine, if destination contact is online (XMPP), to send an instant message and start a live chat. If the message is short, the phone contact data available and the radio service available, the message could be send by SMS. If multiple contact are concerned, the service may offer to create a mailing list on the fly.

In any case, Caliop offers, before sending (if it have access to the public key of contact(s)) to encipher the message. In the same spirit, electronic signature will be proposed by default for all messages type supporting it. Whenever possible enciphering will be done on the user device, through contact public key downloading, before sending the message to Caliop.

According to the message type, and when such process can be done, a symbol allow to know the message state: delivered (when), if an error has been encountered (in this case the symbol must allow to resend) and (when message has been enciphered) if destination identity can be certified.

Attached files, if the user asked so, stored on his private space on Calipo servers (they are still sent to the contact with the chosen protocol). Whenever the contact use another Caliop service, he can access them as if the sender have created a temporary shared space.

When sending a message, the user may, if he wants so, create an identity (From) which is different from his (email) normal one: the Caliop service will ensure that from now this new identity will be linked to the user account when message will be sent to it.

 
project_notes.txt · Last modified: 2014/03/05 08:39 (external edit)