tildenet/index.html

82 lines
4.6 KiB
HTML

<head>
<title>TildeNet</title>
<link rel="stylesheet" href="https://tilde.team/css/hacker.css" />
</style>
</head>
<body>
<div class="container" style="max-width: 900px; width: 80%;">
<h1>TildeNet ( aka ~Net)</h1>
<p>TildeNet is a virtual network connecting different tilde servers. This allows for services to run in a tildeverse-wide intranet. We give away addresses in the reserved blocks (10.0.0.0/24 space) for tilde server operators. Join us on the <code>#tildenet</code> channel on <code>irc.tilde.chat</code>.</p>
<p>Please don't abuse our network &lt;3</p>
<h2>Members</h2>
<p>TildeNet intends to connect all servers of the <a href="https://tildeverse.org">tildeverse</a> federation. At the moment, ~Net connects the following servers:</p>
<ul>
<li><a href="https://tilde.best">~best</a> (10.0.0.3)</li>
<li><a href="https://tilde.team">~team</a> (10.0.0.48)</li>
<li><a href="https://thebackupbox.net">thebackupbox.net</a> (10.0.0.41)</li>
<li><a href="https://thunix.net">thunix.net</a> (10.0.0.5)</li>
</ul>
<h1>Technical details</h1>
<p>TildeNet is very similar to <a href="https://wiki.hamburg.ccc.de/ChaosVPN">ChaosVPN</a>, the virtual network that connects hackerspaces. Contrary to ChaosVPN, TildeNet is based on <a href="https://wireguard.com">wireguard</a> tunnels, not <a href="https://tinc-vpn.org/">tinc</a>.</p>
<p>This project was started after TildeVPN (~VPN) which uses wireguard. That's why ~net is based on Wireguard, but that could change eventually, depending on how this experiment works out in practice.</p>
<p>Each server establishes a tunnel to every other server in the network. End users wishing to access TildeNet should use their tilde server as an entry point, either via SSH or VPN.
either:
- setup SSH SOCKS5 proxy (TL;DR <code>ssh -D 9350 your@tilde</code> then configure your programs to use localhost:9350 as SOCKS proxy)
- connect with OpenVPN/Wireguard via ~VPN node (soon)</p>
<h1>How to join the network</h1>
<h2>For tilde operators</h2>
<p>To setup ~net on your tilde server, you need to open a wireguard tunnel to every other server within the network, and they must also open a tunnel to you.</p>
<p>Join <code>#tildenet</code> at <code>irc.tilde.chat</code>. All node operators are on this channel, so you can ask them to add your Wireguard server to TildeNet as peer.</p>
<p>Also there is a <a href="peers.txt">list of peers</a>.</p>
<h1>Future plans/ideas</h1>
<p>This section describes ideas for future work. None of it is implemented yet.</p>
<h2>Intranet pages</h2>
<h2>Domain Name System</h2>
<p>It would be possible to use special DNS resolvers for TildeNet. Specific domains claimed by ~net nodes would resolve to a ~net address.</p>
<p>approaches:
1. work with <a href="https://tildenic.org">.tilde</a> people so .tilde domain would resolve to ~net addresses
- develop a special resolver that would query a special ~net delegation TXT record that points to an authoritative resolver reachable within ~net
2. sync with .tilde, but use TXT records (with record type + data) which get written as proper records on ~net dns
- or only sync records matching the allocated subnets? (grep? ;)</p>
<p>TODO: The TXT record should contain a unique ID for the LAN context (i.e. "tildenet") so other communities can reimplement the same process with a different ID and there would not be confusion on a DNS level in regards to what services we can resolve locally or not.</p>
<h3>Approach 1</h3>
<p><code>.tilde</code> domains currently resolve to public IP addresses. Anyone using a tilde resolver can resolver <code>.tilde</code> domains to an internet-facing server. This alternative DNS root is a nice proof-by-example that DNS does not have to be centralized in a few people's hands, but brings little value to end-users while requiring manual configuration.</p>
<p>Maybe .tilde domains should resolve to ~net addresses, and ~net members should resolve .tilde domains. This way, the burden of configuration lies on the server in most cases.</p>
<h3>Approach 2</h3>
<p>What we're trying to do, somehow, is to setup alternative authorities for existing domains. For example, thunix.net should be able to resolve to public Internet addresses or to ~net addresses depending on the context.</p>
<p>We can introduce a new TXT record for a domain to delegate its ~net resolution to a different authoritative server </p>
<p>For example current <code>.tilde</code> DNS users can make a subdomain for it and point it to ~Net address. (Needs collabration with <code>.tilde</code> operators and node operators)</p>
<h2>~VPN</h2>
<p>Implementing ~Net with ~VPN and making a decentralized VPN network.</p>