Our Twincode technology allows us to setup various kinds of relations
without knowing private information about any party.
Twincodes implement objects relationships along a client-server model. Twincodes are composed of the following 4 “facets”:
The twincode Factory generates the object identifiers, and defines its ownership and access rights properties;
The twincode Outbound is a proxy of the called object, given to a calling object;
The twincode Inbound defines the entry point to the called object;
The twincode Switch connects the twincode Outbound to the twincode Inbound.
Twincode facets are defined by 4 unique identifiers. These identifiers are version 4 Unique User ID’s (UUID v48F8F10F1).
Their relationships are represented on Figure twincodes “Click-to-Call” relationship model.
“Click-to-Call” relationship model
The twincode relationship model is covered by EU Patent N°3 020 179 granted on 31 May 2017
under the title “Distributed Programmable Connection Method to establish Peer-to-Peer Multimedia
Interactions” (application date: 10 July 2014).
The twincode relationship model is used to represent:
Our applications protect your privacy and freedom by sending messages and
photos directly between devices, without storing any content on a server.
When a device wants to connect to a peer, it generates an SDP (Session Description Protocol)
message to initiate the WebRTC connection. The SDP message is sent to the signaling server
along with the peer’s twincode to identify the target device. The server then attempts
to wake up the peer device using Google or Apple push notification services. Once the peer
device is awake, it connects to the signaling server and retrieves the SDP message.
WebRTC direct communication and encrypted signaling
A signaling server is used for the administration of twincodes and handle the WebRTC signaling
between devices. Our server implements the twincode objects relationships and when a device
wants to establish a WebRTC direct connection, it forwards the WebRTC signaling messages
to the devices. To protect the signaling setup, these signaling messages (known as SDP)
are encrypted on each device with shared secrets which are changed regularly.
Openfire (XMPP) for signaling and Jetty for WebSockets.
PostgreSQL for operations data and Kafka for messaging.
TimescaleDB/Grafana for monitoring and analytics.
Encrypted signaling
twinme
twinme+
Skred
