From 8d48dbafe69193f8a23765154be1f7db851bfa1c Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 24 Apr 2021 00:02:25 +0200 Subject: -fix typos --- doc/handbook/chapters/developer.texi | 30 +++++++++++++++--------------- doc/handbook/chapters/installation.texi | 8 ++++---- doc/handbook/chapters/keyconcepts.texi | 2 +- doc/handbook/chapters/philosophy.texi | 2 +- doc/handbook/chapters/preface.texi | 4 ++-- doc/handbook/chapters/user.texi | 8 ++++---- 6 files changed, 27 insertions(+), 27 deletions(-) (limited to 'doc/handbook') 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. -- cgit v1.2.3