'flow' is a communication system

=
  Conceptual Change Necessary!
 'flow' will no longer use SSL/TLS/Certificates
  because the whole certificate system is broken to death
  there is no need to keep it alife after its death.

  'flow' will receive some new security layer based on SSH and GnuPG as
  discussed at cosin2011. this requires a kind of new concept which is
  in development since the beginning of 2012.
  
  2014-07-08
  There is some new work done for developing a replacement for the SSL
  bound mechanics. A simple studie using GnuPG and Python is nearly
  working. As soon as this reaches the level of  simple functionality
  it will replace the former project to set up a new starting point.
=

  Copyright (C) 2010 Manfred Morgner manfred@morgner.com

  'flow' is free software; you can redistribute it and/or modify it under the
  terms of the GNU General Public License as published by the Free Software
  Foundation; either version 3 of the License, or (at your option) any later
  version.

  This program is distributed in the hope that it will be useful, but WITHOUT
  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  more details.

  You should have received a copy of the GNU General Public License along with
  this program; if not, write to the 
  
  Free Software Foundation, Inc.,
  59 Temple Place, Suite 330,
  Boston, MA  02111-1307  USA

  You must obey the GNU General Public License in all respects for all of the
  code used other than "OpenSSL". If you  modify this file, you may  extend
  this exception to your version of the file, but you are not obligated to do
  so. If you do not wish to do so, delete this exception statement from your
  version.

  Comments are welcome: manfred <manfred@morgner.com>



goal of the project
-------------------
'flow' will move your messages in protected mode

'your messages' means messages from you + message for you

using certificates for transport security (TLS) and content encryption, 'flow'
will enable you to exchange messages securely not only using insecure networks
but also using untrusted message exchange servers.

the system will give you near realtime and asynchronous message exchange and
message distribution capability

because all 'flow' data is secure, it may be stored anywhere for unlimited
time. so, if you lose your message or dialog history, you should be able
to recall all of it from the 'flow' server you used, given, the server stores
your messages

messages are stored encrypted at any time anywhere as long as 'flow' stores
them. so even on your system they are secure. as secure as you treat
your systems security of course.

because of the basic mechanisms of 'flow' it is not a good idea to bind it
to other social networks or similar. 'flow' is for secure and trusted 
message exchange, social networks are for fast and open message exchange.
if you use 'flow', your are interested in privacy. I can not see any reason
to compromise your and your messaging partners privacy by opening a hole in
the system.

you're in command of your messages. you dictate who will be able to
read your messages and so ensure who is going to receive them.
this way, even if the 'flow' servers you will use are not trustworthy,
it is able to supress deliveries, but not to read your messages as long
as you and your message recievers stay trustworthy (keep their secrets)

DATA MUST FLOW!


'flow' will
-----------
enable you to exchange messages even through smartphones and tablet computers
enable you to build protected groups to communicate with


for security reason 'flow' may never
------------------------------------
enable unsafe message exchange
have an official MS Windows version
get an official HTTP(S) interface
become able to exchange data with other social networks


'flow' is not 
-------------
a public social community system
a system to exchange data with public social community systems


current status
--------------
 1) Data is transported encrypted over an encrypted transport layer
 2) Client and Server are not rock stable
 3) the server is able to receive data from client and keeps it in his memory
 4) the client is able to connect to a remote server and send a message to it
 5) TLS on all your ways

next steps
----------
the client should be able to request messages from the server and reconstruct them
the client should remember some important command line information

data compression ? (only if OpenSSL supports it inherently)

compiler error messages
-----------------------
GCC believes:

system/include/environment.h:168: warning: returning reference to temporary
system/include/environment.h:171: warning: returning reference to temporary

Which is not correct, clang thinks otherwise, which is wiser. I'm not sure
if I should exclude such wrong messages and how. The best way should be to add a
compiler switch to turn off such nonsense at this point. In other situations
this warning may be correct. So it may be unwise to shut this message down
with a global compiler switch.

But is GCC realy worth feeding?