[EPIC] Signal Server Facilitates Relay + Removal of TURN

[neonphog]

stateDiagram-v2
direction LR
state "Signal Connect" as sc
state "Relay Messages via Signal" as rms
state "Try Open WebRTC" as rtc
note left of rtc: STUN only
state rtc_ok <<choice>>
state "Relay Messages via WebRTC" as rmrtc
sc --> rms
sc --> rtc
rtc --> rtc_ok
rtc_ok --> rms: error
rtc_ok --> rmrtc: success

• [ ] [Epic] SBD message server and client
  • [x] holochain/sbd#6
  • [x] holochain/sbd#7
  • [x] holochain/sbd#19
  • [x] holochain/sbd#8
  • [ ] holochain/sbd#9
  • [x] holochain/sbd#10
  • [ ] holochain/sbd#11
  • [x] holochain/sbd#12
  • [ ] holochain/sbd#13
  • [ ] holochain/sbd#14
  • [ ] holochain/sbd#15
• [ ] holochain/sbd#16
• [x] holochain/sbd#17
• [x] holochain/sbd#18

[neonphog]

Moving these design musings down to a comment so the description can be real epic details:

---

Signal Server Protocol

• register includes query string timestamped proof of private key
  • wait period then nonce response verify of private key
  • send limit values to client
• forward request bytes be sent to peer (dest peer replaced by source peer when sent out again)
• keepalive periodic client send

Limiting

• limit X concurrent pending connections
• limit X connections per IP
• limit X IPs in memory
• limit X messages per connection per time
• limit message size to X MiB

Back Channel Protocol

• online notify a peer server of client availability (after register success)
• offline notify a peer server of client disconnect
• forward request bytes be sent to peer
• keepalive both peer servers should periodically keepalive

---

Signal Client Protocol

Client protocol is sodium secret stream based with logic to respect rate-limits and buffer messages into batch sends without going over the max message size returned by the server. Within the encryption are framed message types:

• message an actual client message send--this is client communication relayed via the signal server
• request_offer a polite node wants an offer from the impolite node
• offer an impolite node wants to try negotiating webrtc
• answer a polite node responding to an offer
• ice webrtc connectivity message
• open sent upon webrtc data channel connect success. When a node has both sent and received the open message, it switches to sending all data over the webrtc channel. (Note, this may not be needed, data channel open is probably a good enough signal to start using it).