@wyd011011daniel https://post.smzdm.com/p/aoown0g7/ 之前玩过类似这种项目 不过 WOL 直接用 HomeAssistant 就能解决

@richard1122 esp32 的项目很多 或者 8266 ha hk 或者涂鸦接入小米

试试问问 gpt4o ？ ”root /var/www/html; # 注意这里用 root 而非 alias “我刚刚搜的

euphoria ，a kite ，yellow star

@wyd011011daniel 不过我是不太报希望，因为这种听的东西，人对错误的容忍程度应该不是那么高的。譬如男女声音，不同情感。如果配错了，人会很敏感的察觉到，对主要受众来说会很出戏。 不像图片那么好糊弄人

https://learn.microsoft.com/zh-cn/azure/ai-services/speech-service/speech-synthesis-markup-voice#use-speaking-styles-and-roles

你说的就是用大语言模型生成 SSML 标记过后的文本内容

看你是要实时还是预先训练好
实时的话，可以做个阅读器让用户自己导入小说。
起步等待要久一点 然后上下文联系可能会出错。
预训练的话版权问题基本只能大公司做

我自己用阅读/爱阅记 azure tts 听书很久了，也挺听喜马拉雅的有声书。

喜马拉雅真人配的有声书（哈利波特系列/三体系列）除了情感以外 还会模仿角色音色，配音功夫下的很多，而且还有环境配乐和各种实时动作的配乐。

现在 ai 配环境声不知道做的怎么样。感觉可以朝着对标这种有声剧想想办法。

@icestraw 不是哥们，没人说“保护隐私的责任不在开发者。” 太无聊了，感觉自己浪费了好多时间

@icestraw

我认为你和我的逻辑是反过来的

你认为技术无论如何都做不到尽善尽美，所以用哪个技术手段完全不重要。
我认为更透明更开源的实现方式能给用户更多安全感和安全性。

这种观点的辩论无意义了。

@icestraw 我说了 审计方式是使用 app 的用户数量大了必然有愿意审计 app 的看得懂代码的用户 不依靠第三方用户审计。

即对这种软件的信任来自于用户量大了之后必然存在的 geek 用户，geek 用户可以通过自己审计代码自己检测流量的方式。

开发者宣传只使用 cloudkit 并且开源
geek 用户可以通过自己审计代码自己检测流量
没有问题爆出来即软件相对使用开发者自己的用户更安全

你对我的反驳完全来自己于期望用户能够完全掌握 app 的审计等工作以实现对软件安全性的完全掌握。

但这是事实上不可能，只要用户期望使用第三方联网的服务，独立个体用户也不可能审计所有代码并且对开发者的服务器也没有任何审计能力。

但是 cloukit 的信任链很容易建立不是么，只要软件宣传只是用 cloudkit ，任意用户发现异常并报告则软件生涯结束。
那么对大部分用户只要软件有大量用户并且没有异常报告就可以认为是可信任的。

类似的如果一个软件宣传只使用 webdav 上传数据到用户自己的服务器。这也是类似的逻辑链啊。

@icestraw

1 用户审计代码是指所有用户中有一部分愿意审计代码

2 还有“app 不会向除了苹果以外的服务器发送消息”这件可以另一个角度证明的方式

app 不可能知道什么时候在不在被监控对不对，那如果任何时候任意一个用户发现 app 在对除了苹果以外的服务器发送消息，那不就会暴露并且开发者身败名裂。

上述两个部分是同时互相交叉验证的。逻辑链我来给你缕缕

1 开发者宣传只使用 cloudkit 并且开源
2 部分用户审计代码发现代码逻辑里确实没有对除了苹果以外的服务器发送消息
3 部分用户使用流量监测发现确实没有对除了苹果以外的服务器发送消息
4 如果用户审计代码发现代码逻辑对除了苹果以外的服务器发送消息 则开发者需要解释或者身败名裂
5 如果用户使用流量监测发现对除了苹果以外的服务器发送消息 则开发者需要解释或者身败名裂

对比使用开发者自己的服务器的 app
1 用户无法确认自己的数据去的服务器是否安全 会不会泄露 (apple cloud 和 开发者自己服务器安全性的对比)
2 用户无法确认自己的数据会不会被开发者滥用（ cloudkit 上传的数据开发者看不了 服务器上的数据开发者看得了）

那么在 开发者宣传只使用 cloudkit 并且开源 是不是比使用开发者自己的服务器 的 app 有更好的安全性和可审核性？

@andyzhshg 可持续性有个有意思的点 在于开发者不能主动下架 app 然后开发者要持续支付年费。（当然不续费使用过的用户还是可以去下载的）

最好的可持续我想是便捷的导出为可理解的格式。譬如 qq 聊天记录是可以导出为 html 格式的。或者健康心率之类的导出为 json 格式。

这样如果 app 不幸终止服务，用户也可以相对轻松(python 脚本或者第三方工具)导出数据转换到别的平台

当然别的平台也需要有导入手段。

@wyd011011daniel

这种安全的体现方式是“ app 不会向除了苹果以外的服务器发送消息 ”这件事情第三方软件审计或者开源 app 都可证明。

但第三方服务器用户无从得知开发者的操作也无法审计。

区别在于提供了证明开发者没有获取数据的方式，用户当然不可能审计无时无刻审计，但有的用户可能会审计，有的用户可能看的懂代码。如果这里有一个人发现有问题并给出证明，那么开发者就身败名裂。

类似的开源软件内审查是否有问题的方式也类似，一方面代码公开 一方面谁都能运行代码并测试是否有异常流量。

我想说明的是 使用 cloudkit 并且通过开源，或者测试 App 是否链接 Apple 之外的外源服务来审计 相对于 开发者使用自己的服务器。是会带来更多的安全性和可审核性。

@icestraw [可以通过开源，或者测试 App 是否链接 Apple 之外的外源服务来审计] 他不是括号括起来了么。 那肯定表示在这个条件下解除用户对开发者的隐私疑虑。

你说“不能说“我用 CloudKit 所以我安全””

但他说的是可以通过开源，或者测试 App 是否链接 Apple 之外的外源服务来审计后解除用户对开发者的隐私疑虑，他并没有说“我用 CloudKit 所以我安全”。

确实感兴趣 求一个。d3lkMDExMDExQGdtYWlsLmNvbQ==

@SunnyIng 开关梯子都会导致 可能是 dns 残留几次无网络刷新后重新获取 dns 此处的 dns 也可能是代理状态等

如果使用空间音频就会发现 重启 app 之后第一个视频大概率 空间视频可以使用 右上角控制中心的页面显示正确。

但多次切换视频后 有概率视频不显示在右上角并且空间音频显示为灰色不可选中。

可以认为右上角的控制中心和空间音频（按钮）的出现代表 b 站播放的视频走了苹果的媒体渠道。但可能是长短视频/稍后再看列表切换或者其他原因。导致某一时刻开始媒体不再走苹果媒体渠道/或者苹果不再能够识别。

这时候通过重启 app 或者手机版本的听视频或者切入后台小窗（ ios 自带的）会使苹果能够识别这个媒体。

这个问题大概率是 b 站自己某些地方没做好/苹果对太频繁的媒体切换会出问题。

理由是 infuse 一次都没有出现过问题。但爱阅记 tts 播放的大概率第一句不会走空间音频 第二句一定会走。

@wyd011011daniel （带宽不需要太多的话

你可以找网络规划的人员帮你弄频率管理

宽带不需要太多的话 一个宽带就可以了。接几个路由器划分频率

提醒事项和日历肯定够了吧