RKNnoVPN

Repository files (latest commit first)
Filename	Latest commit message	Latest commit date
loop-uh ed2feb45f5 2.3.3	2026-05-02 16:28:59 +03:00
..
busy.go	1.8.1	2026-04-27 17:49:54 +03:00
orchestrator.go	2.3.3	2026-05-02 16:28:59 +03:00
orchestrator_test.go	2.3.3	2026-05-02 16:28:59 +03:00
state_store.go	fix	2026-04-28 21:50:29 +03:00
state_store_test.go	Да, посмотрел похожие направления. Вывод: архитектура у нас не кривая по идее, но она всё ещё местами “после прототипа”. Главный риск не в config.json + profile.json, а в том, что у нас слишк ом много логики пока сходится в daemon main.go/handlers. Ориентиры: - SFA / sing-box-for-android: Android UI + сервисный слой + libbox/sing-box core. Хороший пример разделения UI/service/native core, но это VPNService-модель, не наш root TPROXY сценарий. Исто чник: SFA (https://github.com/SagerNet/sing-box-for-android ), sing-box (https://github.com/SagerNet/sing-box ). - NekoBoxForAndroid: силён в узлах, импортерах, подписках, форматах. У него README прямо говорит про sing-box и поддержку Shadowsocks/ClashMeta/v2rayN/sing-box outbound, при этом правила подп исок игнорируются и берутся именно nodes. Это близко к нашему subscription domain. Источник: NekoBoxForAndroid (https://github.com/MatsuriDayo/NekoBoxForAndroid ). - ClashMetaForAndroid: зрелый Android-проект с модулями app/common/core/design/service, external intents, release automation. Полезен как пример дисциплины Android/service boundary. Источник: ClashMetaForAndroid (https://github.com/MetaCubeX/ClashMetaForAndroid ). - v2rayNG: полезен идеей разделения UI и runtime-процесса; у него proxy/VPN services вынесены в отдельный процесс. У нас это ещё сильнее: runtime вообще в root daemon. Источник: v2rayNG (https://github.com/2dust/v2rayNG ). - Box for Root: самый близкий тип проекта: root transparent proxy через Magisk/KernelSU/APatch, module + optional manager app. Но это скорее ориентир по root substrate, не по typed daemon арх итектуре. Источник: box_for_magisk (https://github.com/taamarin/box_for_magisk ). Что у нас хорошо - Правильная базовая идея: APK -> typed IPC -> daemon -> module scripts -> sing-box/netstack. - Root-first архитектура имеет смысл. Большинство популярных клиентов VPNService-based, а у нас ценность именно в Magisk/root TPROXY. - Два файла config.json + profile.json нормальны, если config.json это runtime substrate, а profile.json это user intent. - Мы уже двигаем систему правильно: panel.json убран, daemon владеет profile.json, APK идёт через typed IPC. Что надо улучшить 1. Разгрузить daemon/cmd/privd/main.go Сейчас daemon слишком много знает сразу: IPC handlers, config apply, runtime, doctor, status, scripts. Я бы вынес: - internal/control или internal/api для IPC handlers; - internal/apply для transaction apply; - internal/doctor для doctor reports; - internal/subscription для fetch/parse/merge. 2. Сделать runtime transaction единственным путём применения Сейчас есть profile.apply, config-import, runtime start/restart/update/reset. Нужно, чтобы все mutating операции шли через один operation manager: validate -> persist draft -> render/check -> apply -> verify -> commit generation. 3. Формализовать IPC как контракт Не просто Go structs и Kotlin mirror руками, а файл контракта: - method name; - request schema; - result schema; - error codes; - operation metadata. Потом можно генерировать Kotlin/Go модели или хотя бы проверять drift тестами. 4. Разделить state files по смыслу Я бы оставил: - config.json: root/runtime substrate; - profile.json: user intent; - runtime_state.json: applied generation, last operation, last verified status; - install_state.json: updater/install progress. Тогда profile.json не превращается в мусорный ящик. 5. Подписки выделить в отдельный package Уже начали правильно. Дальше надо сделать: - SubscriptionSource; - SubscriptionNode; - ManualNode; - removed/stale policy; - provider identity; - preview/apply transaction. 6. APK сделать максимально “тонким” APK не должен “понимать shell/root”. Он должен: - показывать состояние; - отправлять intent; - отображать daemon errors; - не угадывать успех по stdout, raw json, exit code. Мой вывод Проект не надо переписывать с нуля. Архитектура рабочая, но её надо довести до взрослой формы: daemon как единственный runtime owner, APK как typed client, scripts как primitives. Самый выгодный следующий кодовый этап: вынести из main.go отдельный слой apply/operation transaction и зафиксировать IPC/schema contract. После этого subscription domain и updater станут намного проще, потому что появится один честный механизм: “сохранено, применено, не применено, rollback, нужно reset/reboot”.	2026-04-27 22:58:34 +03:00
status_model.go	fix	2026-04-28 21:50:29 +03:00
types.go	2.3.2	2026-05-02 15:19:56 +03:00

busy.go

1.8.1

2026-04-27 17:49:54 +03:00

orchestrator.go

2.3.3

2026-05-02 16:28:59 +03:00

orchestrator_test.go

2.3.3

2026-05-02 16:28:59 +03:00

state_store.go

fix

2026-04-28 21:50:29 +03:00

state_store_test.go

Да, посмотрел похожие направления. Вывод: архитектура у нас не кривая по идее, но она всё ещё местами “после прототипа”. Главный риск не в config.json + profile.json, а в том, что у нас слишк ом много логики пока сходится в daemon main.go/handlers. Ориентиры: - SFA / sing-box-for-android: Android UI + сервисный слой + libbox/sing-box core. Хороший пример разделения UI/service/native core, но это VPNService-модель, не наш root TPROXY сценарий. Исто чник: SFA (https://github.com/SagerNet/sing-box-for-android ), sing-box (https://github.com/SagerNet/sing-box ). - NekoBoxForAndroid: силён в узлах, импортерах, подписках, форматах. У него README прямо говорит про sing-box и поддержку Shadowsocks/ClashMeta/v2rayN/sing-box outbound, при этом правила подп исок игнорируются и берутся именно nodes. Это близко к нашему subscription domain. Источник: NekoBoxForAndroid (https://github.com/MatsuriDayo/NekoBoxForAndroid ). - ClashMetaForAndroid: зрелый Android-проект с модулями app/common/core/design/service, external intents, release automation. Полезен как пример дисциплины Android/service boundary. Источник: ClashMetaForAndroid (https://github.com/MetaCubeX/ClashMetaForAndroid ). - v2rayNG: полезен идеей разделения UI и runtime-процесса; у него proxy/VPN services вынесены в отдельный процесс. У нас это ещё сильнее: runtime вообще в root daemon. Источник: v2rayNG (https://github.com/2dust/v2rayNG ). - Box for Root: самый близкий тип проекта: root transparent proxy через Magisk/KernelSU/APatch, module + optional manager app. Но это скорее ориентир по root substrate, не по typed daemon арх итектуре. Источник: box_for_magisk (https://github.com/taamarin/box_for_magisk ). Что у нас хорошо - Правильная базовая идея: APK -> typed IPC -> daemon -> module scripts -> sing-box/netstack. - Root-first архитектура имеет смысл. Большинство популярных клиентов VPNService-based, а у нас ценность именно в Magisk/root TPROXY. - Два файла config.json + profile.json нормальны, если config.json это runtime substrate, а profile.json это user intent. - Мы уже двигаем систему правильно: panel.json убран, daemon владеет profile.json, APK идёт через typed IPC. Что надо улучшить 1. Разгрузить daemon/cmd/privd/main.go Сейчас daemon слишком много знает сразу: IPC handlers, config apply, runtime, doctor, status, scripts. Я бы вынес: - internal/control или internal/api для IPC handlers; - internal/apply для transaction apply; - internal/doctor для doctor reports; - internal/subscription для fetch/parse/merge. 2. Сделать runtime transaction единственным путём применения Сейчас есть profile.apply, config-import, runtime start/restart/update/reset. Нужно, чтобы все mutating операции шли через один operation manager: validate -> persist draft -> render/check -> apply -> verify -> commit generation. 3. Формализовать IPC как контракт Не просто Go structs и Kotlin mirror руками, а файл контракта: - method name; - request schema; - result schema; - error codes; - operation metadata. Потом можно генерировать Kotlin/Go модели или хотя бы проверять drift тестами. 4. Разделить state files по смыслу Я бы оставил: - config.json: root/runtime substrate; - profile.json: user intent; - runtime_state.json: applied generation, last operation, last verified status; - install_state.json: updater/install progress. Тогда profile.json не превращается в мусорный ящик. 5. Подписки выделить в отдельный package Уже начали правильно. Дальше надо сделать: - SubscriptionSource; - SubscriptionNode; - ManualNode; - removed/stale policy; - provider identity; - preview/apply transaction. 6. APK сделать максимально “тонким” APK не должен “понимать shell/root”. Он должен: - показывать состояние; - отправлять intent; - отображать daemon errors; - не угадывать успех по stdout, raw json, exit code. Мой вывод Проект не надо переписывать с нуля. Архитектура рабочая, но её надо довести до взрослой формы: daemon как единственный runtime owner, APK как typed client, scripts как primitives. Самый выгодный следующий кодовый этап: вынести из main.go отдельный слой apply/operation transaction и зафиксировать IPC/schema contract. После этого subscription domain и updater станут намного проще, потому что появится один честный механизм: “сохранено, применено, не применено, rollback, нужно reset/reboot”.

2026-04-27 22:58:34 +03:00

status_model.go

fix

2026-04-28 21:50:29 +03:00

types.go

2.3.2

2026-05-02 15:19:56 +03:00