## Multicast areas ¶

NNCP has ability to multicast packets: send single packet to multiple recipients, which also can send it further to others. It can also be called echomail (like in FidoNet networks) or newsgroup (like in Usenet networks).

Each multicast group is identified by so-called area. Area consists of private/public Curve25519 keypairs for packets encryption, identity (BLAKE2b-256 hash of the public key) and possible subscribers. Areas are created with `nncp-cfgnew` command.

You can make either file or exec transmissions to the areas. Those ordinary file/exec packets are double wrapped in:

- encrypted packet, securing the actual packet contents from participants not having area’s keypairs (but still being able to relay that encrypted packet to the others)
- area packet, containing area’s identity, telling that tossing node can should it to the subscribers further

Area’s message identity (`MsgHash`) is the hash of the encrypted packet header. Because the area packet, containing the encrypted packet, is relayed as-is without any modifications, that area message’s hash will be the same on each node it reaches.

Tosser’s algorithm of processing the area packet is following:

- check is it known area’s identity (`AREA`). Fail/skip if it is unknown
- hash encrypted packet’s header, getting the `MsgHash`
- for each area’s subscribers:
  - check if that message was already seen (sent or received from) before by the destination node: check existence of `SPOOL/NODE/area/AREA/MsgHash` file. Skip that node if it exists
  - if subscriber’s node is not the one we received the packet from, then create outgoing encrypted packet to it, with that area packet inside
  - create corresponding `MsgHash` file
  - "rewind" the outer encrypted file to the beginning and repeat the whole cycle again, while all of subscribers will "seen" that area’s message.

    Expensive signature verification and shared key computation procedures are skipped in the following cycles – only symmetric cryptography will be in use, having negligible CPU resource consumption.

- check if we have seen that area’s message before by looking at `SPOOL/SELF/area/AREA/MsgHash`. If so, remove the packet, because it is just a ordinary possible duplicate, finish its processing
- check if we have got corresponding area’s private key. If no key exists, then remove the packet, finish its processing – we just relay it further without being able to read it
- look if area’s encrypted packet’s sender is known to us. If neither it is known, nor we have `allow-unknown` configuration option set for that area, then fail
- otherwise start decryption procedure, possibly ignoring the sender’s signature verification if it is unknown
- fed the decrypted contents to the toss-procedure as an ordinary plain packet, receiving files or exec calls
- mark area’s message as the seen one, remove the packet, finish processing

Because outgoing packets creation for each subscriber can be time and (disk) resource consuming, we can suddenly fail. It would be bad if we will loose the possibility to retry the multicasting process again. So we have got to save somehow outgoing area’s message in permanent storage, while outgoing copies are created. That is why the initial (not relaying) message to the area is sent to the self and processed by the tosser to create necessary outgoing message copies. Because message to myself is also encrypted, area’s message is encrypted and secured and noone sees plaintext `MsgHash`, knowing that you either originated or have that message on the disk.

For example we have got 4 nodes participating in the single area and let’s send file to that area from the `nodeA`:

    nodeA -> subs: ["nodeB", "nodeD"]
    nodeB -> subs: ["nodeC", "nodeD", "nodeA"], no keys
    nodeC -> subs: ["nodeB"]
    nodeD -> subs: ["nodeA", "nodeB"]

    A -- B -- C
    \   /
     \ /
      D

    $ nncp-file nodelist-20210704.rec.zst area:nodelist-updates:
    $ nncp-toss -node self

1. `nncp-file` creates an encrypted packet with area packet and encrypted packet inside it, with our own `self` node as a recipient (in the `SPOOL/SELF/tx` directory). It also creates the `SPOOL/SELF/area/AREA/MsgHash` file.
2. `nncp-toss` sees `tx/` file and "opens" it, applying the area message tossing procedure as described above. That will create outgoing packets in `SPOOL/nodeB/tx` and `SPOOL/nodeD/tx` directories with `SPOOL/nodeB/area/AREA/MsgHash` `SPOOL/nodeD/area/AREA/MsgHash` files. Because we already have `SPOOL/SELF/area/AREA/MsgHash`, that packet is removed then.
3. When `nodeB` receives the encrypted packet, it sees the area one inside. It copies/relays it to the `nodeC` and `nodeD`. It can not read area’s message because it lacks the keys.
4. `nodeC` does not relay it to anyone. Just stores `nodelist-20210704.rec.zst` in the incoming directory.
5. `nodeD` receives packets from both `nodeA` and `nodeB`. Only one of them processed, and other is ignored because corresponding `MsgHash` file will exist.

   If `nodeD` will receive packet from the `nodeB` first, it will relay it to the `nodeA` also, that will silently remove it when tossing, because it was already seen.

6. When `nodeC` sends message to the area, then `nodeA` will receive it twice from `nodeB` and `nodeD`, ignoring one of them during tossing.