DEPRECATION NOTICE: As of Aug 24, 2020, this is no longer a valid description of the product.

Session Description Protocol or SDP is a standardized format for describing a client session for peer-to-peer networks. It is the backbone for WebRTC’s connection handshake and can be Base64-encoded with no loss of functionality (this is useful for cross-platform “dead drops” of session descriptions). This article will attempt to apply SDP as a description of zeitgeist member sessions.

Issue

Establishing a connection with a peer in a P2P network is tricky. Conveniently, there are plenty of pre-existing patterns for doing so and even the standard JavaScript API WebRTC to help handle connections and complex media sockets. There is no real point to re-invent this wheel at the current time, so WebRTC will do.

State of the Art

SDP is used in a variety of commonplace technologies including WebRTC, RTP, and RTSP. Common users of these technologies include some streaming services (though some services like Netflix do not – they send packets of data along with a manifest and populate a buffer from that), video conferencing services like Zoom, and video surveillance services like the one in Ring.

Idea

SDP can and be used as a unique user identifier. In the Zeitgeist model, member “addresses” are described loosely at best as the location of the member. This location can be described over IP by SDP.

Implementation

In plain English, the following must be done:

1. A member is handed the SDP of the SOT node through a third party of the Zeitgeist. This should be done carefully over a trusted end-to-end encrypted signaling server.
2. The member initializes a connection
   1. The member describes themselves as a WebRTC PeerConnection object.
   2. The member sets their PeerConnection’s remoteDescription.
   3. The member creates an answer.
   4. The member sets their PeerConnection’s localDescription to the answer and signals this answer back to the SOT node.
3. Once the connection with the SOT node is established, this connection is used as the signaling server for establishing connections with the candidate SOT nodes.

Signals can still follow SOVA, but the initial connection with the SOT does require a signaling server. This signaling server has the following minimum requirements to remain safe and useful:

• It must send messages over an encrypted protocol.
• It must be discoverable by the SOT and the member.
• It must implement a validation pattern for the signals.
• The signaling server should be considered untrustworthy until proven otherwise.

Intuition

The intention of the SOVA protocol is to minimize infrastructure by making the protocol more opinionated. Because it’s so much more simplified, it could make for a lower-weight alternative to the higher-level protocols like HTTP and can even act as a lingua franca protocol across connection types like Bluetooth, IP, radio, and Wifi tethering.