@zololiu 谢谢建议，1.3.6 服务器端支持了 lua 脚本作为插件，可以接收 json 数据后格式化后再推送消息。

@37012 你好，看日志是运行的参数或者配置文件不对，可以看一下是不是 --secret 这个参数没有设置。

@zololiu 你好，发送图片要自建服务器，在群晖 Docker 里面能部署的。

@suisr9255 1.3.0 版本支持原生 macOS 了。

禁止写入剪贴板我认为是苹果不喜欢没有用户参与的情况下 App 私自执行操作。就像禁止 App 长时间后台运行一样。通知消息如果用户自己长按查看、或者点击打开 App 再执行写入剪贴板并不禁止。但是通知消息用户没有操作也没有打开 App，App 自己私自直接写入剪贴板的行为是被限制了的。

@i386 谢谢你的建议，后面有空会考虑如何添加的。

@i386 不客气，也有我没有描述清楚的原因，这个的确主要是个人用户供自己使用的，也没有群发的功能。

@i386 首先谢谢你的提问。

1. 官方服务器理论上可以向户推送消息，但是现在应该是不可以，因为我根本没写这块代码。一般情况也不会向用户推送消息，我现在能想到的唯一用途是，万一发现严重的安全漏洞，我可能会提送一条升级提醒给用户。但是也只能推送到未分类的 channel，希望这个永远用不到吧。如果实在有洁癖的可以自己修改一下 iOS 代码，把链接官方服务器部分去掉，再编译安装。

2. Chanify 不支持群发，所以这里 channel 可以理解为分类。API 设计的 Token 是包含 channel 和 用户 两个信息的，并不是单独的只包含 channel 。认为用户是目标，token 自带分类信息比较合适目前的情况。也是因为保护隐私的关系，所以服务器都没有保存 channel 的数据，所以就放在 Token 里面了。因此就像我之前说的，服务器是没办法知道具体的 channel 信息的。

还有问题欢迎随时交流。

@i386 你好，谢谢你提的问题。

1. 新注册用户时，向 api.chanify.net 发送到数据，只是自动注册到官方服务器。如果只使用自建服务器服务器，后续推送信息都不会经过 api.chanify.net 。官方最多只是知道有多少活跃用户，并无法知道更多其他用户推送的消息。

2. 新建频道信息不会发送到 api.chanify.net ，如果使用自建服务器的话官方服务器永远不会知道用户的频道，除非使用官方服务器向某个频道第一次发送消息时，官方服务器才会知道这个频道的消息。

PS: 自建服务器的时候注意使用有状态的模式，无状态的话因为缺少部分信息，所以会借助官方服务器。因此如果希望保障隐私建议使用有状态的模式自建服务器。

综上所述，这样的实现我认为已经保障了隐私，还有问题欢迎随时交流。

Chrome 扩展推送图片之前有做过，利用图片的 srcUrl 就可以了。srcUrl 有两种情况，一种是小图片 base64 编码的，解码后就可以得到图片；另一种是链接，插件可以用 fetch 下载后再推送出去，希望对楼主有帮助。

@buzailianxi 嗯嗯！恭喜啦！ Gotify 我之前也看过，应该挺不错的。

@buzailianxi 十分抱歉啊！ Android 目前没想到什么好的推送方案，目前主要抽空先把 iOS 的写的完善一点，感觉还是有不少缺陷和不足的。

@q409640976 这个问题没法回答你，我不是大牛，楼主的程序也没看，不知道程序里面有没有破绽。话说我上来是来摸鱼的，不是 code review 的。等真等大牛来回答你吧！:)

@q409640976 这个问题看你怎么看了：

1. 弱密码是一个有限集合，也就是一共就那么多。而穷举法是穷举作用域里面的所有可能。所以通过改良 Hash 算法可以扩大需要穷举的作用域，但是对弱密码的有限集合无效。
2. 用彩虹表不是说可以破解所有数据，而是说只能对有限集合下的密码有效。但是我用一个强密码安全是因为我用的是强密码，而不是因为系统安全。换句话说如果我是用一个足够强的密码，你哪怕用最简单的 Hash 算法也是一样的。并不能说明系统安全性。
3. 如果强行要认为弱密码破解是不符合楼主命题的话，那我之前的论述都是废话。哈哈！

所以我上面说了，如果楼主认为彩虹表攻击没有意义，我可以道歉。:)

@no1xsyzy 嗯嗯！你说很对，我只是为了说明服务器保存密码并不安全。另外我这样说是怕楼主反驳，因为做的好的话用户密码数据和实际业务数据是要分库存储的，这样用户密码数据被脱，业务数据还有一线希望。哈哈！

@xinyana 请不要火气那么大，希望大家还是理性讨论。

1. 我承认自己不牛，特别是密码学这块也就只知道一些皮毛。
2. 在我的理解里面，破解和解密还是有区别的，我并没有说有解密步骤。
3. 方法我已经在上面论述里面讲了，彩虹表攻击，你只要论述一下你是怎么能扛住彩虹表攻击的，我的说法自然不攻自破了。
4. 至于演示和说明实在没时间和义务，抱歉了。

最后，当然如果你认为彩虹表攻击对你的系统来说不需要考虑，没有意义。那我可以为我回复了你的帖子道歉。

1. 服务器保存加盐的密码主要目的是为了抗彩虹表攻击，就是万一被拖库了，给用户时间来修改密码保障安全。
2. 密码不能修改，这条直接把上面一条废了，也就是说服务器保存的密码没办法保证安全。
3. 无论是 DES 还是 AES 都是对称加密，对称加密的安全取决于密钥的安全，因为上面两条所以这条也废了。

是不是满嘴跑火车大家心里有数吧！

首先谢谢楼主分享，下面一点点个人小看法：

1. 服务器只保存了"加盐"的 SHA3 密码
2. 密码不能修改

就我的知识而言只需要上面这 2 条的组合，理论上保证了可破解吧！至于有没有价值、值不值得感觉就是另外的话题了。

@Junichi 抱歉，业余时间写的项目，实在精力有限，目前抽不出时间来做向下兼容了。

@lockheart 之前卡死的问题好了吗？ docker 镜像的话 dev 我已经支持了 linux/386，linux/amd64，linux/arm64，linux/arm/v7 。正式版本的话等 v1.0.9 就可以用了。