2 @unnumbered Multicast areas
4 NNCP has ability to multicast packets: send single packet to multiple
5 recipients, which also can send it further to others. It can also be
6 called echomail (like in FidoNet networks) or newsgroup (like in Usenet
10 Each multicast group is identified by so-called @strong{area}. Area
11 consists of private/public Curve25519 keypairs for @ref{Encrypted area,
12 packets encryption}, identity (BLAKE2b-256 hash of the public key) and
15 You can make either file or exec transmissions to the areas. Those
16 ordinary file/exec packets are double wrapped in:
19 @item encrypted packet, securing the actual packet contents from
20 participants not having area's keypairs (but still being able to relay
21 that encrypted packet to the others)
22 @item area packet, containing area's identity, telling that tossing node
23 can should it to the subscribers further
26 Area's message identity (@code{MsgHash}) is the hash of the encrypted
27 packet header. Because the area packet, containing the encrypted packet,
28 is relayed as-is without any modifications, that area message's hash
29 will be the same on each node it reaches.
31 @ref{nncp-toss, Tosser}'s algorithm of processing the area packet is
35 @item check is it known area's identity (@code{AREA}).
36 Fail/skip if it is unknown
37 @item hash encrypted packet's header, getting the @code{MsgHash}
38 @item for each area's subscribers:
40 @item check if that message was already seen (sent or received from)
41 before by the destination node: check existence of
42 @file{SPOOL/NODE/area/AREA/MsgHash.seen} file. Skip that node if
44 @item if subscriber's node is not the one we received the packet
45 from, then create outgoing encrypted packet to it, with that
47 @item create corresponding @file{MsgHash.seen} file
48 @item "rewind" the outer encrypted file to the beginning and repeat
49 the whole cycle again, while all of subscribers will "seen" that
52 Expensive signature verification and shared key computation
53 procedures are skipped in the following cycles -- only symmetric
54 cryptography will be in use, having negligible CPU resource
57 @item check if we have seen that area's message before by looking at
58 @file{SPOOL/SELF/area/AREA/MsgHash.seen}. If so, remove the packet,
59 because it is just a ordinary possible duplicate, finish its processing
60 @item check if we have got corresponding area's private key. If no key
61 exists, then remove the packet, finish its processing -- we just
62 relay it further without being able to read it
63 @item look if area's encrypted packet's sender is known to us. If
64 neither it is known, nor we have @code{allow-unknown} configuration
65 option set for that area, then fail
66 @item otherwise start decryption procedure, possibly ignoring the
67 sender's signature verification if it is unknown
68 @item fed the decrypted contents to the toss-procedure as an ordinary
69 plain packet, receiving files or exec calls
70 @item mark area's message as the seen one, remove the packet, finish
74 Because outgoing packets creation for each subscriber can be time and
75 (disk) resource consuming, we can suddenly fail. It would be bad if we
76 will loose the possibility to retry the multicasting process again. So
77 we have got to save somehow outgoing area's message in permanent
78 storage, while outgoing copies are created. That is why the initial (not
79 relaying) message to the area is sent to the @strong{self} and processed
80 by the @ref{nncp-toss, tosser} to create necessary outgoing message
81 copies. Because message to myself is also encrypted, area's message is
82 encrypted and secured and noone sees plaintext @code{MsgHash}, knowing
83 that you either originated or have that message on the disk.
85 For example we have got 4 nodes participating in the single area and
86 let's send file to that area from the @code{nodeA}:
89 nodeA -> subs: ["nodeB", "nodeD"]
90 nodeB -> subs: ["nodeC", "nodeD", "nodeA"], no keys
91 nodeC -> subs: ["nodeB"]
92 nodeD -> subs: ["nodeA", "nodeB"]
103 $ nncp-file nodelist-20210704.rec area:nodelist-updates:
104 $ nncp-toss -node self
109 @command{nncp-file} creates an encrypted packet with area packet and
110 encrypted packet inside it, with our own @code{self} node as a recipient
111 (in the @file{SPOOL/SELF/tx} directory). It also creates the
112 @file{SPOOL/SELF/area/AREA/MSGHASH.seen} file.
115 @command{nncp-toss} sees @file{tx/} file and "opens" it, applying the
116 area message tossing procedure as described above. That will create
117 outgoing packets in @file{SPOOL/nodeB/tx} and @file{SPOOL/nodeD/tx}
118 directories with @file{SPOOL/nodeB/area/AREA/MSGHASH.seen}
119 @file{SPOOL/nodeD/area/AREA/MSGHASH.seen} files. Because we already have
120 @file{SPOOL/SELF/area/AREA/MSGHASH.seen}, that packet is removed then.
123 When @code{nodeB} receives the encrypted packet, it sees the area one
124 inside. It copies/relays it to the @code{nodeC} and @code{nodeD}. It can
125 not read area's message because it lacks the keys.
128 @code{nodeC} does not relay it to anyone. Just stores
129 @file{nodelist-20210704.rec} in the incoming directory.
132 @code{nodeD} receives packets from both @code{nodeA} and @code{nodeB}.
133 Only one of them processed, and other is ignored because corresponding
134 @file{MSGHASH.seen} file will exist.
136 If @code{nodeD} will receive packet from the @code{nodeB} first, it will
137 relay it to the @code{nodeA} also, that will silently remove it when
138 tossing, because it was already seen.
140 @strong{TODO}: we must not relay packet to the node also presenting as
141 the sender of the area's message. Obviously it has seen it.
144 When @code{nodeC} sends message to the area, then @code{nodeA} will
145 receive it twice from @code{nodeB} and @code{nodeD}, ignoring one of