一点想法

[JasLin]

awesome! 之前一直有这个想法，但没有动手做。
有一个思路，协议头如果能够做到简单的类似加盐的算法就能改变特征的话（我还没有看源码），那么可以给ET做一个集群（或者一个vps，购买n个ip启动n个实例即可），然后本地的客户端做一个watcher，发现那个ip访问不来，立刻通知另外可用的ip，改变特征和端口，本地的client，动态从这个watcher里获取最新的端口连上去，可以无感切换。

在进一步，如果特征改变算法足够灵活，只要有足够的数据，可以利用这些数据，然后用对抗算法（GAN）不断自动升级特征混淆算法。

[JasLin]

这样只要两个ip，只要不同时端口被封，那么就可以理论上实现长期稳定的服务。 当然如果整个ip被封那也没办法：）

[eaglexiang]

好想法！
负载均衡或者故障转移一类特性的确在计划中。
不过生成协议头的功能我认为可以放在独立程序或脚本中。由它自动维护配置文件便可实现类似的效果。

[JasLin]

翘首以盼：）

[eaglexiang]

@JasLin 有可能会让你失望，目前ET的重心仍然会放在性能优化的方向。在实际使用一年多的过程里，安全性的需求确实是很低的。

[eaglexiang]

@JasLin 短时间内可能满足不了你的期望了，抱歉

[JasLin]

确实，没事，我先试着用用，如果出现这个需求的话，到时给你提pr：）

[JasLin]

@eaglexiang @remmina

给et-electron增加Mac os的支持

https://github.com/JasLin/et-electron/releases

这个版本支持测试了Mac 还没有测试win和linux，所以暂时还没发pr给 @remmina

[eaglexiang]

@eaglexiang @remmina

给et-electron增加Mac os的支持

https://github.com/JasLin/et-electron/releases

这个版本支持测试了Mac 还没有测试win和linux，所以暂时还没发pr给 @remmina

@JasLin 非常感谢！
@remmina 开心吗？

[remmina]

QvQ
感谢帮助！ @JasLin
其实昨天刚重装了家里的苹果一体机所以正有支持Mac之意，没想到竟然心想事成了。
有空的时候我也会研究一下的，虽然几乎没用过Mac，比如能否避免配置文件被覆盖的问题？
还有就是我想加上老早以前就想加的开机自启设置功能
（虽然可能我太菜了这些都实现不了）
大后天要学考了，正在复习中，23333
相信我，我一定不会咕的_(:з」∠)_

[eaglexiang]

@remmina 配置文件覆盖我这边可以解决

[JasLin]

@remmina 在我的mac分支已经支持，在第一次启动的时候把config和core/config的配置文件复制到了et-electron的运行的userData目录,然后程序使用这个目录作为配置目录，以后升级不会覆盖。

但是目前只支持mac，因为看原来@remmina的写的readme这一段，以为win和linux下已经实现了不覆盖的功能，所以只在mac下有这个行为。

如果需要，我把mac的限制去掉就好：）

[remmina]

@JasLin 嗯。。。之前不覆盖功能是很简单粗暴的实现方式：发布的压缩包里的config文件夹是空的，core/config文件夹内也是没有client.conf文件的，这样直接覆盖原本的配置文件是不会丢失的。程序在启动的时候会自动检测是否存在配置文件，如果不存在的话就会自动生成一个默认的配置文件。所以只要npm start一下config文件夹就不是空的了，因此每次测试程序我会保存一个config是空的副本。
您那个方法我觉得很不错_(:з」∠)_以后就用您那个方法吧
您有空的时候pr一下吧，谢谢咯！（话说我似乎从来没有处理过pr，还不知道流程是什么QAQ）

[JasLin]

好，我调一下然后发pr过来：）

[JasLin]

@remmina pr 发过去了 , 在mac和ubuntu18.04上测试通过，win还没测试过（家里没有win用 ^_^）

[remmina]

@JasLin 谢谢！
我打算看看还有没有什么可修改的，例如客户端运行的文件夹内其实没必要config文件夹之类的，直接到userData里生成应该就可以了（强迫症发作）
还有那个README里的macos的图似乎意义不大？如果确实是这样的话我就移除啦
也许还会做一个更好看的新图标XD

[JasLin]

@remmina 是的，macos的图不是很协调，移除了吧。 客户端的文件夹config现在已经没用了，可以去掉，按原来的逻辑config应该只是runtime的文件，直接生成在userData即可：）

[remmina]

@JasLin 现在出现了一个问题：有时候proxylist会更新，如果不覆盖那用户就无法接收到更新；如果覆盖了用户就没法自定义这个proxylist了，而且程序每次启动的时候都要去覆盖一次
您觉得这个问题有什么好的解决方法吗？

[eaglexiang]

@remmina 建议的做法是将自定义规则表放在自定义文件中。这样可以避免被更新覆盖。

所有文件夹内的规则文件都会被加载。

[remmina]

@eaglexiang et有这样的功能吗？还是说客户端每次合并两个文件为一，然后再以合并的文件作为proxylist？
我想了想觉得就不提供自定义功能吧，因为这个proxylist也应该足够用了
刚刚仔细阅读了一下et的文档，应该用config-dir参数就能实现配置文件与proxylist分开存放的功能吧？那样每次安装包里自带proxylist就行了，然后client.conf存userData里

[JasLin]

@remmina @eaglexiang 现在core/config里面所有规则已经被复制到userData目录，如果不考虑自定义，那么每次app启动的时候的时候，对比一下两个文件的内容，不同则覆盖就好。

但是我觉得我们先讨论一下是否需要在客户端支持自定义规则的问题，确定了这个，后面才讨论具体实现的方法。

目前如果不考虑从官方（新版本的安装包）获取新的规则的话，可以直接到userData修改增加自己的文件就好，比如我自己是在core/config/hosts里面增加了一个自己的host配置文件，解决内网dns问题。但是官方的不再覆盖就导致无法更新最新的proxylist网址。

如果proxylist保持和gfwlist.txt同步，这个proxylist非常有价值，值得更新，但是proxylist不够新的时候，可以自己添加进去。 这个好比我们用switchyomega的时候，既支持gfwlist.txt又支持自定义的rule。 用起来就比较爽了。

因此 我倾向于支持自定义，并且把自定义的rule和官方的proxylist的rule分开（需要et.go支持), 同时proxylist不要用现在的方式，而是改成一种可以动态获取的方式，如http服务或者直接socket拿回来。

那么这个拉取新的官方rule的动作，可以在et-electron里面定期或者手动触发去获取就好。 这样就不涉及到版本更新问题了。

[eaglexiang]

@remmina 目前是这样处理的。

所有规则文件都会被读取一次，域名列表最终被存放在同一个trie中。那么就顺带完成了合并与去重。

自带的规则文件与自定义文件，在本质和地位上都没有区别。

[JasLin]

@eaglexiang 如果已经有tire了，那么不用分自定义和官方独立文件也行：），分开存储则好处是将来可在客户端做自定义规则

[eaglexiang]

@remmina proxylist与directlist的目录也是通过config-dir推断出来的。所以更改config-dir也同样会影响两个规则文件目录。

如果确实需要专有的参数来指明规则目录，也可以加进去，倒不需要什么工作量

[remmina]

暂时先做了无法自定义的，毕竟et也支持在线查询智能分流，只不过第一次访问的时候会慢一点。
目前是用config-dir制定list到安装包自带的list里去，那个是会覆盖的
其他配置文件存放在userData目录里
马上发Releases啦，但我好像遇到了一个问题——mac的app文件夹无法压缩，压缩软件似乎会报错，表示“拒绝访问”（在windows10下打的包，打包的时候electron告诉我要用管理员权限才能打包），不知道要怎么压缩？ @JasLin

[remmina]

好吧原来是好压太弱了，用wsl里的zip命令就成功压缩了

[JasLin]

@remmina 嗯, 我暂时还是先用1.6.x，因为要增加hosts来解决内网的dns问题：）

[remmina]

@JasLin 新版客户端已经推出了，支持自定义功能啦。
但是我还是不知道为什么，打包出来的Mac包有140多MB，求指导QAQ

[remmina]

@JasLin 您在代码中写了这么一段：“Create window on mac by default, but hide it after created”
我对Mac不熟悉，为什么要在mac那里创建一个窗口然后隐藏掉呢？我不太清楚这是不是mac的特性
我暂时把那一段删掉了，代码会保存在history里，如果是需要的话我会放回来的QvQ

[JasLin]

@remmina

1. electron-packager在mac下面包太大的问题一直被吐槽从未被好好解，没有什么好的解决办法，特别是我们这个库还没有以来第三方npm modules，基本上没有什么缩小空间，可能把打包工具换成electron-builder会减少一些（以前试过electron-builder，感觉没这么大，具体忘了，但印象中也小不了太多）。 如果我们release给用户u下载的话，可以把这个et-electron.app压缩成zip包，可以减少到70m。

2. 关于这个window是否销毁的问题，这个是mac下面app使用的一个习惯，在mac下面所有窗口关闭并不是销毁，而是隐藏，再次点击dock下面app icon的时候，把隐藏的窗口show出来。 这个和windows的taskbar的用户体验不一样，mac没有taskbar的概念。另外一般来讲win下面关闭所有app的窗口意味着退出app，而mac下面，需要用cmd+q的命令来显式的退出app，这也是和win习惯上不同的一个地方。

另外，在mac下面默认开机启动et的时候，我不想每次都看到这个窗口，所以每次app启动的和时候，虽然窗口的窗口但是隐藏起来，如果点击需要的时候可以很快就show出来。而且我调试的时候试过如果只是创建tray，没有创建window，会出现有一些时候app启动不出了的情况

话说回来，因为现在有个tray的话，如果不想在dock里面看到et，可以在main.js import了app后，调用:

app.dock.hide()

这样就行了，那么这个行为就和shadowsocks-qt在mac下面的行为一样。 我没有写这个句，是因为我习惯了dock去调出窗口，而不太喜欢在tray里面去调出窗口。 这个纯属个人喜好：）

[JasLin]

关于mac下面包太大的问题，或者有时间，我们可以做一个macgap的版本,根据et-electron目前的代码结构和依赖，估计发布后5m以内的包