Multicast area в NNCP

http://www.nncpgo.org/Multicast.html
http://www.nncpgo.org/Encrypted-area.html
http://www.nncpgo.org/Reliz-7_002e1_002e0.html
Реализовал крупную фичу в своём NNCP: полноценную multicast рассылку!
Ибо нравится мне идея эффективной рассылки файлов/писем без создания
каждому прекаждому копии пакета, как это в обычных почтовых рассылках
делалось бы. Нравится эффективность подхода в FidoNet эхопочты, фэх и,
видимо (никогда не пользовался), NNTP и Usenet новостей.

Мне нравится как я реализовал: обычный (file/exec) пакет помещается в
обычный зашифрованный пакет, но в котором получателем является multicast
area. Этот зашифрованный пакет оборачивается в обычный (plain) но с
типом "area" и идентификатором area в которую он посылается. А только
после этого он уже штатно помещается в обычный зашифрованный
отправляемый от ноды к ноде. Во время тоссинга, когда мы видим area
пакет, то плодим для каждого подписчика area по копии его содержимого.

Везде блюдутся .seen файлы. Обработка пакета выполняется в цикле каждый
раз с нуля, создавая по одному новому .seen файлу к созданному
исходящему пакету. Асимметричная криптография выполняется только один
раз, а дальше результат её работы (Диффи-Хельман) кэшируется. Имеем
последовательное чтение/запись, просто многократное, с расходами только
на симметричную криптографию.

И только после "обработки" всех подписантов, дешифруем пакет и
обрабатываем его содержимое. Причём, раз это Go, то функция обработки
пакета у меня на вход принимает io.Reader, поэтому абсолютно прозрачно
для неё данные берутся из на лету дешифруемого "внешнего" пакета и из
зашифрованного пакета который внутри area пакета.

Если приватного ключа от area нет, то значит будем только делать relay
multicast пакета, без попытки его самостоятельной обработки. Можно
включить разрешение на обработку пакетов (внутри area) с неизвестными
отправителями.

Идентификатор для .seen файлов зашифрованного сообщения -- хэш от
заголовка зашифрованного пакета внутри area, который при relay нигде не
затрагивается и не меняется. А раз он содержит эфемерный ключ, то и хэш
для каждого действительно нового сообщения будет разный.

Чтобы отправить начальное сообщение, нужно множеству подписантов создать
исходящие зашифрованные копии area пакета (внутри которого ещё один
зашифрованный для area). Если тут где-то что-то упадёт, то будет плохо:
ведь оригинал (зашифрованный пакет в area) у нас уже будет утерян и мы
не сможем оставшимся подписантам дослать его копии. Нужно значит где-то
временно сохранить. Проблему даже не пришлось решать, ибо уже написанный
(на тот момент) код отлично справился с тем, что пакет можно отправить
самому себе, и тоссер запускать на свою собственную "tx" директорию. И
тоссер уже надёжно и гарантированно, пофиг как и сколько его прерывали,
создаст копии для каждого подписанта, а так как во время отправки самому
себе, уже будет создан .seen файл, то тоссер после создания всех копий
просто удалит этот пакет из self/tx директории. Из коробки готовое
перманентное хранилище для multicast пакета, к тому же зашифрованное (в
открытом виде никто нигде не видит заголовков area пакета),
автоматически очищаемое.