messenger.rst (5560B)
1 .. _Using-the-GNUnet-Messenger: 2 3 Messenger 4 --------- 5 6 The GNUnet Messenger subsystem allows decentralized message-based 7 communication inside of so called rooms. Each room can be hosted by a 8 variable amount of peers. Every member of a room has the possibility to 9 host the room on its own peer. A peer allows any amount of members to 10 join a room. The amount of members in a room is not restricted. 11 12 Messages in a room will be distributed between all peers hosting the 13 room or being internally (in context of the messenger service) connected 14 to a hosting peer. All received or sent messages will be stored on any 15 peer locally which is hosting the respective room or is internally 16 connected to such a hosting peer. 17 18 The Messenger service is built on the CADET subsystem to make internal 19 connections between peers using a reliable and encrypted transmission. 20 Additionally the service uses a discrete padding to few different sizes. 21 So kinds of messages and potential content can't be identified by the 22 size of traffic from any attacker being unable to break the encryption 23 of the transmission layer. 24 25 Another feature is additional end-to-end encryption for selected 26 messages which uses the public key of another member (the receiver) to 27 encrypt the message. Therefore it is ensured that only the selected 28 member can read its content. This will also use additional padding. 29 30 .. _Current-state: 31 32 Current state 33 ~~~~~~~~~~~~~ 34 35 Currently there is only a simplistic CLI application available to use 36 the messenger service. You can use this application with the 37 ``gnunet-messenger`` command. 38 39 This application was designed for testing purposes and it does not 40 provide full functionality in the current state. It is planned to 41 replace this CLI application in later stages with a fully featured one 42 using a client-side library designed for messenger applications. 43 44 .. _Entering-a-room: 45 46 Entering a room 47 ~~~~~~~~~~~~~~~ 48 49 You can enter any room by its ROOMKEY and any PEERIDENTITY of a hosting 50 peer. Optionally you can provide any IDENTITY which can represent a 51 local ego by its name. This will automatically select that ego's private 52 key to sign your messages with. 53 54 :: 55 56 $ gnunet-messenger [-e IDENTITY] -d PEERIDENTITY -r ROOMKEY 57 58 A PEERIDENTITY gets entered in encoded form. You can get your own peer 59 ID by using the ``gnunet-core`` command: 60 61 :: 62 63 $ gnunet-core -i 64 65 A ROOMKEY gets entered in readable text form. The service will then hash 66 the entered ROOMKEY and use the result as shared secret for transmission 67 through the CADET submodule. You can also optionally leave out the '-r' 68 parameter and the ROOMKEY to use the zeroed hash instead. 69 70 If no IDENTITY is provided you will not send any name to others, you 71 will be referred as \"anonymous\" instead and use the anonymous ego (a 72 shared key pair known to all peers). If you provide any IDENTITY a 73 matching ego will be used to sign your messages. If there is no matching 74 ego you will use the anonymous ego instead. The provided IDENTITY will 75 be distributed as your name for the service in any case. 76 77 .. _Opening-a-room: 78 79 Opening a room 80 ~~~~~~~~~~~~~~ 81 82 You can open any room in a similar way to entering it. You just have to 83 leave out the '-d' parameter and the PEERIDENTITY of the hosting peer. 84 85 :: 86 87 $ gnunet-messenger [-e IDENTITY] -r ROOMKEY 88 89 Providing ROOMKEY and IDENTITY is identical to entering a room. Opening 90 a room will also make your peer to a host of this room. So others can 91 enter the room through your peer if they have the required ROOMKEY and 92 your peer ID. 93 94 If you want to use the zeroed hash as shared secret key for the room you 95 can also leave it out as well: 96 97 :: 98 99 $ gnunet-messenger 100 101 .. _Messaging-in-a-room: 102 103 Messaging in a room 104 ~~~~~~~~~~~~~~~~~~~ 105 106 Once joined a room by entering it or opening it you can write text-based 107 messages which will be distributed between all internally conntected 108 peers. All sent messages will be displayed in the same way as received 109 messages. 110 111 This relates to the internal handling of sent and received messages 112 being mostly identical on application layer. Every handled message will 113 be represented visually depending on its kind, content and sender. A 114 sender can usually be identified by the encoded member ID or their name. 115 116 .. code-block:: text 117 118 [17X37K] * 'anonymous' says: "hey" 119 120 .. _Private-messaging: 121 122 Private messaging 123 ~~~~~~~~~~~~~~~~~ 124 125 As referred in the introduction the service allows sending private 126 messages with additional end-to-end encryption. These messages will be 127 visually represented by messages of the kind 'PRIVATE' in case they 128 can't be decrypted with your used private key. Members who can't decrypt 129 the message can potentially only identify its sender but they can't 130 identify its receiver. This prevents other members from collecting more 131 metadata than necessary about you. 132 133 .. code-block:: text 134 135 [17X37K] ~ message: PRIVATE 136 137 If they can be decrypted they will appear as their secret message 138 instead but marked visually. 139 140 .. code-block:: text 141 142 [17X37K] ** 'anonymous' says: "hey" 143 144 Currently you can only activate sending such encrypted text messages 145 instead of usual text messages by adding the '-p' parameter: 146 147 .. code-block:: shell 148 149 $ gnunet-messenger [-e IDENTITY] -d PEERIDENTITY -r ROOMKEY -p 150 151 Notice that you can only send such encrypted messages to members who use 152 a private key which is not publicly known via the anonymous ego to ensure 153 transparency. If any user could decrypt these messages they would not be 154 private. So as receiver of such messages the IDENTITY is required and it 155 has to match a local ego.