[Feature Request] 支持端到端加密

[hellodword]

非常感谢作者的 bark 应用，重度使用中。

我注意到在 Finb/Bark#86 有过类似讨论，不过他没有详细阐述，也并非一定要非对称加密。

端到端加密可以极大程度地解决传输过程中的信任问题，从原本的信任 [客户端，服务器，传输过程（https），苹果服务器，手机]，变成了信任 [客户端，苹果服务器，手机]。

---

• Apple - Decrypting data contained in a remote notification

[hellodword]

十分期望能参与贡献

[Finb]

我最近正在尝试加上加密
第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密
第二种对用户透明，服务端将数据加密后发送到app，app解密

目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密

第一种的缺点就是发送端可能会复杂一点，类似

#!/usr/bin/env bash

set -e

# bark key
deviceKey='your key'
# push payload
json='{"body": "test"}'

# must be 16 bytes long
key='1234567890123456'
iv='1234567890123456'

# openssl requires Hex encoding of manual keys and IVs, not ASCII encoding. 
key=$(printf $key | xxd -ps -c 200)
iv=$(printf $iv | xxd -ps -c 200)

ciphertext=$(echo -n $json | openssl enc -aes-128-cbc -K $key -iv $iv | base64)
echo $ciphertext
# curl --data-urlencode "ciphertext=$ciphertext" https://api.day.app/$deviceKey

[hellodword]

我最近正在尝试加上加密
第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密
第二种对用户透明，服务端将数据加密后发送到app，app解密

目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密

第一种的缺点就是发送端可能会复杂一点

太棒了🥳

第一种正是端到端加密。

发送复杂是可以理解的，但因为可以通过 ciphertext 之类的扩展字段以及其它方式保持兼容，所以对这个特性没有需求的用户是可以无感的。

不过不熟悉 iOS 开发，不清楚那边保持兼容的代价如何。

[Finb]

旧版本不兼容加密，打算加个提示使用加密之前升级app。
第一种方案只需app修改就行，改动的代码也不多

[Finb]

1.3.0 版本已经加上了推送加密