@wmhack 谢谢你的意见。

发送给多个人建议最好还是发送的人去处理，不然有的消息加密、有的不加密用的人容易混乱。

导入旧账号的流程回头我会再考虑一下看看怎么可以再简单一些。

添加频道的按钮纯粹是因为我看 iOS14 的 sdk 里面有这个新的 API 感觉好厉害，以前要写一堆代码的现在几行就 OK 了。正如常言道手中有锤子，看什么都像钉子。哈哈！这个我回头再看看那里放这个按钮会合适一点。

@xingheng 手动感谢，哈哈！

@wmhack 首先谢谢支持啊！批量删除和小红点后面会加，不过优先级不会很高，要往后排一下啦！目前频道是和用户账号绑定的，没办法分享给别人的。因为每个人都有单独的密钥加密，你不把账号给别人的话别人收到消息也没办法解密的。所以按照目前的架构，如果要发给多个人其实相当于发送多次，每次用不同的 token 来发送。

@lockheart .chanify.yml 这个文件 docker 的话默认位置在 /root/.chanify.yml ，也可以通过参数--config=<配置文件路径>来自定义。会卡死不太清楚是什么原因，我这边没遇到过，是配置了 mysql 数据库但是没连上吗？其他原因好像一时也想不到。

@superlks0 哈哈！谢谢鼓励啊！没有意外的话，我至少会把 Apple watch 和 Mac OSX 支持做完，后面的功能就随缘了。

@suisr9255 自动复制 功能等过几天 1.0.8 发布就会有了，不过不会像 Bark 那么方便，因为 Bark 自动复制是做在 Notification Service Extension 里面的，我个人观点是但是在没有用户交互的情况下直接操作剪贴板好像不太符合苹果的风格，苹果的短信验证码的自动填充也是要用户点一次的。所以，我目前是做在下拉或长按消息后自动复制，也就是用户至少要有一次交互才会触发。

@suisr9255

1. Mac 端等手机端功能再完善一下后会开始开发的，目前手机端还有一些 UI 要优化一下。
2. 自动复制 功能我会考虑一下怎么加比较好的。

谢谢提的意见。

@cjqXe2v chrome 插件简单写了一个，可以试一下，支持发送选中文本，链接，图片。

https://github.com/chanify/chanify-chrome-extensions

不过还没来得及上 Chrome 的 WebStore，只有先通过源代码使用来了。

@From313 网上搜 App Store Screenshots Templates 之类的模版，然后再自己改的。

@tbg @txoooy 1.0.3 苹果过审了，昨天那个闪退问题应该修复了。再次谢谢。

@cjqXe2v 你说的是 Bark-Chrome-Extension 这个吗？我昨天晚上看了一下应该没办法直接工作，对于 url 里面消息的部分用的编码方式不一样，受到我在服务器端用的 web 框架的限制没有想到好的方案来兼容。

@919615766 抱歉啊！昨天晚上试着把版本依赖调到 ios13，然后编译爆出一堆警告和错误，瞬间头皮发麻，只能改回去。感觉没信心往下改依赖了。

@txoooy 没关系，能用就好。闪退是我的失误，已经紧急修复后提交给苹果审核了。服务器我写了单元测试覆盖代码，APP 偷懒没写，哈哈！看来有时候偷懒就要遭报应啊！

@txoooy 感觉你的这个状态手机上的数据库似乎已经不太对了，之前是不是有闪退过？建议删掉 APP 重新装一下。再先用内置的 api.chanify.net 试一下看看。

闪退的问题我已经改了，1.0.3 在等苹果审核。多条未读消息不论是不是点消息本体应该都会保存的。

@txoooy 只提示 “收到一条新信息” 是因为加密数据没有解开时会显示这个提示，这个状态下声音和 title 都不会工作。

原因可能有 2 个：
1. 是不是手机重启后没有解锁过就直接推送消息了？重启后没有解锁的时候密钥是在保护状态，没办法用来解密。
2. 是不是自建服务器的数据库重置过了，可以删掉服务器后重新加一下看看，如果内置 api 也不行的话应该不是这个原因。

看一下点击进入 APP 后消息是不是在。如果还是不行可以描述一下具体的操作流程，我看一下我这边是不是可以复现。

@Citrus 文档里有，可能写的不是很明显。在首页通过长按右上角扫描二维码的图标可以弹出菜单，菜单里有创建 Channel 。

@Citrus 苹果的 DeviceToken 有 256 位长，要是能穷举到也是厉害了。至于被 Ban 我也无可奈何，只有下架 APP 了。本来就是抱着开源的精神和大家分享的。真有人作恶也没办法，只能希望世上好人多吧！

如果想用又实在担心的话自己 99 美金注册一个苹果开发者账号，申请一个证书自己用，这个服务器代码是支持测试环境下面的 sandbox 模式的，所以不用上架自己默默一个人用也行。

@Citrus APNS 的 Key 直接公开的话会有如下几个可能的隐患：
1. 别人拿到你的设备 Token 后可以连续给你发推送，轰炸你。
所以在添加节点的时候请注意是自己的信的过的节点，不然别打开让节点存储设备信息的选项。

2. 如果遇到中间人攻击可以截获你的服务器和苹果之间的通讯。
我的解决方案是消息主体用 AESGCM 加密后再传递给苹果，这样即使是苹果的 APNS 服务器也无法解密，只有在手机上才能解开消息。缺点是每个节点服务器在每个设备上都要手工添加一次，服务器列表没有共享存储。

3. 用公开的 key 攻击默认服务器
我在默认服务上使用的 key 和自建服务器里面的 key 用的不是同一组，所以这个攻击没用。

我看 bark 也是公开了 key，目前还没想到更好的解决方案。如果有好的想法欢迎分享一下。

@internelp 没有意外的话苹果账号到期了我会坚持续，万一我不能续的话。客户端和服务器代码都在，你可以自己编译一下 APP，只要替换上面的证书就 OK 了，别的代码都不用改。

@internelp 自建服务器用的证书写死在代码里面了 github.com/chanify/chanify/blob/5a15385bb8b98a8ba272f343158ce46b8fae720f/logic/logic.go#L63

用的.p8 证书，正常情况下应该不会过期。

@bao3 webhook 可以用 GET 的方式发送，/v1/sender/<token>/<msg>

@tbg 官网自己手工写的 html，没用模版。谢谢反馈问题，是一个 Bug，等下次更新就会修复了。

@Acoffice Android 没找到好的方案，不知道从何下手，大家有什么好的点子吗？

@54xavier 要兼容各家的推送工作量太多了，感觉自己能力有限搞不定。

@kanbi 第三方肯定不太能信啦！不过开源的稍微能信一下吧！我自己也是在 Nas 上自建服务器用的。还有欢迎大家 review 代码，看看有没有安全方面的漏洞，毕竟我也不是这方面的专家，万一不小心坑了大家也不好。

@Mountaincnc 最开始是为了 apple watch 选的 iOS14，目前代码里面太多部分用了新的 API，短时间内应该没办法降低依赖了，十分抱歉啊！

@thet 暂时不支持 markdown，回头我会考虑看看，希望支持的话不会太复杂。