Always on internet connections are taken for granted by every one who has reliable access to these 24/7. However the traditional system (centralised server - many clients) is not suited to the environments the system will be employed in. However mesh networking is ideal because instead of investing a large amount of money into infrastructure without providing the devices that use the infrastructure is futile.

Time to get to the point now.
The system is essentially designed to operate as two seperate systems:
The system which the user interacts with to retrieve messages, send message and in general interact with the system. The other side is the infrastructure side. This layer would need to run 24/7 to act as a data forwarding node in the system. That is the purpose of the message ticker/manager and the download/upload manager.

The message ticker is responsible for message management. By this the message ticker is responsible for notifying the UI that a new message has been recieved and when the user wants to send a message invoke the appropriate actions to do so. As each member in the network is a node the message ticker has the additional responsibility to forward messages to their destination. The message ticker unlike the download/upload manager is responsible for small chunks of data (each message would be limited to about 1024 bytes to keep network utilisation low.) Because of this imposed limitation and the fact that the system is designed for voice communication the message will also contain instructions on how to retrieve the voice data.

This is where the download/upload manager comes in. Loosely based on the bittorrent model this system allows the network to supply the recorded voice only when requested to do so. Given the complete system will be part of a mesh network, a bittorrent network is the one of the best data distribution methods that does not rely on a centralised server. However unlike a bittorrent network the protocol employed will need to be different and employ a distributed tracker to prevent congestion to the tracker server/source party.

Thanks for reading and I will be updating this very regularly in the weeks to come. So if you have any questions dont be afraid to contact me.

BTW. I am currently looking for someone with experience in UI coding/design to create the front-end to the system.