Livestream caseros con #Owncast en #yggdrasil aqui la addr http://live.dev1ls.org
Saludos muy especial para [Gatito] http://gatito.ygg.at #Yggdrasil #ipv6
acabo de montar un ssh-chat: ssh tunick@.ygg.at #Yggdrasil #ipv6
Buscame en Yggdrasil http://dev1ls.ygg.at/ #NixOS #ipv6 #yggdrasil #Domain
Nuevo Post: https://dev1ls.deno.dev/yggdrasil-la-red-mesh-ipv6-descentralizada #NixOS #ipv6 #yggdrasil #Dev
Empezamos con nixos-containers y ya tenemos #ergo y #honk deforma declarativa.. y todo bajo la ipv6 de #yggdrasil
i’m torn between git-daemon and using a forgejo to store my flakes. i can do authz using yggdrasil addresses, but that’s basically the limit. maybe that’s not a bad thing.
↳
In-reply-to
»
i am working on very smol deployments, where a server may use two or so replicated sqlite databases instead of a db server like postgres to seamlessly move from single to multi-node arrangements as needed. there is a clear performance limit here, but the goal is not to serve a huge number of clients. just to do as much as possible with a small number of useful components that can be upgraded to handle up to medium size workloads, without difficult data conversions or migrations. scaling beyond that point should be done via federation.
⤋ Read More
for example, ejabberd, redka, and litefs. all using sqlite+litefs for their database needs allows agents to communicate over xmpp, matrix, mqtt, and sip. other applications can use sqlite for storage or speak the redis protocol to redka. ejabberd can also handle file uploads, static file publishing, identity, and various other web application services. when scaling, litefs integrates with consul to manage replication which grants the network access to service disco, encrypted mesh networking, and various other features that can be used to build secure service grids. ejabberd and redka can be scaled to multiple nodes that coordinate over the litefs replication protocol without any changes to the db storage config. other components can be configured to plug into this framework fairly easily as well. we keep the network config fairly simple by linking nodes together with yggdrasil to flatten the address space and then linking app nodes together using consul to provide secure routing for the local grid service. yggdrasil also offers utility for buliding federated networks in a similarly flat address space, for more secure communications i2p is also available in yggdrasil mode. minibase is wonderful, and we have not even started to talk about secure IoT.
I built a gaming PC back in 2020, and in 2024 the only resource-intensive task I perform with it is generating strong private keys for my nodes on the Yggdrasil network. Money well-spent!
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.
so i learned that my vpn provider uses nftables to tag traffic for split tunnelling. so it looks like i’ll be converting my iptables rules. there’s some implication for docker containers that i’ll have to reckon with, but i’m already nesting them inside a nixos container so i don’t really need docker to touch the network at all. after that i’ll be able to define some rules to allow traffic meant for the yggdrasil network to reach the tunnel. this will be important later.
i wonder if i can replace my uses of haproxy with iptables 🤔 generally its a yes, but i do need some SNI sniffing in there to direct the streams at the right hosts in yggdrasil.