-fix typos

6 files changed, 27 insertions, 27 deletions

diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
index 9bb74c3de..e7b88a39f 100644
--- a/doc/handbook/chapters/developer.texi
+++ b/doc/handbook/chapters/developer.texi
@@ -2305,7 +2305,7 @@ for new developers):
 @itemize @bullet
 @item logging (common_logging.c)
 @item memory allocation (common_allocation.c)
-@item endianess conversion (common_endian.c)
+@item endianness conversion (common_endian.c)
 @item internationalization (common_gettext.c)
 @item String manipulation (string.c)
 @item file access (disk.c)
@@ -4287,7 +4287,7 @@ which will warn you if you don't have the necessary libraries.
 @c work!@ Finally you just have to be sure that you have the correct drivers
 @c for your Bluetooth device installed and that your device is on and in a
 @c discoverable mode. The Windows Bluetooth Stack supports only the RFCOMM
-@c protocol so we cannot turn on your device programatically!
+@c protocol so we cannot turn on your device programmatically!
 
 @c FIXME: Change to unique title
 @node How does it work2?
@@ -4638,7 +4638,7 @@ simply use the socket.
 @c implementation follows the same principles as the GNU/Linux one:
 
 @c @itemize @bullet
-@c @item It has a initalization part where it initializes the
+@c @item It has a initialization part where it initializes the
 @c Windows Sockets, creates a RFCOMM socket which will be binded and switched
 @c to the listening mode and registers a SDP service. In the Microsoft
 @c Bluetooth API there are two ways to work with the SDP:
@@ -5023,7 +5023,7 @@ key of the other peer
 ephemeral key of the other peer, but we are waiting for the other peer to
 confirm it's authenticity (ability to decode) via challenge-response.
 @item @code{KX_STATE_UP} The connection is fully up from the point of
-view of the sender (now performing keep-alives)
+view of the sender (now performing keep-alive)
 @item @code{KX_STATE_REKEY_SENT} The sender has initiated a rekeying
 operation; the other peer has so far failed to confirm a working
 connection using the new ephemeral key
@@ -5653,7 +5653,7 @@ download. The client component is basically a HTTP client
 (based on libcurl) which can download hostlists from one or more websites.
 The hostlist format is a binary blob containing a sequence of HELLO
 messages. Note that any HTTP server can theoretically serve a hostlist,
-the build-in hostlist server makes it simply convenient to offer this
+the built-in hostlist server makes it simply convenient to offer this
 service.
 
 
@@ -5895,7 +5895,7 @@ The size of the list of URLs is restricted, so if an additional server is
 added and the list is full, the URL with the worst quality ranking
 (determined through successful downloads and number of HELLOs e.g.) is
 discarded. During shutdown the list of URLs is saved to a file for
-persistance and loaded on startup. URLs from the configuration file are
+persistence and loaded on startup. URLs from the configuration file are
 never discarded.
 
 @node Usage
@@ -6155,7 +6155,7 @@ To disconnect from NAMESTORE, clients use
 @code{GNUNET_NAMESTORE_disconnect} and specify the handle to disconnect.
 
 NAMESTORE internally uses the ECDSA private key to refer to zones. These
-private keys can be obtained from the IDENTITY subsytem.
+private keys can be obtained from the IDENTITY subsystem.
 Here @emph{egos} @emph{can be used to refer to zones or the default ego
 assigned to the GNS subsystem can be used to obtained the master zone's
 private key.}
@@ -6811,7 +6811,7 @@ the client.
 
 
 
-Each listener also requires a seperate client connection. By sending the
+Each listener also requires a separate client connection. By sending the
 @code{GNUNET_SERVICE_SET_LISTEN} message, the client notifies the service
 of the application id and operation type it is interested in. A client
 rejects an incoming request by sending @code{GNUNET_SERVICE_SET_REJECT}
@@ -7147,7 +7147,7 @@ the client.
 @node Listeners for Intersection
 @subsubsection Listeners for Intersection
 
-Each listener also requires a seperate client connection. By sending the
+Each listener also requires a separate client connection. By sending the
 @code{GNUNET_SERVICE_SETI_LISTEN} message, the client notifies the service
 of the application id and operation type it is interested in. A client
 rejects an incoming request by sending @code{GNUNET_SERVICE_SETI_REJECT}
@@ -7409,7 +7409,7 @@ the client.
 @node Listeners for Union
 @subsubsection Listeners for Union
 
-Each listener also requires a seperate client connection. By sending the
+Each listener also requires a separate client connection. By sending the
 @code{GNUNET_SERVICE_SETU_LISTEN} message, the client notifies the service
 of the application id and operation type it is interested in. A client
 rejects an incoming request by sending @code{GNUNET_SERVICE_SETU_REJECT}
@@ -7832,7 +7832,7 @@ performance).
 Third, an optional Bloom filter can be specified to exclude known results;
 replies that hash to the bits set in the Bloom filter are considered
 invalid. False-positives can be eliminated by sending the same query
-again with a different Bloom filter mutator value, which parameterizes
+again with a different Bloom filter mutator value, which parametrizes
 the hash function that is used.
 Finally, an optional application-specific "eXtended query" (xquery) can
 be specified to further constrain the results. It is entirely up to
@@ -9810,7 +9810,7 @@ properties designed for application level usage:
 @item MESSENGER allows detection for dropped messages by chaining them (messages 
       refer to the last message by their hash) improving accountability
 @item MESSENGER allows requesting messages from other peers explicitly to ensure
-      availibility
+      availability
 @item MESSENGER provides confidentiality by padding messages to few different
       sizes (512 bytes, 4096 bytes, 32768 bytes and maximal message size from 
       CADET)
@@ -9825,13 +9825,13 @@ Also MESSENGER provides multiple features with privacy in mind:
 @itemize @bullet
 @item MESSENGER allows deleting messages from all peers in the group by the 
       original sender (uses the MESSENGER provided verification)
-@item MESSENGER allows using the publically known anonymous ego instead of any
+@item MESSENGER allows using the publicly known anonymous ego instead of any
       unique identifying ego
 @item MESSENGER allows your node to decide between acting as host of the used 
       messaging room (sharing your peer's identity with all nodes in the group) 
       or acting as guest (sharing your peer's identity only with the nodes you
       explicitly open a connection to)
-@item MESSENGER handles members independantly of the peer's identity making 
+@item MESSENGER handles members independently of the peer's identity making 
       forwarded messages indistinguishable from directly received ones (
       complicating the tracking of messages and identifying its origin)
 @item MESSENGER allows names of members being not unique (also names are 
@@ -9977,7 +9977,7 @@ check for completion of a member session requires this information.
 
 A member session is a triple of the room key, the member ID and the public key 
 of the member's ego. Member sessions allow that a member can change their ID or 
-their ego once at a time without loosing the ability to delete old messages or 
+their ego once at a time without losing the ability to delete old messages or 
 identifying the original sender of a message. On every change of ID or EGO a 
 session will be marked as closed. So every session chain will only contain one 
 open session with the current ID and public key.
diff --git a/doc/handbook/chapters/installation.texi b/doc/handbook/chapters/installation.texi
index 40a23e738..ad939b5b7 100644
--- a/doc/handbook/chapters/installation.texi
+++ b/doc/handbook/chapters/installation.texi
@@ -171,7 +171,7 @@ group. In addition the group @code{gnunetdns} may be needed (see below).
 
 Create user @code{gnunet} who is member of the group @code{gnunet}
 (automatically created) and specify a home directory where the GNUnet
-services will store persistant data such as information about peers.
+services will store persistent data such as information about peers.
 @example
 $ sudo useradd --system --home-dir /var/lib/gnunet --create-home gnunet
 @end example
@@ -431,7 +431,7 @@ For the @emph{multi-user setup} first the system services need to be started
 as the system user, i.e. the user @code{gnunet} needs to execute
 @code{gnunet-arm -s}. This should be done by the system's init system.
 Then the user who wants to start GNUnet applications has to run
-@code{gnunet-arm -s} too. It is recommented to automate this, e.g. using
+@code{gnunet-arm -s} too. It is recommended to automate this, e.g. using
 the user's crontab.
 
 @node gnunet-gtk
@@ -1369,7 +1369,7 @@ proxy forwards the HTTP request he receives with a certain URL to another
 webserver, here a GNUnet peer.
 
 So if you have a running Apache or nginx webserver you can configure it to
-be a GNUnet reverse proxy. Especially if you have a well-known webiste
+be a GNUnet reverse proxy. Especially if you have a well-known website
 this improves censorship resistance since it looks as normal surfing
 behaviour.
 
@@ -2175,7 +2175,7 @@ Sane defaults should exist in your
 you could simply start without any configuration. If you want to
 configure your peer later, you need to stop it before invoking the
 @code{gnunet-setup} tool to customize further and to test your
-configuration (@code{gnunet-setup} has build-in test functions).
+configuration (@code{gnunet-setup} has built-in test functions).
 
 The most important option you might have to still set by hand is in
 [PATHS]. Here, you use the option "GNUNET_HOME" to specify the path where
diff --git a/doc/handbook/chapters/keyconcepts.texi b/doc/handbook/chapters/keyconcepts.texi
index f429997bf..49129acf5 100644
--- a/doc/handbook/chapters/keyconcepts.texi
+++ b/doc/handbook/chapters/keyconcepts.texi
@@ -242,7 +242,7 @@ against identification.
 
 The messaging service allows the use of an anonymous ego for the signing and
 verification process of messages instead of a unique ego. This anonymous ego is
-a publically known key pair which is shared between all peers in GNUnet.
+a publicly known key pair which is shared between all peers in GNUnet.
 
 Using this ego only ensures that individual messages alone can't identify its 
 sender inside of a messenger room. It should be clarified that the route of 
diff --git a/doc/handbook/chapters/philosophy.texi b/doc/handbook/chapters/philosophy.texi
index 060871189..785a65e42 100644
--- a/doc/handbook/chapters/philosophy.texi
+++ b/doc/handbook/chapters/philosophy.texi
@@ -70,7 +70,7 @@ applications.
 @node Practicality
 @section Practicality
 
-Whereever possible GNUnet allows the peer to adjust its operations and
+Wherever possible GNUnet allows the peer to adjust its operations and
 functionalities to specific use cases. A GNUnet peer running on a
 mobile device with limited battery for example might choose not to
 relay traffic for other participants.
diff --git a/doc/handbook/chapters/preface.texi b/doc/handbook/chapters/preface.texi
index 62ced08a4..d1afdf756 100644
--- a/doc/handbook/chapters/preface.texi
+++ b/doc/handbook/chapters/preface.texi
@@ -85,7 +85,7 @@ book which explains GNUnet in the least complicated way to you.
 
 Even when you don't want to or can't learn Texinfo, you can contribute.
 Send us an Email or join our IRC chat room on freenode and talk with
-us about the documentation (the prefered way to reach out is the
+us about the documentation (the preferred way to reach out is the
 mailinglist, since you can communicate with us without waiting on
 someone in the chatroom).
 One way or another you can help shape the understanding of GNUnet
@@ -144,7 +144,7 @@ and privacy-preserving online payments.  In 2015, the
 @c XXX: but the correct version would lead to problems with
 @c XXX: some of our outputs and/or older versions of texinfo
 @c XXX: and devices that display versions on consoles etc.
-@c XXX: This is why we keep the pEp until proven that p(tripple bar)p
+@c XXX: This is why we keep the pEp until proven that p(triple bar)p
 @c XXX: does not create broken outputs.
 @uref{https://pep.foundation/, pretty Easy privacy} (pEp) project
 announced that they will use GNUnet as the technology for their
diff --git a/doc/handbook/chapters/user.texi b/doc/handbook/chapters/user.texi
index b5889891b..911d23526 100644
--- a/doc/handbook/chapters/user.texi
+++ b/doc/handbook/chapters/user.texi
@@ -109,7 +109,7 @@ rules - GO0T87F9BPMF8NKD5A54L2AH1T0GRML539TPFSRMCEA98182QD30
 @subsection The GNS Tab
 
 
-Maintaing your zones is through the NAMESTORE service and is discussed
+Maintaining your zones is through the NAMESTORE service and is discussed
 here.  You can manage your zone using @command{gnunet-identity} and
 @command{gnunet-namestore}, or most conveniently using
 @command{gnunet-namestore-gtk}.
@@ -1633,7 +1633,7 @@ are BOXed up.
 @subsubsection LEHO
 
 The LEgacy HOstname of a server. Some webservers expect a specific
-hostname to provide a service (virtiual hosting). Also SSL
+hostname to provide a service (virtual hosting). Also SSL
 certificates usually contain DNS names. To provide the expected
 legacy DNS name for a server, the LEHO record can be used.
 To mitigate the just mentioned issues the GNS proxy has to be used.
@@ -2404,7 +2404,7 @@ $ gnunet-peerinfo -s
 
 A ROOMKEY gets entered in readable text form. The service will then hash the 
 entered ROOMKEY and use the result as shared secret for transmission through 
-the CADET submodule. You can also optionally leave out the '-r' paramter and 
+the CADET submodule. You can also optionally leave out the '-r' parameter and 
 the ROOMKEY to use the zeroed hash instead.
 
 If no IDENTITY is provided you will not send any name to others, you will be 
@@ -2478,7 +2478,7 @@ $ gnunet-messenger [-e IDENTITY] -d PEERIDENTITY -r ROOMKEY -p
 @end example
 
 Notice that you can only send such encrypted messages to members who use an ego
-which is not publically known as the anonymous ego to ensure transparency. If 
+which is not publicly known as the anonymous ego to ensure transparency. If 
 any user could decrypt these messages they would not be private. So as receiver
 of such messages the IDENTITY is required and it has to match a local ego.