let the topology be pinned: trusted peer, outgoing switch, known nodes

A private Bitmessage contour cannot be assembled by letting the nodes find
each other. The sybil check in connectionpool refuses a candidate whose /16 is
already among the outbound connections, and every container of a compose
project shares one /16 -- so each node keeps a single outbound connection to a
randomly chosen peer, and the contour splits into components on some runs and
not on others.

Three variables make the topology explicit instead:

  BITMESSAGE_TRUSTED_PEER    trustedpeer = host:port
  BITMESSAGE_SEND_OUTGOING   sendoutgoingconnections = True/False
  BITMESSAGE_KNOWN_NODES     host:port,... -> knownnodes.dat

With them a star is one line of config per node: the hub takes
SEND_OUTGOING=False and only accepts, the spokes take TRUSTED_PEER=<hub>:8444.

Details worth knowing:

- trustedpeer is absent from the stock keys.dat, so a substitution alone would
  be a silent no-op. The key is added the same way maxtotalconnections is,
  and it is added even when the value is empty -- that is how a node that was
  pinned before can be unpinned. Its anchors stop at "=" rather than "= ",
  because an empty value leaves no trailing space to match.
- knownnodes.dat is rewritten on every start, not only when missing. "Only
  when missing" would never have fired: the image ships one, built by the
  `pybitmessage -t` run in the Dockerfile, and a named volume inherits it.
  Seeding it is also what stops the DNS bootstrap -- deserialising any peer
  that is neither a DEFAULT_NODE nor "self" raises knownNodesActual, and
  startBootstrappers only runs while that flag is down.
- Both peer variables are validated here. PyBitmessage does check trustedpeer,
  but with a sys.exit() from a constructor in the network thread, which reads
  as a container that died for no stated reason.

README.ru-RU.md

@@ -81,6 +81,9 @@ docker run -d \
 |-e BITMESSAGE_STOPRESENDINGAFTERXDAYS|Прекратить повторную отправку недоставленного сообщения через X дней. По умолчанию: `30`|
 |-e BITMESSAGE_APIVARIANT|Предоставляемый API: xml или json-RPC. По умолчанию: `legacy`|
 |-e BITMESSAGE_MAXTOTALCONNECTIONS|Предел одновременных соединений, входящих и исходящих вместе (`maxoutboundconnections` равен 8, то есть это значение минус 8 — запас на входящие). По умолчанию: `200`, штатное значение PyBitmessage — снижайте, если P2P-порт опубликован|
+|-e BITMESSAGE_TRUSTED_PEER|`host:port` единственного пира, к которому узел подключается наружу; больше ни к кому. По умолчанию: пусто — узел выбирает пиров сам. См. «Замечания»|
+|-e BITMESSAGE_SEND_OUTGOING|Подключается ли узел наружу вообще: `True` или `False`. По умолчанию: `True`. При `False` получается узел, который только принимает входящие, — центр приватного контура|
+|-e BITMESSAGE_KNOWN_NODES|Список `host:port` через запятую; записывается в `knownnodes.dat` при каждом старте вместо того, что там было. По умолчанию: пусто — файл не трогается. Заодно выключает бутстрап по DNS, см. «Замечания»|
 
 # Замечания
 
@@ -104,6 +107,23 @@ docker run -d \
   опубликованным 8444 сеть находит сама, как только он подключится наружу:
   ни IP, ни DNS-имя хоста задавать негде. Единственное исключение — скрытый
   сервис Tor, которому нужен явный `onionhostname`.
+- **Приватному контуру нужны назначенные пиры и звезда, в которую их назначать.**
+  PyBitmessage отвергает кандидата, чья сетевая группа (для IPv4 — /16) уже
+  представлена среди его исходящих соединений. Все контейнеры одного
+  compose-проекта живут в одной /16, поэтому каждый узел удерживает ровно одно
+  исходящее соединение — со случайно выбранным пиром, и контур чаще всего
+  распадается на компоненты. Задайте одному узлу
+  `BITMESSAGE_SEND_OUTGOING=False`, и он станет хабом, который только принимает
+  (проверка смотрит лишь на исходящие, входящие она не ограничивает), остальные
+  направьте на него через `BITMESSAGE_TRUSTED_PEER=<ip-хаба>:8444` — объекты
+  пойдут спица → хаб → спицы. Адреса задавайте IP, а не именами сервисов:
+  проверка разбирает хост как IP, да и обмен `addr` между узлами оперирует IP.
+- **`BITMESSAGE_KNOWN_NODES` — то, что делает приватный контур приватным.** Узел,
+  у которого в `knownnodes.dat` есть пир не из встроенного списка PyBitmessage,
+  перестаёт спрашивать адреса у `bootstrap8080.bitmessage.org`; без этого даже
+  узел с назначенным пиром при каждом старте резолвит публичный бутстрап-хост.
+  Файл переписывается на каждом старте, поэтому во что узел верит при загрузке,
+  определяет переменная, а не история контейнера.
 - **Публикация 8444 — осознанный компромисс по безопасности.** Демон работает на
   Python 2 и уже разбирает недоверенные данные от своих исходящих пиров, так что
   открытый порт эту поверхность не создаёт — он меняет то, *кто* может