meowlib/doc/protocol.tex

\documentclass{article}
\usepackage{fetamont}
\begin{document}
\title{
    \textffm{Meow} messaging protocol}
\author{Author
   \texttt{meow@redroom.link}}
\date{\today}

\maketitle

\begin{abstract}

    
    The \textffm{Meow} protocol is a privacy driven instant messaging protocol. 
That protocol might be used for creating secure and distributed chat services or allowing machine to machine communication.
This document describes the services provided by the protocol, the messaging structures and the transport protocols that might be used.
\begin{quote} 

    \centering 
    \emph{"Nous ne vivrons pas d'utopie collective, nous arrivons trop tard, le grand marché est déjà là.
Nous devons élaborer des stratégies de survie et de contamination, par la prolifération d'utopies privées, cryptées, qui se substitueront à l'ancien ordre social. 
Tout ce que je sais, c'est que nous vivons dans un monde dont on ne s'évade pas"}\\
\footnotesize{Maurice G. Dantec for NOII (1997)}
\end{quote} 
\end{abstract}


\section{Services}
\subsection{Unregulated identities}
The only requirement to get a valid \textffm{Meow} identity is to generate a user key pair.
No phone number or email check will be performed, unlike main instant messaging protocols, there is no central administration.

\subsection{Fine grained privacy control}

\subsubsection{Trustable server based communication}
Like most widely available messaging softwares, (Whatsapp, Signal, Viber, Telegram...), \textffm{Meow} provides a simple server based messaging.
The main difference is it allows to explicitly choose which server you want to use.
The server code being open source, we strongly encourage you to run your own server at home or in your company.
The server requires very few ressources and will run on any low cost single board computer.

\subsubsection{Anonymized message transfer}
\textffm{Meow} also provides an anonymizing transfer services very similar to the Tor Onion protocol, we call it the Matriochka protocol.
Any server can be used for building the transfer chain. 
Some of them might be marked as trusted.
It is strongly advised to use trusted servers as your first node and message server (the one that holds your incoming messages).

\subsubsection{Presence protocol for direct messaging}
A presence service associating your conversation keys to your IP address for direct peer to peer connection is also provided.
The presence protocol is simply activated by setting a flag in the message poll requests. 
If that flag is set, your encrypted IP will be published on the server, allowing your only your peer(s) to decrypt it and directly communicate with your terminal.

\subsubsection{Peer based privacy settings}
You might define specific communication privacy preferences for each of your contacts: 
\begin{itemize}
    \item simple server based communication allowed for Joe, 
    \item preferred direct communication with Julian, fallback to my own server, 
    \item required matriochka protocol for Edward, first node is one of my trusted servers, my message node is my own server, randomly switch from trusted server lists for others.
    \item ...
\end{itemize}
\subsection{Multiple devices support}
\textffm{Meow} allows you to be connected from multiple devices and offers chat synchronization capability.
A device might be revoqued anytime from any other one. Proof of your identity (password or other) shall be provided in order to grant device revocation.

\subsection{Adding contacts}
If you want to add a new contact, keys and uuids will be generated, then a rendez-vous card will be created.
That rendez-vous card might be sent by any trustable communication means, or preferably from hand to hand, as a file on a flash disk or a QR code.\\
In return your contact will provide the exact same data, encrypted with your public key and delivered to the address specified in the initial rendez-vous card.

\subsection{Contacts forwarding}
By using the \textffm{Meow} protocol a user won't be able to forward your contact information without your consent.
Each user knows you as a different identity, thus forwarding a known identity to another user is meaningless. Any message to that identity signed by another user than you would be discarded.


\subsection{Group conversation}
A very basic group messaging service is available. It allows to exchange group information between users. After that, a message to a group will send a copy of the message to each member.


\subsection{Emergency broadcast}
A local (server based) emergency broadcast service will be provided. It will provide the ability to send/receive broadcast messages to all users connected to the current server.


\subsection{Public networks shortage resilience}
\textffm{Meow} may run without Internet connection, either on an isolated wifi access point, or on a meshed network of wifi routers or even via serial IOT transport layers (LoRa,...)


 
\subsection{User directory service}
This service allows to restore a lost functionality of Internet historic chat services (like ICQ). You could simply set a "Free for chat" status that would allow other people to contact you, either randomly or based on a short description that you might provide.
Why providing that service while the internet is suffocating due to the abundance of social networks ?\\
Well, that option offers a few advantages :
\begin{itemize}
    \item you are still an anonymous user chatting with other anonymous users;
    \item no social network algorithm will select people that think/behave/vote/eat... just like you. Diversity makes a better world;
    \item a smaller community of users, skilled enough to operate a \textffm{Meow} chat app... that might provide a first filter;
    It's a bit like in the old times, when people had to be able to start a win98 computer, connect it to internet, then download and install ICQ...
    If you lost some time in social networks, and experienced ICQ in the 2000's, you know what I mean.
\end{itemize}

\section{Identities and keys}

\subsection{User identity}
Each \textffm{Meow} user has a unique identity. That identity is strictly private, only used to manage your own data (local encryption, devices, ...)
Let's call that one the User Key Pair (Ukp)

\subsection{Contact identity}
Each of your contacts will know you under a different identity, we'll call that one the Contact Key Pair (Ckp)
That contact Key Pair will not change once it's agreed between both peers: an initial key will be exchanged as part of the peer invitation process.
As other people might have seen your key, this means that :
\begin{itemize}
    \item none of your contacts will be able to forward your id to another person without your consent;
    \item any message to that Ckp, not signed by its associated user, will be discarded.
\end{itemize}

\subsection{Conversation encryption}
Each conversation with one of your contacts will be encrypted using an encryption keypair (Ekp) allowing cyphering your conversation.
The Ekp might be changed anytime by its owner and the new public key will be sent along the last message.

\subsection{Conversation lookup}
A contact conversation Lookup Key Pair(Lkp) is also associated with your conversation. The Lkp public key is used to identify your conversation on a server.
The private key allows you to sign your request and prove the server that you are the legitimate recipient for a message.
This Lkp can be changed anytime by its owner and the new public key will be sent along the last message. 
The Lkp and the Ekp are only changed once the change has beeen acknowledged by your contact.

\subsection{Server identity}
Each server has a Server key (Skp). That key allows you to cypher the messages that you're sending to the server.

\subsection{Device identity}
Each device is identified by a device key (Dkp) that allows you to perform secured exchanges between your devices for synchronization/revocation purposes.
Communication between devices is achieved using the same principle as the user to user communication. A device might be considered as any another user. The messages content is based on a synchronization protocol.

\section{Contact management}
\subsection{Adding a contact}
Rendez-vous card, containing : 
\begin{itemize}
    \item Your public key for that contact;
    \item An initial conversation public key for getting encrypted messages from that contact;
    \item An initial conversation uuid that you'll use to lookup for incoming messages on the servers;
    \item A list of your preferred message servers;
    \item A signature to prevent transmission of tampered data.
\end{itemize}
\subsection{Sharing a contact}
If a user wants to forward one of his contacts to you, it will be handled as a double request:
\begin{enumerate}
    \item I'm receiving a contact name, without any key
    \item 
\end{enumerate}

\section{Messaging}
\subsection{User messages}
TODO

\subsection{Server stored message}
TODO

\subsection{Matriochka message packing}
TODO

\subsection{Synchronization messages}
TODO

\section{Transport protocols}
\subsection{URLs}
Server urls do define the protocol used for communicating with the server.
Some of the protocols will be described hereafter, but that list is not exhaustive and might be extended in the future.\\
Examples of a valid url:
\begin{verbatim}
http://myserver.com
https://user:pass@myauthenticatedserver.net:8443
mqtt://mymqttserver:6203
udp://myudpserver.org:41325
serial://dev/ttyS0
\end{verbatim}

\subsection{HTTP/S}
TODO

\subsection{UDP}
TODO

\subsection{Internetless alternative routing}
TODO

\section{Server Features}
\subsection{Server catalog}
Each server will cache a list of all the servers that it is aware of.

\subsection{Antispam}

\subsection{Self defense}




\section{Backup}
\section{Recovery}

\section{Very secure devices}
You don't trust your phone ?

\section{Roadmap}
\subsection{Nations}
Beyond the scope of user directories, we plan to implement the concept of virtual Nations.
Today still, most people don't really choose the nation they live in. 


\end{document}