In order for the realtime engine (e.g. ChainPad) to build the document, it needs to access the history of the channel to which it has joined. Since every ChainPad instance has the history, it is ok for us to alter ChainPad so that it can ask a peer for the history and then provide that history. However in order to ensure that peers with good network latency are selected, there should be an attribute which indicates how preferable a peer is for communicating with, this way the peers to ask can be selected from the peers in the channel.
In order for the realtime engine (e.g. ChainPad) to build the document, it needs to access the history of the channel to which it has joined. Since every ChainPad instance has the history, it is ok for us to alter ChainPad so that it can ask a peer for the history and then provide that history. However in order to ensure that peers with good network latency are selected, there should be an attribute which indicates how preferable a peer is for communicating with, this way the peers to ask can be selected from the peers in the channel.