Hi !
It would be very greatful to emit the id when you emit the join event.

Here is the code to change (line 101/102, spray.js) :

callbacks.onReady = function(id){
  onReadyFunction && onReadyFunction(id);
  // #D emit a join event
  self.emit('join');
};

to

self.emit('join', id);

If you can do it with a NPM release it would be great !

Forget about soketio for now. Let's focus on webrtc ;)
Can you rename the project to spray-wrtc ?

Leaving/crashing peers are handled

After #2, the peers continue to join the network. Each time, the peer forwards the offers appropriately.

Currently, a peer leaving the network does it without giving notice. In that sense, departures are equivalent to crashes. Nevertheless, if enough time is given, it could try to patch the network, i.e., not being as disruptive as it is currently by attempting connections from it inview to its outview (eg A-> B -> C, B leaves but first acts as a bridge to connect A to C, it becomes A -> C )

Partial views can be temporarily empty during the exchanges in order to not exchange multiple time a same entry.
Nevertheless, it becomes a problem if one wants to broadcast messages in the network...

Among others, it raises segmentation faults. Todo: stay informed at webtorrent/webtorrent-hybrid#5

Currently, we close the sockets using a timeout meaning that after a while, the socket is not used any longer. It could be possible to close it faster when no messages reference the socket. It requires to look carefully to whom is entitled to close a connection.

When an exchange is initiated by Peer Pi with the Peer Pj, it asks to one of its neighbor to give it an offer ticket, then forwards it to Pj and expect Pj to give a stamped ticket in response. However, if Pj already knows the emitter of the offer, it directly adds it to its neighborhood (because it already has a working socket with him). Thus, no answer comes through Pi. Therefore, the forwarding route is kept while it should be cleaned at some point.
Note that the pending socket of the emitter is clean after 'timeout'.

Sorted by age, the partial views only improve getOldest and addNeighbor. Probably better to sort by id.

Every delta time, they execute a function that shuffle partial views.

There is an inbrowser example. Yet, it does not implement all functionnalities of the network interface.

TODO: make a nodejs example using signaling service.

It corresponds to the very first part of the protocol. It implements the interface of 'network'.

1 peer joins a known peer and connects to it. Afterwards, the network contains 2 peers.

with a > 0. , b >= 0.

Currently, it converges towards log(N) , i.e., a = 1.

Might be an overkill.... But it could possibly help to maintain the code in the future...

After the first step of #2, the links establish properly, nevertheless, the joining peer receive twice the message of the stamped ticket during the second connection establishment.

Currently, connections are created using the default options provided by simple-peer. To do: give the possibility to configure the options.