\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 that \textffm{Meow} allows you 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 service very similar to the Tor Onion protocol, we call it the Matriochka protocol.
Any server can be used for building the transfer chain.
Random delays and random size payload padding might be set for each forwarding step, making the overall message tracking much more difficult, even for organizations having capabilities of global network surveillance.
In case of data interception on your device link, in order to prevent statistical analysis, every request might be answered with size useful data (server's known server list).
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:
\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}
\subsubsection{Resistance to device requisition / forensic}
All your contact information and discussion are encrypted on the device and password protected.
Password shall be asked on application startup and allows your identity file and contact decrytion.
That password is not recoverable, so you can't forget it, or you'll loose your whole configuration and identity.
Real security implies some constraints.
You might configure the app to save your password, but that is a security flaw.
In many authoritarian countries, you are required by law to provide your device passwords to authorities.
In a \textffm{Meow} device, you might set a specific password for some contacts.
Those contacts won't be visible when entering your main identity password.
You'll have to type their specific password in order to make them visible.
The \textffm{Meow} application will by default create a random set of fake hidden contacts and conversations.
Even in case of device storage analysis, authorities won't be able to differentiate a real hidden contact from an normal fake generated one.
It could be argued that this feature puts every user at risk, because authorities might think you're hiding something, even if you're not.
As every \textffm{Meow} user has the same constraint, users are not responsible for that. Moreover solidarity is also a requirement for real security.
\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 will be generated, then a contact card will be created.
That contact 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 a similar contact card as an answer to your invitation.
\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 restoring 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 early ages, when people had to be able to start a win98 computer, connect it to internet, then download and install ICQ...
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.
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{Server Features}
\subsection{Server catalog}
Each server will cache a list of all the servers that it is aware of.
