README.md 2.4 KB

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.