Actually now really interested in running my own instance on a #RaspberryPi that I have lying around. But I'd lose the great #Fosstodon local feed. Would there be a way of following it with #Mastodon or #Pleroma web UIs? Preferably without putting unnecessary pressure on the Fosstodon server also.
Of course, I don't have a static IP at home so I'd have to deal with that headache. I guess there's software to autoupdate #DNS records of a subdomain based on the current IP?
@nicd actually, it tempts me to make a network of low availability (by design) #yggdrasil servers. It may be unavailable to talk to the rest of the world, depending on how #acttivitypub resolves actors (I'm completely ignorant of the protocol). But it is available, then we can use it to host stuff anywhere and be reachable via a fixed IPv6 in the yggdrasil network.
@jonn I've been actually working on my own federated microblogging protocol (mostly in my head) that would tolerate nodes being offline for any amount of time. But I have too many other things going on right now. :P
@nicd wait wait, did we talk about self-hosting yet? Because this is part of what I was thinking about based on my realisation that self-hosting is only possible if we let people host content from their phones. Here comes the genius part:
Which, in turn is only possible if the data syncs while the phones are charging (which happens every day).
But it means that we need to develop to extreme low availability.
@jonn Having something work on a smartphone with the low availability would be an interesting challenge.
Problem with self hosting is IPv4 NAT and IPv6 not being available. Does Yggdrasil have tools to solve that? I don't know what it is really.
I should probably write my protocol idea down somewhere so that it could be commented on by others. :P
@nicd #yggdrasil abuses ipv6 and works on phones because it also abuses #wireguard.
But clearly the system will still have some conventional servers, public who don't self-host can connect to.
@jonn What if you don't have IPv6?
@nicd what do you mean? If your OS doesn't have IPv6 support, you should stop trying to use a washing machine to go online.
#yggdrasil creates a new virtual #tun interface (a virtual ethernet adapter). The only difference from #wireguard is that #yggdrasil is an open network! It kinda adds routing to wireguard.
@jonn I mean if your ISP doesn't offer you IPv6. I don't know how Yggdrasil works. How does one host something behind NAT in practical terms? Via a proxy server?
@nicd no, spin up yggdrasil, add an AAAA DNS record, enjoy life. That's how we host dev copies of services in https://doma.dev.
You can also point #Caddy active load balancer to a swarm of such servers and have a high total availability btw.
@jonn An AAAA record that points where? 🤔
@nicd to your yggdrasil IP:
```
λ ping6 ozols.doma.dev
PING ozols.doma.dev(202:9557:aae7:88f8:cfcc:1b63:3dce:7475 (202:9557:aae7:88f8:cfcc:1b63:3dce:7475)) 56 data bytes
64 bytes from 202:9557:aae7:88f8:cfcc:1b63:3dce:7475 (202:9557:aae7:88f8:cfcc:1b63:3dce:7475): icmp_seq=1 ttl=64 time=91.6 ms
```
@jonn So it is a proxy server of some kind?
@nicd sorry, I'm not sure I understand the question. #Yggdrasil is a tun + routing protocol, kinda like #cjdns.
We have no proxy servers, we just point AAAA records to our laptops and make the requests from any machine in the world that runs #yggdrasil. If the laptops are running, the requests succeed. If the laptops aren't running, the requests fail.
The proxy comes into play if you want to have an uptime total to be equal to the union of the uptimes of all the laptops. *For that* you need a reverse proxy with active load balancing, yes.
@nicd you don't need to forward ports if you have an IPv6, right?
You get IPv6 from a tun virtual device because Android has Wireguard in kernel for two years.
If you do it via #yggdrasil, now you can now route to that tun virtual device from any other device in the world that runs #yggdrasil.
Obviously you won't be able to run stuff on protected ports, but that should be enough. I can make a PoC demo some time... Uhh... Late November. I have some time on the week after Nov 26th.
@jonn I read the FAQ and now I understand more, so it's a mesh network and you need to know at least one other node to bootstrap it. And that node has to have ports open.
I take it you also need to use it if you want to access my site that I'd be hosting over the network then? I dream of a solution where the end user doesn't need to know about such things, but since we're stuck with NAT I guess that stays a dream.
@nicd 1st point isn't really a problem, I think.
2nd one isn't either, but sorry for not being clear enough on this one.
Think about what true low-availability self-hosting means. It means that all the computations are pushed all the way to your own device. The users won't even know that they access exclusively cached data. The users who refuse to self-host (by installing an app on their phone or running a binary on their computer), will still be able to connect to a server, serving its cache over HTTP. It's kinda bitcoind with RPC, right? You can maintain your own cache and then you sort of let the swarm feed you data. Or you can connect to something else that maintains its own cache.
Eventually it all converges to something meaningful. And we don't even need for debit to match credit in our use case!
@jonn My idea of this was just a pull-only protocol like RSS, it's much simpler to implement. But it won't solve the NAT problem which is a pain in my behind. :)
@nicd oh yes, I've been there. Only the realisation that the client-server model is *literally* and *by design* incompatible with self-hosting (and thus true understanding of what p2p means) allowed me to break free and start thinking about low-availability hosting.
@jonn I'm sorry, I keep not getting it. :D
So let's say I have a phone, it's behind NAT using IPv4. I can't forward ports from the NAT to my device, so no one can actively connect to it. There _has_ to be some kind of proxy that my device connects to, that forwards the connections to my device. Kinda like SSH reverse tunnel. Or what's the solution? In very practical terms. :D