X-Git-Url: https://www.tinc-vpn.org/git/browse?a=blobdiff_plain;f=goals.mdwn;h=57bffec947255b2342fb8988ae337cf15fe0dc34;hb=506b1601731eb4cac35e5f516e20b312f0b51015;hp=41a5a10b272dadd2ada0467523166b2ff2dfc45d;hpb=7c74a57cd95cfc0358fdd5980d9170ea16751dfb;p=wiki

diff --git a/goals.mdwn b/goals.mdwn
index 41a5a10..57bffec 100644
--- a/goals.mdwn
+++ b/goals.mdwn
@@ -65,7 +65,7 @@ The 1.1 branch of tinc has been created as a stepping stone towards
 2.0. Only gradual changes to the source code are allowed, ensuring
 that the code is always in a mostly usable state. The protocol will
 stay compatible with that of the 1.0 branch. The following features
-are planned in this branch:
+are planned or are already implemented in this branch:
 
 **Replaceble cryptography backend**
 
@@ -93,15 +93,14 @@ in the tinc.conf files. It is desirable to have tinc manage the
 creation of control connections as well, so that the administrator
 does not have to do this manually anymore.
 
-**Deal with NAT**
+**Automate setting up nodes**
 
-The 1.0 branch by default tries to exchange packets via UDP.
-However, if one or more peers are behind a NAT, and source ports
-might be changed or packets may not arrive at all, the
-administrator had to manually enable the TCPOnly option or use
-another workaround to get tinc to work. Tinc should be able to cope
-with altered source ports, and should detect whether or not packet
-exchange via UDP works at all, and if not fall back to TCP.
+The tincctl utility should have a wizard-like interface that asks a few
+necessary questions and then creates all the configuration files.  Another
+useful feature would be to allow it to export a GPG signed email to selected
+recipients, which would be able to import them with a simple command.  Another
+option would be to allow a user to connect via SSH to a remote node (if he has
+an account there), and do a two-way exchange of configuration files.
 
 ## Plans for tinc 2.0
 
@@ -137,14 +136,14 @@ PGP, where peers can sign each other, and if there are enough
 signatures, they can allow communication. Trust management should
 be simple, for example using a command like
 
-    tinc trust *foo*
+    tinc trust foo
 
 which should let the local tinc
 daemon trust information from the peer named *foo*. To authorise
 the use of addresses on the VPN, a command like the following could
 be used:
 
-    tinc allow *bar* 192.168.3.0/24
+    tinc allow bar 192.168.3.0/24
 
 This should generate a small certificate that proves that the node that
 issued this command trusts node *bar* with the 192.168.3.0/24 range
@@ -153,11 +152,11 @@ tinc daemon's configuration, but also spread immediately amongst
 the other peers in the VPN. It is also important to allow trust and
 authorisation to be revoked in the same way:
 
-    tinc distrust *foo*
+    tinc distrust foo
 
 This should make the local tinc daemon stop trusting any information from *foo*.
 
-    tinc deny *bar*
+    tinc deny bar
 
 This should generate a certificate (with a newer timestamp than the previous one) denying
 *bar* any access, and spread this amongst the other peers as well.