# Riddle

A system for finding application peers and resolving names over mesh-like networks

TODO:
- Verify CertifiedNameInfo against system trust
- Create a NameInfoStore, along with a FilesystemNameInfoStore and maybe a memory one too
- Build propogation mechanism
- Add propogation rate limit
- Build tooling for generating and propogating NameInfo
- Peer auto-discovery using LAN multicast, known seed servers, and optionally Yggdrasil nodeinfo (although this may not actually be needed)
- Riddle (callback) mode, removing `CHALLENGE` requests.
- OpenPGP domains, in the form `[fingerprint].rns` i.e. "c3a6-5e46-7b54-77df-3c4c-9790-4d22-b3ca-5b32-ff66.rns"
- Server class should implement (or inherit) a "Service" class, with another implementation being "DaemonClient" when a Riddle Daemon is implemented

## Riddles v2
- Sent with `RIDDLE` request, accepted with `OK`
- Responded to with `CALLBACK` request
- Callback accepted with `SOLVED` reply
- `RIDDLE` arguments: group id, ttl, expiry, reply port
- `RIDDLE` items: checksum/id, riddle public key, author public key, reply public key, riddle data
- `CALLBACK` arguments: riddle checksum/id
- `CALLBACK` items: answer data, connecion info public key
- `SOLVED` arguments: none
- `SOLVED` items: encrypted and signed IP/port data

- Riddles are sent to peers who are in the correct group
- Peers receive the riddle and then forward onto other peers in the group - holding on to the riddle ID and metadata
- When a peer is reached that can solve the riddle, it encrypts its answer with the `reply public key` and then signes the encrypted answer with the private key derrived from the riddle matching the `riddle public key`.
- Thet peer then sends a `CALLBACK` request to the peer it received the riddle from.
- The peer servicing the `CALLBACK` request verifies the riddle with the public signature, and if correct forwards the request to the peer it received the riddle from.
- The originating peer once receiving and verifying the `CALLBACK` request, encrypts its IP/Port information with the `connection info public key` and then signs the encrypted data using the `author private key` from the riddle. The peer then replys with `SOLVED` and the encrypted/signed data.
- Intermediate peers verify the `SOLVED` reply by verifying the encrypted data against the `author public key` of the riddle before passing back the reply.
- At any point in the chain, if a peer is not happy it can reply with `NOT-ACCEPTED` and codes in the 1xx range.