SuBFraMe Messaging Framework
Table of Contents
- What is SuBFraMe?
- Download and Install
- How does it work? - Overview
- Sending a Message
- Advantages and Disadvantages
What is SubFraMe?
SuBFraMe stands for Securely Broadcasted and Fragmented Messaging. It is a concept for an entirely decentralized, extensible network used primarily for email-like communication.
Download and Install
Currently, there is no (usable) working Version of SuBFraMe available. If you are interested in contributing to make SuBFraMe a reality, see #Contributing
If you are interested in the SuBFraMe Project and want to contribute, you can find a guide on how to get you set up in the CONTRIBUTING.md file. Any help is greatly appreciated and will help make communication more secure and uncensored!
If you want to actively support and contribute to the SuBFraMe - Project, please consider joining our Discord. This is not required, but makes communication easier and helps to resolve questions, uncertainties or problems. Discord is free to use, can be used completely in-browser and is substancially faster than #Slack.
How does it work?
The SubFraMe Network consists of two kinds of Nodes: StorageNodes and CoordinatorNodes (SN and CN respectively). CNs represent a small fragment of and are therefore part of the SN-Network.
When a message is to be sent, it is transmitted to a StorageNode. This Node will store it to it's local disk for the message file to be served on request. It will also log the unique MessageID to it's local database and announce to the Coordinator-Network that it has the Message File in question. It then proceeds to transmit the Message to a number of other StorageNodes, for them to also store the Message and announce that they are able to serve it to the recipient. A StorageNode periodically tries to register as a CoordinatorNode, to fill any open positions in the CoordinatorNetwork. A successful registration will sync the CoordinatorNetwork Database to the StorageNode. StorageNodes with a good connection will be prioritized on registration as CoordinatorNode, as well as being selected as StorageNode for a Message.
The Coordinator-Network represents the 'Brain' of the SubFraMe Network, and is strictly limited in size. It possesses a synchronous database keeping track of known Messages and their StorageNodes. That way, when a recipient requests a list of new Messages, it can query any CoordinatorNode and get a list of relevant Messages and their Storage Locations. CoordinatorNodes with a bad connection may be kicked from the CoordinatorNetwork, yet still function as a StorageNode.
Sending a Message
- Compose Message and add Attachments
- Create Envelope with Message Body, Attachments, Checksum, Confimation Key and other relevant metadata
- Encrypt the Envelope and generate a unique MessageID from the RecipientID and a Hash of the Messages Confirmation Key
- Transmit the MessageFile to any known StorageNode
- Receive the Message File
- Store Message to local disk
- Log MessageID to local database, broadcast own ID as server for Message File with MessageID to CoordinatorNode
- Transmit MessageFile to defined number of other StorageNodes
- Receive ID of StorageNode registering as MessageFileServer
- Log StorageNodeID and MessageID to local database
- Synchronize database with all other CoordinatorNodes
- Request new Messages with MessageID containing ID of Recipient
- Receive List of new Messages and their StorageNodes
- Download Message File from one or more of the relevant StorageNodes
- Decrypt Message, verify checksum
- Verify that Confimation Key in envelope matches Hash in MessageID
- Announce to CoordinatorNode that Message has been received and decrypted, transmit Confirmation Key
- Display Message Body and Attachments
- If Confirmation Key Hash matches MessageID, mark Message as received, verified and decrypted
- Periodically check Message Status against CoordinatorNetwork, remove file from disk if Message has been received and decrypted or if MessageTTL has passed
Schematic: Sending a message
Schematic: Receiving a message
- Network is entirely decentralized and pretty much impossible to censor or block
- SuBFraMe allows for secure communication through Public-Key-Encryption and various checksum verifications
- Message Flow is hard to trace, as sender is only identifiable by recipient after decrypting the envelope
- Message Propagation can be rather slow. making real-time-communication not possible
- Pushing messages to the recipients device is not possible, it will have to query the CoordinatorNetwork for new Messages
- Sender's identify cannot be reliably verified without a secure way of exchanging PublicKeys; meeting physically and using uncompromised systems
- Using multiple devices to receive messages for the same address will be rather complicated, as the message is removed from the Network once it has been decrypted and verified, or reached its TTL
More detailed information about Network communication you can find in PROTOCOL.md