7 files changed, 258 insertions, 372 deletions

diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
index 228603cda..830a345a8 100644
--- a/doc/handbook/chapters/developer.texi
+++ b/doc/handbook/chapters/developer.texi
@@ -79,6 +79,7 @@ new chapters, sections or insightful comments.
 * File-sharing (FS) Subsystem::
 * REGEX Subsystem::
 * REST Subsystem::
+* RPS Subsystem::
 @end menu
 
 @node Developer Introduction
@@ -556,7 +557,7 @@ stacked together to construct complex buildings and it is generally easy
 to swap one block for a different one that has the same shape. GNUnet's
 architecture is based on LEGOs:
 
-@c @image{images/service_lego_block,5in,,picture of a LEGO block stack - 3 APIs as connectors upon Network Protocol on top of a Service}
+@image{images/service_lego_block,5in,,picture of a LEGO block stack - 3 APIs upon IPC/network protocol provided by a service}
 
 This chapter documents the GNUnet LEGO system, also known as GNUnet's
 system architecture.
@@ -573,10 +574,14 @@ Like services, they have holes to be filled by APIs of other services.
 Unlike services, daemons do not implement their own network protocol and
 they have no API:
 
+@image{images/daemon_lego_block,5in,,A daemon in GNUnet is a component that does not offer an API for others to build upon}
+
 The GNUnet system provides a range of services, daemons and user
 interfaces, which are then combined into a layered GNUnet instance (also
 known as a peer).
 
+@image{images/service_stack,5in,,A GNUnet peer consists of many layers of services}
+
 Note that while it is generally possible to swap one service for another
 compatible service, there is often only one implementation. However,
 during development we often have a "new" version of a service in parallel
@@ -1876,7 +1881,6 @@ Testbed API can accessed by including the
 * Hosts file format::
 * Topology file format::
 * Testbed Barriers::
-* Automatic large-scale deployment in the PlanetLab testbed::
 * TESTBED Caveats::
 @end menu
 
@@ -2140,168 +2144,6 @@ message from its upward propagation --- the upward propagation is needed
 for ensuring that the barrier is reached by all the controllers and the
 downward propagation is for triggering that the barrier is crossed.
 
-@cindex PlanetLab testbed
-@node Automatic large-scale deployment in the PlanetLab testbed
-@subsection Automatic large-scale deployment in the PlanetLab testbed
-
-PlanetLab is a testbed for computer networking and distributed systems
-research. It was established in 2002 and as of June 2010 was composed of
-1090 nodes at 507 sites worldwide.
-
-To automate the GNUnet we created a set of automation tools to simplify
-the large-scale deployment. We provide you a set of scripts you can use
-to deploy GNUnet on a set of nodes and manage your installation.
-
-Please also check @uref{https://old.gnunet.org/installation-fedora8-svn} and
-@uref{https://old.gnunet.org/installation-fedora12-svn} to find detailed
-instructions how to install GNUnet on a PlanetLab node.
-
-
-@c ***********************************************************************
-@menu
-* PlanetLab Automation for Fedora8 nodes::
-* Install buildslave on PlanetLab nodes running fedora core 8::
-* Setup a new PlanetLab testbed using GPLMT::
-* Why do i get an ssh error when using the regex profiler?::
-@end menu
-
-@node PlanetLab Automation for Fedora8 nodes
-@subsubsection PlanetLab Automation for Fedora8 nodes
-
-@c ***********************************************************************
-@node Install buildslave on PlanetLab nodes running fedora core 8
-@subsubsection Install buildslave on PlanetLab nodes running fedora core 8
-@c ** Actually this is a subsubsubsection, but must be fixed differently
-@c ** as subsubsection is the lowest.
-
-Since most of the PlanetLab nodes are running the very old Fedora core 8
-image, installing the buildslave software is quite some pain. For our
-PlanetLab testbed we figured out how to install the buildslave software
-best.
-
-@c This is a very terrible way to suggest installing software.
-@c FIXME: Is there an official, safer way instead of blind-piping a
-@c script?
-@c FIXME: Use newer pypi URLs below.
-Install Distribute for Python:
-
-@example
-curl http://python-distribute.org/distribute_setup.py | sudo python
-@end example
-
-Install Distribute for zope.interface <= 3.8.0 (4.0 and 4.0.1 will not
-work):
-
-@example
-export PYPI=@value{PYPI-URL}
-wget $PYPI/z/zope.interface/zope.interface-3.8.0.tar.gz
-tar xzvf zope.interface-3.8.0.tar.gz
-cd zope.interface-3.8.0
-sudo python setup.py install
-@end example
-
-Install the buildslave software (0.8.6 was the latest version):
-
-@example
-export GCODE="http://buildbot.googlecode.com/files"
-wget $GCODE/buildbot-slave-0.8.6p1.tar.gz
-tar xvfz buildbot-slave-0.8.6p1.tar.gz
-cd buildslave-0.8.6p1
-sudo python setup.py install
-@end example
-
-The setup will download the matching twisted package and install it.
-It will also try to install the latest version of zope.interface which
-will fail to install. Buildslave will work anyway since version 3.8.0
-was installed before!
-
-@c ***********************************************************************
-@node Setup a new PlanetLab testbed using GPLMT
-@subsubsection Setup a new PlanetLab testbed using GPLMT
-
-@itemize @bullet
-@item Get a new slice and assign nodes
-Ask your PlanetLab PI to give you a new slice and assign the nodes you
-need
-@item Install a buildmaster
-You can stick to the buildbot documentation:@
-@uref{http://buildbot.net/buildbot/docs/current/manual/installation.html}
-@item Install the buildslave software on all nodes
-To install the buildslave on all nodes assigned to your slice you can use
-the tasklist @code{install_buildslave_fc8.xml} provided with GPLMT:
-
-@example
-./gplmt.py -c contrib/tumple_gnunet.conf -t \
-contrib/tasklists/install_buildslave_fc8.xml -a -p <planetlab password>
-@end example
-
-@item Create the buildmaster configuration and the slave setup commands
-
-The master and the and the slaves have need to have credentials and the
-master has to have all nodes configured. This can be done with the
-@file{create_buildbot_configuration.py} script in the @file{scripts}
-directory.
-
-This scripts takes a list of nodes retrieved directly from PlanetLab or
-read from a file and a configuration template and creates:
-
-@itemize @bullet
-@item a tasklist which can be executed with gplmt to setup the slaves
-@item a master.cfg file containing a PlanetLab nodes
-@end itemize
-
-A configuration template is included in the <contrib>, most important is
-that the script replaces the following tags in the template:
-
-%GPLMT_BUILDER_DEFINITION :@ GPLMT_BUILDER_SUMMARY@ GPLMT_SLAVES@
-%GPLMT_SCHEDULER_BUILDERS
-
-Create configuration for all nodes assigned to a slice:
-
-@example
-./create_buildbot_configuration.py -u <planetlab username> \
--p <planetlab password> -s <slice> -m <buildmaster+port> \
--t <template>
-@end example
-
-Create configuration for some nodes in a file:
-
-@example
-./create_buildbot_configuration.p -f <node_file> \
--m <buildmaster+port> -t <template>
-@end example
-
-@item Copy the @file{master.cfg} to the buildmaster and start it
-Use @code{buildbot start <basedir>} to start the server
-@item Setup the buildslaves
-@end itemize
-
-@c ***********************************************************************
-@node Why do i get an ssh error when using the regex profiler?
-@subsubsection Why do i get an ssh error when using the regex profiler?
-
-Why do i get an ssh error "Permission denied (publickey,password)." when
-using the regex profiler although passwordless ssh to localhost works
-using publickey and ssh-agent?
-
-You have to generate a public/private-key pair with no password:@
-@code{ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_localhost}@
-and then add the following to your ~/.ssh/config file:
-
-@code{Host 127.0.0.1@ IdentityFile ~/.ssh/id_localhost}
-
-now make sure your hostsfile looks like
-
-@example
-[USERNAME]@@127.0.0.1:22@
-[USERNAME]@@127.0.0.1:22
-@end example
-
-You can test your setup by running @code{ssh 127.0.0.1} in a
-terminal and then in the opened session run it again.
-If you were not asked for a password on either login,
-then you should be good to go.
-
 @cindex TESTBED Caveats
 @node TESTBED Caveats
 @subsection TESTBED Caveats
@@ -8116,6 +7958,14 @@ This section discusses the challenges and problems faced when writing the
 Ascension tool. It also takes a look at possible improvements in the
 future.
 
+Consider the following diagram that shows the workflow of Ascension:
+
+@image{images/ascension_ssd,6in,,Ascensions workflow}
+
+Further the interaction between components of GNUnet are shown in the diagram
+below:
+@center @image{images/ascension_interaction,,6in,Ascensions workflow}
+
 @menu
 * Conversions between DNS and GNS::
 * DNS Zone Size::
@@ -8126,9 +7976,9 @@ future.
 @node Conversions between DNS and GNS
 @subsubsection Conversions between DNS and GNS
 
-The differences between the two name systems lies in the details
-and is not always transparent.
-For instance an SRV record is converted to a GNS only BOX record.
+The differences between the two name systems lies in the details and is not
+always transparent.  For instance an SRV record is converted to a BOX record
+which is unique to GNS.
 
 This is done by converting to a BOX record from an existing SRV record:
 
@@ -8141,7 +7991,7 @@ _sip._tcp.example.com. 14000 IN SRV     0 0 5060 www.example.com.
 14000 BOX n 5060 6 33 0 0 5060 www.example.com
 @end example
 
-Other records that have such a transformation is the MX record type,
+Other records that need to undergo such transformation is the MX record type,
 as well as the SOA record type.
 
 Transformation of a SOA record into GNS works as described in the
@@ -8156,8 +8006,9 @@ following example. Very important to note are the rname and mname keys.
     604800     ; expire
     600 )      ; ttl
 # Recordline for adding the record
-$ gnunet-namestore -z example.com -a -n @ -t SOA -V rname=master.example.com \
-  mname=hostmaster.example.com 2017030300,3600,1800,604800,600 -e 7200s
+$ gnunet-namestore -z example.com -a -n @ -t SOA -V \
+    rname=master.example.com mname=hostmaster.example.com  \
+    2017030300,3600,1800,604800,600 -e 7200s
 @end example
 
 The transformation of MX records is done in a simple way.
@@ -8166,10 +8017,10 @@ The transformation of MX records is done in a simple way.
 $ gnunet-namestore -z example.com -n mail -R 3600 MX n 10,mail
 @end example
 
-Finally, one of the biggest struggling points were the NS records that are found
-in top level domain zones. The intended behaviour for those is to add GNS2DNS
-records for those so that gnunet-gns can resolve records for those domains on
-its own. This requires migration of the DNS GLUE records as well, provided that
+Finally, one of the biggest struggling points were the NS records that are
+found in top level domain zones. The intended behaviour for those is to add
+GNS2DNS records for those so that gnunet-gns can resolve records for those
+domains on its own. Those require the values from DNS GLUE records, provided
 they are within the same zone.
 
 The following two examples show one record with a GLUE record and the other one
@@ -8178,10 +8029,12 @@ does not have a GLUE record. This takes place in the 'com' TLD.
 @example
 # ns1.example.com 86400 IN A 127.0.0.1
 # example.com 86400 IN NS ns1.example.com.
-$ gnunet-namestore -z com -n example -R 86400 GNS2DNS n example.com@@127.0.0.1
+$ gnunet-namestore -z com -n example -R 86400 GNS2DNS n \
+    example.com@@127.0.0.1
 
 # example.com 86400 IN NS ns1.example.org.
-$ gnunet-namestore -z com -n example -R 86400 GNS2DNS n example.com@@ns1.example.org
+$ gnunet-namestore -z com -n example -R 86400 GNS2DNS n \
+    example.com@@ns1.example.org
 @end example
 
 As you can see, one of the GNS2DNS records has an IP address listed and the
@@ -8204,7 +8057,7 @@ Currently the following record types are supported:
 @item TXT
 @end itemize
 
-This is not due to a technical limitation but rather a practical one. The
+This is not due to technical limitations but rather a practical ones. The
 problem occurs with DNSSEC enabled DNS zones. As records within those zones are
 signed periodically, and every new signature is an update to the zone, there are
 many revisions of zones. This results in a problem with bigger zones as there
@@ -8214,16 +8067,22 @@ as they cause a CLI call of the namestore.  Furthermore certain record types
 need transformation into a GNS compatible format which, depending on the record
 type, takes more time.
 
+Further a blacklist was added to drop for instance DNSSEC related records. Also
+if a record type is neither in the white list nor the blacklist it is considered
+as a loss of data and a message is shown to the user. This helps with
+transparency and also with contributing, as the not supported record types can
+then be added accordingly.
+
 @node DNS Zone Size
 @subsubsection DNS Zone Size
-
 Another very big problem exists with very large zones. When migrating a small
 zone the delay between adding of records and their expiry is negligible. However
-when working with a TLD zone that has more that 1 million records this delay
-becomes a problem.
+when working with big zones that easily have more than a few million records
+this delay becomes a problem.
 
 Records will start to expire well before the zone has finished migrating. This
-causes unwanted anomalies when trying to resolve records.
+is usually not a problem but can cause a high CPU load when a peer is restarted
+and the records have expired.
 
 A good solution has not been found yet. One of the idea that floated around was
 that the records should be added with the s (shadow) flag to keep the records
@@ -8233,45 +8092,51 @@ of said record(s).
 
 Another problem that still persists is how to refresh records. Expired records
 are still displayed when calling gnunet-namestore but do not resolve with
-gnunet-gns. When doing incremental zone transfers this becomes especially
-apparent.
+gnunet-gns. Zonemaster will sign the expired records again and make sure that
+the records are still valid. With a recent change this was fixed as gnunet-gns
+to improve the suffix lookup which allows for a fast lookup even with thousands
+of local egos.
+
+Currently the pace of adding records in general is around 10 records per second.
+Crypto is the upper limit for adding of records. The performance of your machine
+can be tested with the perf_crypto_* tools. There is still a big discrepancy
+between the pace of Ascension and the theoretical limit.
 
-I estimate that the limit lies at about 200'000 records in a zone as this is
-the limit that my machine is capable of adding within one hour.  This was
-calculated by running cProfile on the application with a zone of 5000 records
-and calculating what abouts a much bigger zones with 8 million records would
-take. This results in a nice metric of records migrated per hour.
+A performance metric for measuring improvements has not yet been implemented in
+Ascension.
 
 @node Performance
 @subsubsection Performance
 The performance when migrating a zone using the Ascension tool is limited by a
 handful of factors. First of all ascension is written in Python3 and calls the
-CLI tools of GNUnet. Furthermore all the records that are added to the same
+CLI tools of GNUnet. This is comparable to a fork and exec call which costs a
+few CPU cycles. Furthermore all the records that are added to the same
 label are signed using the zones private key. This signing operation is very
 resource heavy and was optimized during development by adding the '-R'
-(Recordline) option to gnunet-namestore. This allows to add multiple records
-at once using the CLI.
-
-The result of this was a much faster migration of TLD zones, as most records
-with the same label have two name servers.
+(Recordline) option to gnunet-namestore which allows to specify multiple records
+using the CLI tool. Assuming that in a TLD zone every domain has at least two
+name servers this halves the amount of signatures needed.
 
 Another improvement that could be made is with the addition of multiple threads
-when opening the GNUnet CLI tools. This could be implemented by simply creating
-more workers in the program but performance improvements were not tested.
+or using asynchronous subprocesses when opening the GNUnet CLI tools. This could
+be implemented by simply creating more workers in the program but performance
+improvements were not tested.
 
-During the entire development of Ascension sqlite was used as a database
-backend for GNUnet. Other backends have not been tested yet.
+Ascension was tested using different hardware and database backends. Performance
+differences between SQLite and postgresql are marginal and almost non existent.
+What did make a huge impact on record adding performance was the storage medium.
+On a traditional mechanical hard drive adding of records were slow compared to a
+solid state disk.
 
 In conclusion there are many bottlenecks still around in the program, namely the
-signing process and the single threaded implementation. In the future a solution
-that uses the C API would be cleaner and better.
+single threaded implementation and inefficient, sequential calls of
+gnunet-namestore. In the future a solution that uses the C API would be cleaner
+and better.
 
 @cindex GNS Namecache
 @node GNS Namecache
 @section GNS Namecache
 
-
-
 The NAMECACHE subsystem is responsible for caching (encrypted) resolution
 results of the GNU Name System (GNS). GNS makes zone information available
 to other users via the DHT. However, as accessing the DHT for every
@@ -9007,3 +8872,72 @@ so please make sure that endpoints are unambiguous.
 
 This is WIP. Endpoints should be documented appropriately.
 Preferably using annotations.
+
+
+@cindex RPS Subsystem
+@node RPS Subsystem
+@section RPS Subsystem
+
+In literature, Random Peer Sampling (RPS) refers to the problem of
+reliably drawing random samples from an unstructured p2p network.
+
+Doing so in a reliable manner is not only hard because of inherent
+problems but also because of possible malicious peers that could try to
+bias the selection.
+
+It is useful for all kind of gossip protocols that require the selection
+of random peers in the whole network like gathering statistics,
+spreading and aggregating information in the network, load balancing and
+overlay topology management.
+
+The approach chosen in the rps implementation in GNUnet follows the
+Brahms@uref{https://bib.gnunet.org/full/date.html\#2009_5f0} design.
+
+The current state is "work in progress". There are a lot of things that
+need to be done, primarily finishing the experimental evaluation and a
+re-design of the API.
+
+The abstract idea is to subscribe to connect to/start the rps service
+and request random peers that will be returned when they represent a
+random selection from the whole network with high probability.
+
+An additional feature to the original Brahms-design is the selection of
+sub-groups: The GNUnet implementation of rps enables clients to ask for
+random peers from a group that is defined by a common shared secret.
+(The secret could of course also be public, depending on the use-case.)
+
+Another addition to the original protocol was made: The sampler
+mechanism that was introduced in Brahms was slightly adapted and used to
+actually sample the peers and returned to the client.
+This is necessary as the original design only keeps peers connected to
+random other peers in the network. In order to return random peers to
+client requests independently random, they cannot be drawn from the
+connected peers.
+The adapted sampler makes sure that each request for random peers is
+independent from the others.
+
+@node Brahms
+@subsection Brahms
+The high-level concept of Brahms is two-fold: Combining push-pull gossip
+with locally fixing a assumed bias using cryptographic min-wise
+permutations.
+The central data structure is the view - a peer's current local sample.
+This view is used to select peers to push to and pull from.
+This simple mechanism can be biased easily. For this reason Brahms
+'fixes' the bias by using the so-called sampler. A data structure that
+takes a list of elements as input and outputs a random one of them
+independently of the frequency in the input set. Both an element that
+was put into the sampler a single time and an element that was put into
+it a million times have the same probability of being the output.
+This is achieved this is achieved with exploiting min-wise independent
+permutations. In rps we use HMACs: On the initialisation of a sampler
+element, a key is chosen at random. On each input the HMAC with the
+random key is computed. The sampler element keeps the element with the
+minimal HMAC.
+
+In order to fix the bias in the view, a fraction of the elements in the
+view are sampled through the sampler from the random stream of peer IDs.
+
+According to the theoretical analysis of Bortnikov et al. this suffices
+to keep the network connected and having random peers in the view.
+
diff --git a/doc/handbook/chapters/installation.texi b/doc/handbook/chapters/installation.texi
index d02fc7f82..a508feb6a 100644
--- a/doc/handbook/chapters/installation.texi
+++ b/doc/handbook/chapters/installation.texi
@@ -1786,10 +1786,21 @@ Keeping a virtual environment helps with keeping things tidy and prevents
 breaking of Ascension through a future Python update.
 
 The advantage of using a virtual environment is, that all the dependencies can
-be installed separately in different versions without touching your system
+be installed separately in different versions without touching your systems
 Python installation and its dependencies.
 
-@xref{Migrating an existing DNS zone into GNS}, for usage manual of the tool.
+Another way to install Ascension on Debian is to install the python3-ascension
+package. It can be found within the above mentioned Ascension git repository.
+This also adds a system user ascension and runs a GNUnet peer in the
+background. Attention: This only works if a recent version of GNUnet is
+installed on your system. The version number of Ascension is chosen according
+to the required feature level of GNUnet. I.e. Ascension 0.11.5 is only
+compatible with GNUnet 0.11.5 and upwards. As Debian's packages for GNUnet are
+outdated even in experimental, you will need to install GNUnet manually.
+@xref{Installing GNUnet}
+
+Please check @xref{Migrating an existing DNS zone into GNS}, for usage manual
+of the tool.
 
 @node Configuring the GNUnet VPN
 @subsection Configuring the GNUnet VPN
diff --git a/doc/handbook/chapters/keyconcepts.texi b/doc/handbook/chapters/keyconcepts.texi
index 4900ed328..bdfa5b631 100644
--- a/doc/handbook/chapters/keyconcepts.texi
+++ b/doc/handbook/chapters/keyconcepts.texi
@@ -319,3 +319,4 @@ Egos are your "identities" in GNUnet. Any user can assume multiple
 identities, for example to separate their activities online. Egos can
 correspond to "pseudonyms" or "real-world identities". Technically an
 ego is first of all a key pair of a public- and private-key.
+
diff --git a/doc/handbook/chapters/user.texi b/doc/handbook/chapters/user.texi
index 55518bc34..fcf5e7871 100644
--- a/doc/handbook/chapters/user.texi
+++ b/doc/handbook/chapters/user.texi
@@ -526,7 +526,7 @@ shell) and create an entry home-phone in your master zone.
 For the record type, select PHONE. You should then see the
 PHONE dialog:
 
-@c image here
+@image{images/gnunet-namestore-gtk-phone,5in,,Dialog to publish a PHONE record}
 
 Note: Do not choose the expiry time to be 'Never'. If you
 do that, you assert that this record will never change and
@@ -645,7 +645,7 @@ Now, using your normal user (not the @code{gnunet} system user), run
 master zone. For the record type, select @code{VPN}. You should then
 see the VPN dialog:
 
-@c insert image
+@image{images/gnunet-namestore-gtk-vpn,5in,,Dialog to publish a VPN record}
 
 Under peer, you need to supply the peer identity of your own peer. You can
 obtain the respective string by running @command{gnunet-peerinfo -sq}
@@ -926,7 +926,7 @@ concepts that are used to achieve these goals.
 * Files::
 * Keywords::
 * Directories::
-* Pseudonyms::
+* Egos and File-Sharing::
 * Namespaces::
 * Advertisements::
 * Anonymity level::
@@ -984,69 +984,55 @@ typically includes the mime-type, description, a filename and
 other meta information, and possibly even the full original file
 (if it was small).
 
-@node Pseudonyms
-@subsubsection Pseudonyms
+@node Egos and File-Sharing
+@subsubsection Egos and File-Sharing
 
+When sharing files, it is sometimes desirable to build a reputation as
+a source for quality information.  With egos, publishers can
+(cryptographically) sign files, thereby demonstrating that various
+files were published by the same entity.  An ego thus allows users to
+link different publication events, thereby deliberately reducing
+anonymity to pseudonymity.
 
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
+Egos used in GNUnet's file-sharing for such pseudonymous publishing
+also correspond to the egos used to identify and sign zones in the
+GNU Name System.  However, if the same ego is used for file-sharing
+and for a GNS zone, this will weaken the privacy assurances provided
+by the anonymous file-sharing protocol.
 
-Pseudonyms in GNUnet are essentially public-private (RSA) key pairs
-that allow a GNUnet user to maintain an identity (which may or may not
-be detached from their real-life identity). GNUnet's pseudonyms are not
-file-sharing specific --- and they will likely be used by many GNUnet
-applications where a user identity is required.
+Note that an ego is NOT bound to a GNUnet peer. There can be multiple
+egos for a single user, and users could (theoretically) share
+the private keys of an ego by copying the respective private keys.
 
-Note that a pseudonym is NOT bound to a GNUnet peer. There can be multiple
-pseudonyms for a single user, and users could (theoretically) share the
-private pseudonym keys (currently only out-of-band by knowing which files
-to copy around).
 
 @node Namespaces
 @subsubsection Namespaces
 
+A namespace is a set of files that were signed by the same ego.
+Today, namespaces are implemented independently of GNS zones, but
+in the future we plan to merge the two such that a GNS zone can
+basically contain files using a file-sharing specific record type.
 
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
-A namespace is a set of files that were signed by the same pseudonym.
-Files (or directories) that have been signed and placed into a namespace
-can be updated. Updates are identified as authentic if the same secret
-key was used to sign the update. Namespaces are also useful to establish
-a reputation, since all of the content in the namespace comes from the
-same entity (which does not have to be the same person).
+Files (or directories) that have been signed and placed into a
+namespace can be updated. Updates are identified as authentic if the
+same secret key was used to sign the update. 
 
 @node Advertisements
 @subsubsection Advertisements
 
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
 Advertisements are used to notify other users about the existence of a
-namespace. Advertisements are propagated using the normal keyword search.
-When an advertisement is received (in response to a search), the namespace
-is added to the list of namespaces available in the namespace-search
-dialogs of gnunet-fs-gtk and printed by @code{gnunet-identity}. Whenever a
-namespace is created, an appropriate advertisement can be generated.
-The default keyword for the advertising of namespaces is "namespace".
-
-Note that GNUnet differentiates between your pseudonyms (the identities
-that you control) and namespaces. If you create a pseudonym, you will
-not automatically see the respective namespace. You first have to create
-an advertisement for the namespace and find it using keyword
-search --- even for your own namespaces. The @command{gnunet-identity}
-tool is currently responsible for both managing pseudonyms and namespaces.
-This will likely change in the future to reduce the potential for
-confusion.
+namespace. Advertisements are propagated using the normal keyword
+search.  When an advertisement is received (in response to a search),
+the namespace is added to the list of namespaces available in the
+namespace-search dialogs of gnunet-fs-gtk and printed by
+@code{gnunet-identity}. Whenever a namespace is created, an
+appropriate advertisement can be generated.  The default keyword for
+the advertising of namespaces is "namespace".
+
 
 @node Anonymity level
 @subsubsection Anonymity level
 
-
 The anonymity level determines how hard it should be for an adversary to
 determine the identity of the publisher or the searcher/downloader. An
 anonymity level of zero means that anonymity is not required. The default
@@ -1066,10 +1052,10 @@ delays traffic.
 While higher anonymity levels may offer better privacy, they can also
 significantly hurt performance.
 
+
 @node Content Priority
 @subsubsection Content Priority
 
-
 Depending on the peer's configuration, GNUnet peers migrate content
 between peers. Content in this sense are individual blocks of a file,
 not necessarily entire files. When peers run out of space (due to
@@ -1083,10 +1069,10 @@ lowest priority. The priority of a block is decided by its popularity
 published locally, the base-priority that was specified by the user
 when the block was published initially.
 
+
 @node Replication
 @subsubsection Replication
 
-
 When peers migrate content to other systems, the replication level
 of a block is used to decide which blocks need to be migrated most
 urgently. GNUnet will always push the block with the highest
@@ -1098,99 +1084,37 @@ selection is simply random.
 @node Namespace Management
 @subsection Namespace Management
 
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-
-The @code{gnunet-identity} tool can be used to create pseudonyms and
-to advertise namespaces. By default, @code{gnunet-identity -D} simply
-lists all locally available pseudonyms.
+The @code{gnunet-identity} tool can be used to create egos.
+By default, @code{gnunet-identity -D} simply
+lists all locally available egos.
 
 
 @menu
-* Creating Pseudonyms::
-* Deleting Pseudonyms::
-* Advertising namespaces::
-* Namespace names::
-* Namespace root::
+* Creating Egos::
+* Deleting Egos::
 @end menu
 
-@node Creating Pseudonyms
-@subsubsection Creating Pseudonyms
+@node Creating Egos
+@subsubsection Creating Egos
 
+With the @command{-C NICK} option it can also be used to create a new
+ego. An ego is the virtual identity of the entity in control of a
+namespace or GNS zone. Anyone can create any number of egos.  The
+provided NICK name automatically corresponds to a GNU Name System
+domain name.  Thus, henceforth name resolution for any name ending in
+``.NICK'' will use the NICK's zone.  You should avoid using NICKs that
+collide with well-known DNS names.
 
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
+@node Deleting Egos
+@subsubsection Deleting Egos
 
-With the @command{-C NICK} option it can also be used to
-create a new pseudonym. A pseudonym is the virtual identity
-of the entity in control of a namespace. Anyone can create
-any number of pseudonyms. Note that creating a pseudonym can
-take a few minutes depending on the performance of the machine
-used.
+With the @command{-D NICK} option egos can be deleted.  Once the ego
+has been deleted it is impossible to add content to the corresponding
+namespace or zone. However, the existing GNS zone data is currently
+not dropped. This may change in the future.
 
-@node Deleting Pseudonyms
-@subsubsection Deleting Pseudonyms
-
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
-With the @command{-D NICK} option pseudonyms can be deleted.
-Once the pseudonym has been deleted it is impossible to add
-content to the corresponding namespace. Deleting the
-pseudonym does not make the namespace or any content in it
-unavailable.
-
-@node Advertising namespaces
-@subsubsection Advertising namespaces
-
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
-Each namespace is associated with meta-data that describes
-the namespace. This meta-data is provided by the user at
-the time that the namespace is advertised. Advertisements
-are published under keywords so that they can be found using
-normal keyword-searches. This way, users can learn about new
-namespaces without relying on out-of-band communication or directories.
-A suggested keyword to use for all namespaces is simply "namespace".
-When a keyword-search finds a namespace advertisement,
-it is automatically stored in a local list of known namespaces.
-Users can then associate a rank with the namespace to remember
-the quality of the content found in it.
-
-@node Namespace names
-@subsubsection Namespace names
-
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
-While the namespace is uniquely identified by its ID, another way
-to refer to the namespace is to use the NICKNAME.
-The NICKNAME can be freely chosen by the creator of the namespace and
-hence conflicts are possible. If a GNUnet client learns about more
-than one namespace using the same NICKNAME, the ID is appended
-to the NICKNAME to get a unique identifier.
-
-@node Namespace root
-@subsubsection Namespace root
-
-
-@b{Please note that the text in this subsection is outdated and needs}
-@b{to be rewritten for version 0.10!}
-@b{This especially concerns the terminology of Pseudonym/Ego/Identity.}
-
-An item of particular interest in the namespace advertisement is
-the ROOT. The ROOT is the identifier of a designated entry in the
-namespace. The idea is that the ROOT can be used to advertise an
-entry point to the content of the namespace.
+Deleting the pseudonym does not make the namespace or any content in
+it unavailable.
 
 @node File-Sharing URIs
 @subsection File-Sharing URIs
@@ -1314,12 +1238,12 @@ To publish a file, select "File Sharing" in the menu bar just below the
 
 Afterwards, the following publishing dialog will appear:
 
-@c Add image here
+@image{images/gnunet-gtk-0-10-fs-publish,5in,,The gnunet-fs-gtk publishing dialog}
 
 In this dialog, select the "Add File" button. This will open a
 file selection dialog:
 
-@c Add image here
+@image{images/gnunet-gtk-0-10-fs-publish-select,5in,,Dialog to select the file to publish (looks may differ for other Gtk+ versions)}
 
 Now, you should select a file from your computer to be published on
 GNUnet. To see more of GNUnet's features later, you should pick a
@@ -1335,12 +1259,12 @@ and potential errors that might be encountered during processing.
 After the progress dialog automatically disappears, your file
 should now appear in the publishing dialog:
 
-@c Add image here
+@image{images/gnunet-gtk-0-10-fs-publish-with-file,5in,,Publishing dialog with file added}
 
 Now, select the file (by clicking on the file name) and then click
 the "Edit" button. This will open the editing dialog:
 
-@c Add image here
+@image{images/gnunet-gtk-0-10-fs-publish-editing,5in,,Editing meta data of a file to be published}
 
 In this dialog, you can see many details about your file. In the
 top left area, you can see meta data extracted about the file,
@@ -1364,9 +1288,7 @@ You should now be back at the "Publish content on GNUnet" dialog. Select
 "Execute" in the bottom right to close the dialog and publish your file
 on GNUnet! Afterwards, you should see the main dialog with a new area
 showing the list of published files (or ongoing publishing operations
-with progress indicators):
-
-@c Add image here
+with progress indicators).
 
 @node gtk-Searching
 @subsubsection Searching
@@ -1920,33 +1842,42 @@ options:
 
 @example
 Ascension
-
 Usage:
-    ascension <domain> [-d] [-p]
-    ascension <domain> <port> [-d] [-p]
-    ascension <domain> -n <transferns> [-d] [-p]
-    ascension <domain> -n <transferns> <port> [-d] [-p]
+    ascension <domain> [-d] [-p] [-s] [--minimum-ttl=<ttl>] \
+        [--dry-run]
+    ascension <domain> <port> [-d] [-p] [-s] \
+        [--minimum-ttl=<ttl>] [--dry-run]
+    ascension <domain> -n <transferns> [-d] [-p] \
+        [-s] [--minimum-ttl=<ttl>] [--dry-run]
+    ascension <domain> -n <transferns> <port> [-d] \
+        [-p] [-s] [--minimum-ttl=<ttl>] [--dry-run]
     ascension -p | --public
+    ascension -d | --debug
+    ascension -s | --standalone
     ascension -h | --help
     ascension -v | --version
 
 Options:
-    <domain>        Domain to migrate
-    <port>          Port for zone transfer
-    <transferns>    DNS Server that does the zone transfer
-    -p --public     Make records public on the DHT
-    -d --debug      Enable debugging
-    -h --help       Show this screen.
-    -v --version    Show version.
+    <domain>              Domain to migrate
+    <port>                Port for zone transfer
+    <transferns>          DNS Server that does the zone transfer
+    --minimum-ttl=<ttl>   Minimum TTL for records to migrate \
+        [default: 3600]
+    --dry-run             Only try if a zone transfer is allowed
+    -p --public           Make records public on the DHT
+    -s --standalone       Run ascension once
+    -d --debug            Enable debugging
+    -h --help         Show this screen.
+    -v --version      Show version.
 @end example
 
-Before you can migrate any zone though, you need to start the GNUnet peer:
+Before you can migrate any zone though, you need to start a local GNUnet peer:
 @example
 $ gnunet-arm -s
 @end example
 
 To migrate the Syrian top level domain - one of the few top level domains that
-still supports zone transfers - into GNS use the following command:
+support zone transfers - into GNS use the following command:
 
 @example
 $ ascension sy. -n ns1.tld.sy. -p
@@ -1959,33 +1890,39 @@ Once the zone is migrated, Ascension will output a message telling you, that it
 will refresh the zone after the time has elapsed.  You can resolve the names in
 the zone directly using GNS or if you want to use it with your browser, check
 out the GNS manual section. @ref{Configuring the GNU Name System}. To resolve
-the records from another system you need the zone PKEY.  To get the zone key,
-you can run the following command:
+the records from another system you need the respective zones PKEY. To get the
+zones public key, you can run the following command:
 
 @example
-$ gnunet-identity -d | grep ^sy | cut -d " " -f3
+$ gnunet-identity -dqe sy
 @end example
 
 Where "sy" is the name of the zone you want to migrate.
 
-As soon as the public flag is implemented, you can share the PKEY of the zone
-with your friends. They can then resolve records in the zone by doing a lookup
-replacing the zone label with your PKEY:
+You can share the PKEY of the zone with your friends. They can then resolve
+records in the zone by doing a lookup replacing the zone label with your PKEY:
 
 @example
-$ gnunet-gns -t SOA -u "@.$PKEY"
+$ gnunet-gns -t SOA -u "$PKEY"
 @end example
 
 The program will continue to run as a daemon and update once the refresh time
 specified in the zones SOA record has elapsed.
 
-The next step would be to add the PKEY record as a DNScurve style NS record
-into the existing DNS zone to enable clients to detect that this zone has
-already been migrated to GNS and to also have a means of distributing the PKEY
-seamlessly.
+DNSCurve style records are supported in the latest release and they are added
+as a PKEY record to be referred to the respective GNS public key. Key
+distribution is still a problem but provided someone else has a public key
+under a given label it can be looked up.
+
+There is an unofficial Debian package called python3-ascension that adds a
+system user ascension and runs a GNUnet peer in the background.
 
-At this point you might want to write for example a systemd unit file to start
-and enable the service, so that your zone is migrated automatically.
+Ascension-bind is also an unofficial Debian package that on installation checks
+for running DNS zones and whether or not they are transferable using DNS zone
+transfer (AXFR). It asks the administrator which zones to migrate into GNS and
+installs a systemd unit file to keep the zone up to date.  If you want to
+migrate different zones you might want to check the unit file from the package
+as a guide.
 
 @node reclaimID Identity Provider
 @section reclaimID Identity Provider
diff --git a/doc/handbook/images/ascension_interaction.png b/doc/handbook/images/ascension_interaction.png
new file mode 100644
index 000000000..84e2e9c0f
--- /dev/null
+++ b/doc/handbook/images/ascension_interaction.png
diff --git a/doc/handbook/images/ascension_ssd.png b/doc/handbook/images/ascension_ssd.png
new file mode 100644
index 000000000..3b142ab31
--- /dev/null
+++ b/doc/handbook/images/ascension_ssd.png
diff --git a/doc/man/gnunet-config.1 b/doc/man/gnunet-config.1
index 0e612fe29..95dc98811 100644
--- a/doc/man/gnunet-config.1
+++ b/doc/man/gnunet-config.1
@@ -30,6 +30,7 @@
 manipulate GNUnet configuration files
 .Sh SYNOPSIS
 .Nm
+.Op Fl b Ar BACKEND | Fl \-supported-backend= Ns Ar BACKEND
 .Op Fl c Ar FILENAME | Fl \-config= Ns Ar FILENAME
 .Op Fl f | \-filename
 .Op Fl h | \-help
@@ -44,6 +45,8 @@ manipulate GNUnet configuration files
 .Nm
 can be used to read or modify GNUnet configuration files.
 .Bl -tag -width indent
+.It Fl b Ar BACKEND | Fl \-supported-backend= Ns Ar BACKEND
+Tests whether the specified BACKEND is supported by the current installation.  The backend must match the name of a plugin, i.e. "namestore_postgres" for the Postgres database backend of the "NAMESTORE" service. If the BACKEND is supported, gnunet-config will return a status code of 0 (success), otherwise 77 (unsupported).  When this option is specified, no other options may be specified. Specifying this option together with other options will cause gnunet-config to return a status code of 1 (error).
 .It Fl c Ar FILENAME | Fl \-config= Ns Ar FILENAME
 Use the configuration file FILENAME.
 .It Fl f | \-filename