diff --git a/docs/todo/websockets.txt b/docs/todo/websockets.txt
new file mode 100644
index 00000000..b6934416
--- /dev/null
+++ b/docs/todo/websockets.txt
@@ -0,0 +1,51 @@
+TODO: websockets-transport
+ Предлагается следующее решение:
+
+ - Пир стартует и пингует/получает PEX по UDP - это, вроде бы, работает.
+
+ - Пир получает расширенную информацию о пирах --- например, путем запроса
+   ссылки или еще как-то (TBD), что бы не делать лишний протокол.
+
+ - В отдельном потоке пир поднимает сервер
+
+ - Сервер ведёт список список клиентов, ключом является публичный ключ
+   (либо же нонс - лучше нонс)
+
+ - Сервер ждёт соединений и трекает их в общем каком-то стейте
+
+ - Возможно, поднимает "пира" и использует те же самые команды,
+   правда в нашем случае только GetBlockChunks, используя в качестве
+   транспорта реаилзацию WS
+
+ - Через какое-то время после старта сервера, пир пытается поднимать
+   треды с ws - клиентами. Один клиент -- один пир. Проверяет, если
+   соединение уже установлено с сервером - то запрашивает трубу для того
+   соединения. "Труба" -- это реализация пира через какой-нибудь TChan
+   для уже имеющегося соединения.
+
+ - Если соединения нет, то пытается поднять соединение со стороны
+   клиента
+
+  Логика работы через WS существенно другая, полагаем, что пиры
+  изначально связываются по UDP/Ping/PEX.
+
+  Однако, в дальнейшем можно и бутстрап и всё прочее делать,
+  указывая префикс протокола ( ws://xxxx или udp:/xxxx ) в
+  URI пиров.
+
+  На каждого пира запускается свой поток скачивания, аналогично
+  UDP.  Потоки отгнивают, если теряется авторизация (?), все
+  такое же.
+
+  Таким образом, WS пир это или тред вокруг websocket-клиента,
+  либо же тред вокруг трубы, торчащей из вебсокет-сервера.
+
+  Является ли проблемой, если получится одновременно установить
+  и клиентское, и серверное соединение?
+
+  Надо бы понять. Возможно, ничего специально делать не надо,
+  будет две трубы - да и пусть себе.
+
+  TBD: udp-relay
+  TBD: ws-relay
+