commit 1c910f64baa91df478dd0b4b4495aa3895efbf06
parent 32064a9ffbc52790b1130e4d96c37c683569bcab
Author: TheJackiMonster <thejackimonster@gmail.com>
Date: Mon, 13 Jun 2022 21:22:23 +0200
-adjusting terms of messenger service documentation in handbook
Signed-off-by: TheJackiMonster <thejackimonster@gmail.com>
Diffstat:
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
@@ -9990,7 +9990,7 @@ Also MESSENGER provides multiple features with privacy in mind:
original sender (uses the MESSENGER provided verification)
@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
+@item MESSENGER allows your node to decide between acting as relay 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)
diff --git a/doc/handbook/chapters/user.texi b/doc/handbook/chapters/user.texi
@@ -2365,16 +2365,16 @@ that will terminate at the respective peer's service.
@section Using the GNUnet Messenger
The GNUnet Messenger subsystem allows decentralized message-based
-communication inside of so called rooms. Each room can be hosted by
+communication inside of so called rooms. Each room can be relayed by
a variable amount of peers. Every member of a room has the possibility
-to host the room on its own peer. A peer allows any amount of members
+to relay the room on its own peer. A peer allows any amount of members
to join a room. The amount of members in a room is not restricted.
-Messages in a room will be distributed between all peers hosting the
+Messages in a room will be distributed between all peers relaying the
room or being internally (in context of the messenger service) connected
-to a hosting peer. All received or sent messages will be stored on any
-peer locally which is hosting the respective room or is internally
-connected to such a hosting peer.
+to a relaying peer. All received or sent messages will be stored on any
+peer locally which is relaying the respective room or is internally
+connected to such a relaying peer.
The Messenger service is built on the CADET subsystem to make internal
connections between peers using a reliable and encrypted transmission.
@@ -2411,9 +2411,9 @@ library designed for messenger applications.
@node Entering a room
@subsection Entering a room
-You can enter any room by its ROOMKEY and any PEERIDENTITY of a hosting peer.
-Optionally you can provide any IDENTITY which can represent a local ego by
-its name.
+You can enter any room by its ROOMKEY and any PEERIDENTITY of a relaying
+peer. Optionally you can provide any IDENTITY which can represent a local
+ego by its name.
@example
$ gnunet-messenger [-e IDENTITY] -d PEERIDENTITY -r ROOMKEY
@@ -2441,14 +2441,14 @@ be distributed as your name for the service in any case.
@subsection Opening a room
You can open any room in a similar way to entering it. You just have to leave
-out the '-d' parameter and the PEERIDENTITY of the hosting peer.
+out the '-d' parameter and the PEERIDENTITY of the relaying peer.
@example
$ gnunet-messenger [-e IDENTITY] -r ROOMKEY
@end example
Providing ROOMKEY and IDENTITY is identical to entering a room. Opening a room
-will also make your peer to a host of this room. So others can enter the room
+will also make your peer to a relay of this room. So others can enter the room
through your peer if they have the required ROOMKEY and your peer ID.
If you want to use the zeroed hash as shared secret key for the room you can
