Directory Service Tracking Issue

[nothingmuch]

See #775 for discussion

Sub bullets indicate spinoffs of parent, which are directly dependent. additionally many tasks kinda depend on #927, but mostly don't depend on each other

• [x] #914
• [x] #848
  • [ ] tower_http::metrics for simple in flight reqs metric, indicates ~ number of active sessions proxied by concurrent GET requests that are blocking on data
  • [ ] custom ultraloglog or hyperloglog based metric, analogous to histogram in prometheus parlance, unique shortids in a time period
• [ ] #927
  • [ ] #445
  • [ ] config reloading? not sure how valuable this would be with acme and automatic key rotation
• [ ] #915
  • [ ] DB should also be a tower::Service, using tower::{timeout,limit::rate}
• [ ] tokio-rustls-acme
  • [ ] configure rustls for PQ
• [ ] remove boilerplate with tower middleware
  • [ ] tower_http::trace, remove boilerplate tracing and only leave domain relevant logging
  • [ ] tower_http::limit, remove our custom body size limiter
  • [ ] tower::limit::rate, POST reqs should be limited to 25/s to ensure all mailboxes have a TTL of minimum 24hrs given default capacity limit
  • [ ] tokio_http::cors, removes tiny bit of boilerplate
• [ ] use axum to simplify routes, split app into sub-apps that all implement the Service trait (e.g. the OHTTP target resources)
  • [ ] backwards compatibility routes can be done using the tower_http::follow_redirect middleware instead of being aliased as they are today
  • [ ] handle HTTP 2
• [ ] use tokio-listener, --listen-addr instead of --port or something like that
  • [ ] nixos module using systemd listener. nix2container for docker?
• [ ] ohttp-relay into monorepo
• [ ] merge ohttp-relay & payjoin-directory into combined service
  • /{id} and /{authority} paths are distinguishable, ShortIDs are 13 bech32 chars, authorities must have : or .
  • deny access to own directory from the relay
• [ ] maybe factor out a tower_http OHTTP gateway middleware

---

Far future:

• QUIC
• arti_client for #766 (hidden service for directories & tor bridge for relays), kinda tricky without https://gitlab.torproject.org/tpo/core/arti/-/issues/1932 see https://docs.rs/arti-client/0.33.0/arti_client/index.html#-warnings-
• multihop OHTTP #582

[DanGould]

Now that ohttp-relay is up to date with 1.85.0, it could be brought into this repository as a monorepo item. However, it depends on ureq for proxy which'd be nice to replace with reqwest if possible and it depends on nginx for tls termination which would really be better to replace with whatever native ACME solution you cook up for the directory.

In either case I don't think merging the repos affects payjoin crate's 1.0 stability now so I'm just noting these things for when the time is right.

[zealsham]

Now that ohttp-relay is up to date with 1.85.0, it could be brought into this repository as a monorepo item. However, it depends on ureq for proxy which'd be nice to replace with reqwest if possible and it depends on nginx for tls termination which would really be better to replace with whatever native ACME solution you cook up for the directory.

In either case I don't think merging the repos affects payjoin crate's 1.0 stability now so I'm just noting these things for when the time is right.

@DanGould The ureq crate is only used for integration test in the ohttp-relay repo . i did a replacement with reqswest on my local branch and all test-cases pass .

[benalleng]

Feel free to open a PR on the ohttp-relay so we can take a look