A stream is a collection of nodes, connected together and having addresses associated with the specific stream number.
The content on this page has not yet been implemented in the client and all nodes have only addresses for stream 1. Content here is subject to change. While possible stream distribution methods are still being discussed in the forum, this page describes the tree structure, that can be found in the whitepaper.
If users create addresses, they must enter the stream number or (if existing) select an existing address from which the settings are copied. At the time this document was written, the stream number is always 1.
Stream 1 is the master stream from which all other streams develop. Apart from the fact, that it contains all pubkeys (see "Advertising") it is a regular stream and at the time this page is written, the only one existing stream.
Clients can have multiple addresses in different streams and will connect to other clients for each stream they own an address, ignoring all other streams. This prevents the message cache from getting too big. Clients also connect to streams of addresses they are subscribed too.
Clients not connected to stream 1 occasionally connect its stream chain up to the master stream to advertise their existance. This allows each client to reach each other and identify in which stream the address in question is located.
If clients get uncomfortable with the amount of messages being sent to the network they may create two child streams.
If new addresses are generated and multiple streams are available the user can choose, which stream becomes the addresses home stream. This number should be chosen to match as many recipient addresses as possible. If a stream is chosen that the address will never send messages too, it creates additional traffic for sender and receiver due to the stream changing.
The receiver is responsible for advertising its existance, while the sender is responsible for finding the receiver. If a private message is sent, the sender has to find the receivers stream and send the message to it. The receiver will upon receiving the message connect to the senders stream and send the ACK Message (post fashion).
Broadcasts are organized in a get fashion. A Broadcast is always sent to the stream the sending address is allocated to. Clients have to manually pull the message from the stream. Example: The Timeservice Broadcast is located in stream 1 and the user is located in stream 5. If the user wants to get the broadcasts from the timeservice, he needs to connect to stream 1 and check all messages to verify if there are broadcasts from the timeservice. This forces the client to download all messages from the stream, thus carefully choosing the right stream for a new address is important.
More details can be found in the Whitepaper