Skip to content

Textric Routing Protocol

Jump to bottom
Alex Rao edited this page May 29, 2021 · 5 revisions

This document attempts to describe how Textric routes messages. It covers from send, through route, to delivery at the endpoint destination.

Sending

As detailed elsewhere in this Wiki, the originating device (i.e., the sender) will construct a payload that, at the bare minimum, contains the userID of the intended recipient. This is sent as a POST request to the server, using the fingerprint generated during device enrollment.

Keep in mind; only authenticated devices can send, so we implicitly know the sender's identity.

Routing

The server will lookup the user, and then fire off copies to each of the user's devices, assuming they are listening. Ideally, this is done by iterating through active connections...

We'd probably also send push notifications; something like APNs or FCM. So we'll need to keep some other bits of information about the user in this case. Alternatively, at least for APNs, we could even send a background notification...?

Regardless, if an app isn't listening, we'll queue it on the server instead. How long do we keep it? Good question...

Delivery

In the meantime, the client app has a web socket connected to our server; we pump it down the web socket, and then read it from there and do what we do best!

WebSocket Protocol

For now, Textric shall use the standardized WebSocket protocol for communication. After device enrollment, recall that devices (and the server!) now possesses a "fingerprint"; it's a fast pass the device can use to log in.

Device Introduction

First, the device sets up a WebSocket connection to the server; by default, this is port 8080. Once connected, it sends the following payload:

{
  "deviceID": "string",
  "userID": "string",
  "fingerprint": "the_hash"
}

This step must be done over TLS.

  • deviceID: The Device Identifier (i.e., MAC address, etc.) used previously
  • userID: The User ID used previously... if the user changes their handle, all devices are revoked.
  • fingerprint: The previously-generated fingerprint

If this is rejected, an error message - a Message with type ERR - is sent. Note that this is sent regardless of the actual reason (i.e., device does not exist, etc.). At this point, the device should instead attempt re-enrollment.

Upon success, the server will respond with an AACK message. At this point, new messages will be pumped down, and sent messages can be pumped up.

Clone this wiki locally