Adding New Registration Sources

As of the time of writing, Conjure supports two methods of registration: a TapDance-like chosen-ciphertext decoy registration system supported by detectors on each station, and a centralized API that creates registrations based on HTTP requests. If you're on this page, you probably want to add another; luckily this is pretty painless!

Once you've determined the name of the registration source, you should add it to the RegistrationSource enum in gotapdance's ProtoBuf definitions (link may be broken when you're reading this if branches switch around, but change it in the branch related to Conjure). To re-generate the Go code in gotapdance, run protoc --go_out=import_path=tdproto:. signalling.proto, and to regenerate the Rust code in conjure, run protoc --rust_out=. signalling.proto. The Go code should replace gotapdance/protobuf/signalling.pb.go, and the Rust code should replace conjure/src/signalling.rs.

Next, expose a ZeroMQ PUB socket on the registration source. This is where stations will connect to receive (SUB to) registrations. If the registration source is intended to be used over the internet you'll probably (definitely) want to add authentication; see the Registration API for a Go example of setting up authentication via CurveZMQ (ServerAuthCurve is for the clients to verify the server's identity, and AuthCurveAdd is for allowing a certain list of clients to connect represented by their public keys). Next, on each station add a registration source to zmq-proxy/config.toml similar to the other [[connect_sockets]]: the address and type fields are required. If the source is local to each station the type should be NULL (no authentication), and if the source is over the internet the type should be CURVE, and a pubkey field should be added containing the Z85-encoded public key of the registration source.

Back on the source's side, when a registration is received, it should publish a message of type ZMQPayload from gotapdance/protobuf, filling in the shared secret, the registration_payload field representing the registration data from the client, and the registration_source enum with the value you set up above.

That's it! Once specified in zmq-proxy/config.toml, the proxy will connect to the new source and transparently combine registrations from it with registrations from other sources. The application will log the source of the registration when it is received, so you should be able to see registrations with the value corresponding to the new enum value that you set up above.

---

As a possible TODO, it might be good to further centralize all internet-based registration sources into one central ZMQ PUB socket so that each station only needs to set up connections to one socket and we can transparently add more registration sources to that socket, rather than adding them on each station. This was the simplest architecture for supporting a single internet-based registration source, and I don't have enough foresight to tell if it'd be a worthwhile architectural change or an unnecessarily large point of failure right now.