number571 / go-peer

🔐 Library for developing secure, decentralized, anonymous and quantum-resistant networks in Go language
MIT License
265 stars 16 forks source link

Split HLS application -> HLK (kernel) and HLD (distributor) #15

Closed number571 closed 2 months ago

number571 commented 2 months ago

English

The HLS application currently performs two main functions - anonymizing traffic on the network and routing between local services. Technically, these functions should be located in different services - HLK and HLD, which will allow you to create and edit applications more flexibly. For example, it will be possible to create client-secure applications on HLS (distributor), but without anonymizing traffic. This is similar to the secpay_chat application, but at the same time it allows you to use applications of the anonymous Hidden Lake network such as HLM, HLF, HLR without changing the latter.


Russian

Приложение HLS в настоящее время выполняет две основные функции - анонимизации трафика в сети и маршрутизации между локальными сервисами. Технически эти функции должны находиться в разных сервисах - HLK и HLD, что позволит более гибко создавать и редактировать приложения. Так например, на HLD (раздатчик) можно будет создавать клиент-безопасные приложения, но без анонимизации трафика. Это схоже с приложением secpy_chat, но при этом позволяет использовать прикладные приложения анонимной сети Hidden Lake по типу HLM, HLF, HLR без изменения последних.

number571 commented 2 months ago

English

The concept was canceled because during the analysis it was revealed that:

  1. Application services are linked to HLS in different ways. Some (HLM, HALF) are linked to additional HLS functions (sending messages, creating a download stream), some are not linked at all (HLR). In other words, when dividing HLS into HLK and HLD, some application services will be linked to both services, which reduces the relevance of the idea of service independence to HLK,
  2. HLK, being the core, begins to depend on other services, which looks contradictory. In such a concept, the HLK service will need to constantly redirect received messages to any one service (HLD), whereas previously HLS could not contain any application services at all in its list and continue to function successfully.

    Russian

Концепия была отменена, т.к. в ходе анализа было выявлено, что:

  1. Прикладные сервисы в разной разисимости привязаны к HLS. Какие-то (HLM, HLF) привязаны к дополнительным функциям HLS (отправления сообщений, создания потока скачивания), какие-то непривязаны вовсе (HLR). Иными словами, при разделении HLS на HLK и HLD некоторые прикладные сервисы будут привязаны к обоим сервисам, что уменьшает релевантность идеи о независимости сервисов к HLK,
  2. HLK, будучи ядром, начинает зависеть от других сервисов, что выглядит противоречиво. В такой концепции сервису HLK потребуется постоянно перенаправлять полученные сообщения какому-либо одному сервису (HLD), в то время как раньше HLS мог не содержать вовсе прикладных сервисов в своём списке и продолжать успешно функционировать.