# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 1
# self = https://watcher.sour.is/conv/4oekf3a
minibase has a network security architecture with a number of overlapping layers of protection. first, routers and discovery endpoints either require a password or an authorized public key to accept traffic. this setup restricts who can reach the endpoints to an extent, but peering with enough third parties with less restrictive policies will practically allow global routing. since this is a possible policy choice, minibase also requires internal traffic to be authenticated. overlay traffic is automatically encrypted by yggdrasil, but applications should still treat the traffic like its clearnet and use tls. currently i'm requiring a dns acme challenge to generate wildcard certs, but eventually it might make sense to scope the certificates to the specific service its associated with. we don't have much config generation in the nix modules yet, but something like this should be possible eventually. i'm working on configurations for ory oathkeeper, hydra, and kratos to provide a federated auth framework that your network services and minibase configs can integrate with.