Naive plugin的发布形式

[klzgrad]

https://matsuridayo.github.io/m-plugin/

SagerNet 发布的插件 io.nekohasekai.sagernet.plugin.* 目前以下协议可以使用 SagerNet 版插件，请以应用内为准。

SagerNet现在维护比较缓慢，naive plugin的更新实为各种用户提交PR改版本号。如果要NekoBox支持更新比较及时的naive plugin，指导用户直接从klzgrad/naiveproxy下载这个apk是否合适？还是对第三方打包以及往play store或者f droid发布有特点的安排？

[arm64v8a]

1. 如果要发布 MatsuriDayo 版本的 Naive 插件，这边希望直接用上游的编译产物，更新就是直接改版本号。
2. 插件不打算上传到 Play Store
3. 插件可以发布到 F-Droid ，这部分我要问问 @linsui

[linsui]

F-Droid 肯定是要自己编译的。只发布插件没问题。

[arm64v8a]

F-Droid 肯定是要自己编译的。只发布插件没问题。

https://github.com/MatsuriDayo/plugins/blob/dev/download.sh

目前这种下载的不行吗？如果要编译会比较麻烦。

[linsui]

SagerNet 的 naive proxy 插件是编译的。F-Droid 要求从源码构建。

[klzgrad]

如果要发布 MatsuriDayo 版本的 Naive 插件，这边希望直接用上游的编译产物，更新就是直接改版本号。

1. klzgrad/naiveproxy发布naive-plugin.apk，这样的好处是版本发布是同步的，没有额外的发布工作，缺点是没有App分发渠道
2. klzgrad/naiveproxy发布libnaive.so，MatsuriDayo/NekoBoxForAndroid将其打包发布naive-plugin.apk或者自行编译出libnaive.so然后打包成naive-plugin.apk，这样会多一个打包发版环节产生滞后，打包环节里面的App分发渠道策略比较容易调整
3. 在SagerNet/SagerNet发布naive-plugin.apk，维持现状，更新也是改版本号，但是版本滞后最多，无法确保版本有更新

怎么选？我的目的是让naive-plugin的更新快一点。

[linsui]

klzgrad/naiveproxy发布naive-plugin.apk，这样的好处是版本发布是同步的，没有额外的发布工作，缺点是没有App分发渠道

这个 apk 是 NekoBoxForAndroid 和 SagerNet 通用的吗？F-Droid 直接打包这个怎么样？

[arm64v8a]

怎么选？我的目的是让naive-plugin的更新快一点。

如果不维持现状，我建议是 1，把 MatsuriDayo/plugins 的部分源码和 Github Actions 文件合并进 naiveproxy 项目（或者单独开一个项目方便 fdroid 打包）。

这个 apk 是 NekoBoxForAndroid 和 SagerNet 通用的吗？F-Droid 直接打包这个怎么样？

情况比较复杂。

1. 如果你手机上存在两个 id 相同(naive-plugin) 且 authority 相同(io.nekohasekai.sagernet) 的插件，这套插件系统会报错。

https://github.com/SagerNet/SagerNet/blob/f8a89a4f4470782751b5e51bed066c21bb2662c0/app/src/main/java/io/nekohasekai/sagernet/plugin/PluginManager.kt#L91-L138

2. 为了避免这种情况，Matsuri 插件把 authority 改了，SagerNet 不会识别到 Matsuri 插件。（实际上这边的 Hysteria TUIC 等插件还用到了 protect_path 绕过端口转发提升性能，这与 SagerNet 是不兼容的）

https://github.com/MatsuriDayo/plugins/blob/dev/app_hysteria/src/main/AndroidManifest.xml

鉴于目前的 io.nekohasekai.sagernet.plugin.naive 已经由 nekohasekai 签名发布，加上 SagerNet 原作者弃坑长期无人维护，实际停更的状态。如果不想维持现状，只能舍弃 SagerNet 支持，发布 moe.matsuri.exe.naive 这个插件。

如果维持现状，那么更新速度取决于 @enfein 合 PR / 改版本号的速度。

[klzgrad]

或者单独开一个项目方便 fdroid 打包

我不清楚fdroid发布是否一般认为有价值，我提Fdroid是因为sagernet原来做了这个工作，我的印象是fdroid的构建系统繁琐和陈旧，要支持可能比较费劲，但是对价值大小我没有感知，所以提问。

把 MatsuriDayo/plugins 的部分源码和 Github Actions 文件合并进 naiveproxy 项目

我不太熟悉apk打包的流程和惯例，这相当于naiveproxy项目里面签发了moe.matsuri.exe域下的apk，不知道从渠道控制权的层面来看，是否妥当？

加上 SagerNet 原作者弃坑长期无人维护，实际停更的状态

SagerNet主页也是宣称不会停止维护，所以是不是还要沟通一下，免得产生不善意竞争的感觉。我的理解是，Matsuri原来是SagerNet的fork，只是观点不同。但是SagerNet停更转去开发sing box，而NekoBox也是使用sing box作为“内核”，所以NekoBox在技术路线上理应属于SagerNet的下一代/继承者？

如果不想维持现状，只能舍弃 SagerNet 支持，发布 moe.matsuri.exe.naive 这个插件

这个意思是说，NekoBox这里的naive plugin无法一个apk两用，插件也要fork出来，把名字区分一下，不再使用SagerNet版本，更新会变快。但是SagerNet现有的插件构建系统也不受影响，依然可以继续发布SagerNet自用版本。

[arm64v8a]

Google play 之前不允许我上架 Hysteria Plugin ，所以估计 Naive 也不会过。

目前的 Play 的 naive plugin 2022年6月后未有更新。这个的控制权应该在 @nekohasekai 手上。

F-droid 要求比较多，比较复杂。但目前的 Naive Plugin 仍有更新。

我不太熟悉apk打包的流程和惯例，这相当于naiveproxy项目里面签发了moe.matsuri.exe域下的apk，不知道从渠道控制权的层面来看，是否妥当？

如果需要发布新插件，我倾向在 Matsuridayo 这边做一个专门的构建项目。

而NekoBox也是使用sing box作为“内核”，所以NekoBox在技术路线上理应属于SagerNet的下一代/继承者？

是的。

这个意思是说，NekoBox这里的naive plugin无法一个apk两用，插件也要fork出来，把名字区分一下，不再使用SagerNet版本，更新会变快。但是SagerNet现有的插件构建系统也不受影响，依然可以继续发布SagerNet自用版本。

是的。

SagerNet主页也是宣称不会停止维护，所以是不是还要沟通一下，免得产生不善意竞争的感觉。

为了避免这种感觉，我希望 naive 插件维持现状，只有出现不兼容或SN明确放弃，才发布新的插件。

回到本帖目的，就是希望 @nekohasekai @enfein 加快插件更新速度。

[linsui]

我不清楚fdroid发布是否一般认为有价值，我提Fdroid是因为sagernet原来做了这个工作，我的印象是fdroid的构建系统繁琐和陈旧，要支持可能比较费劲，但是对价值大小我没有感知，所以提问。

如果使用 SagerNet 的构建工具肯定没有问题，挺丝滑的。

[klzgrad]

我希望 naive 插件维持现状，只有出现不兼容或SN明确放弃，才发布新的插件。

如果需要发布新插件，我倾向在 Matsuridayo 这边做一个专门的构建项目。

这个应该是当前的结论了

[enfein]

一些意见：

1. Play store 和 F-driod 比 GitHub 更适合发布软件，缺点是比较麻烦。
2. 最近 SN 的 PR 大部分是更新 naive proxy 的，我虽然不定期上线，但是看到了会尽量处理。
3. @nekohasekai 请把 @klzgrad 加到 SagerNet org 里面。

[klzgrad]

注意到 https://github.com/SagerNet/SagerNet 已经被标记为 This repository has been archived by the owner on Jan 4, 2024. It is now read-only.

1. klzgrad/naiveproxy发布naive-plugin.apk，这样的好处是版本发布是同步的，没有额外的发布工作，缺点是没有App分发渠道

我建议是 1，把 MatsuriDayo/plugins 的部分源码和 Github Actions 文件合并进 naiveproxy 项目

我会尝试先把SagerNet的libnaive.so构建流程恢复出来，然后看看“MatsuriDayo/plugins 的部分源码”具体要做什么。

[klzgrad]

我已经把MatsuriDayo/plugins里面app_naive的部分合并到klzgrad/naiveproxy并完成构建

但是applicationId还维持了moe.matsuri.exe.naive https://github.com/klzgrad/naiveproxy/commit/5bdb3f745e9ff838722557f5953302a763bf9e7e#diff-1e9228482882929462a30eec994afced02a688339dfa3c186b113f32cf3bc564R35

有没有建议要把这个id改成其他的值，是否影响兼容性？

@arm64v8a @purofle