D

关联 Issue #8232 · siyuan-note/siyuan

感谢反馈，考虑如下：

• 有序列表复制粘贴序号没有重新编号，目前设计如此
• Ctrl x 剪切内容后无法 Ctrl m，没看明白，我这里测试剪切以后按 Ctrl+M 可以触发行级公式
• 通过搜索打开文档没有记住浏览位置，搜索打开时是定位到搜索位置
• 网络图片转化为本地图片问题，对于无法转换（比如网络异常）的情况下是提示不存在网络图片
• 前进后退大纲高亮未改变，Issue #8256 · siyuan-note/siyuan
• Ctrl f 后 Ctrl p 仍保持了 Ctrl f，目前设计如此 Issue #7988 · siyuan-note/siyuan
• ￥￥ 与公式块，公式可能可以考虑 ·<content>· 生成行内代码这个不行，很容易冲突
• 输入 ```+ 代码块名称 时能不能自动出现补全，暂时还不能确定
• 支持大纲拖动调整文件结构，Issue #7957 · siyuan-note/siyuan

焦点要在文档树上，你鼠标点击文档以后焦点就在编辑器里了。

这就不太清楚了，理论上不应该这么慢。

你的服务器下行带宽是多少？

已经帮你重置了，请重新登录看看。

目前没有办法可以获得，估计得加个接口 getChildBlockIDs(parentID)？

麻烦通过账号绑定的邮箱发邮件至 845765@qq.com

我这里暂时无法重现问题，只能等后面再看看了。

在浏览器使用的话是否是因为其他浏览器扩展影响了？

请试试在桌面端程序能否重现，谢谢。

1. 在应用私有路径下，外部无法访问到
2. 包含所有数据文件，具体就是 工作空间/data/ 文件夹下的所有文件

我刚刚测试没问题了。

@Epiphany2310 把它配置为 ../Untitled 试试，下个版本会做自动修正 Issue #8238 · siyuan-note/siyuan

@ciwoyipang 这个是新建文档保存位置，不是新建块引保存位置

楼主，已经定位到原因，是因为这个笔记本的 设置 - 新建文档存放位置 配置为 ../ 引起的，我想问一下这样配置的原因是？

楼主，我们已经收到你发的数据集，可以重现问题，原因等定位到再来补充。

@zxhd86 感谢老铁协助

我这里无法重现，如果方便的话麻烦导出 data（去掉 assets）后发送给我再试试 845765@qq.com

不用担心，本地优先、隐私优先是思源的基础，不会有所动摇的。

现在我们是在讨论要不要给思源支持内置密钥，前面大家已经提供了很多利弊方面的论述。

对于 Obsidian，它已经提供了云端托管密钥这个选择给用户，我之前通过它的文档进行过一些了解，但其中似乎并没有提到云端托管密钥安全相关的方案，在我们没有了解清楚之前，照搬这个设计可能会有隐患。

大家如果了解 Obsidian 对于云端托管密钥的细节，请向我介绍一下，谢谢。

对于用户来说肯定是越方便越好，但是软件不应该提供不够安全的“安全”机制，特别是对于云端而言，完全不受用户控制。

说得绝对一点，如果用户的需求是在任何设备上登录账号就能够同步和备份数据，那么选择思源是舍近求远。

从目前的讨论看来，我们可能得放弃内置密钥这个需求（不是放弃这部分用户），另一方面是改进自定义密钥的界面交互（比如在生成密钥后自动导出密钥文本文件让用户妥善保存），这样能尽量降低用户丢失密钥的可能性。

对，本地环境上面我们只能认为是受信任的安全环境，包括插件的安装或者其他软件的行为都认为是受控的。

是的，这部分已经在用户指南中的 数据安全 章节描述过。

这个投票的意义我前面简短写过一点，怎么能说没有意义呢……

不同需求的用户实际上已经通过产品选择过滤了，比如不需要本地数据的用户会选择云端产品，安全性和便利性本身是对立的，我们讨论的意义在于探寻是否存在一个折中方案进行兼顾。

对于“真正的问题”前面已经讨论过，即内置密钥（甚至是不加密）的需求是客观存在的，但是思源是不是一定要去实现这个需求？思源的受众定位如果不考虑这部分用户的需求是否合理？

我认为一个产品不可能满足所有人的需求的，放弃一部分需求是合理的。在内置密钥这个具体的需求上，放弃的代价可能就是无法获得更多“小白用户”的青睐，但真正的小白用户会选择本地优先的产品吗？这也是个需要不断思考和讨论的问题。

我们期望的不是毫无根据的信任，而是能够用技术证明的信任。开发者抛开代码实现谈信任是一种不负责任的做法，用户将希望寄托于开发者人品上也是不明智的，因为人品不能保证安全，但是代码能。

对于内置密钥就像前面 @zxhd86 提到的那样：“安全不绝对，等于绝对不安全”，一旦我们为思源提供了不足够安全的加密方案，云端数据实际上有很多泄漏的可能性，不只是开发者可以解密，云服务提供商也可以。所以前面 @zuoez02 提出了实现内置密钥后进一步的安全方案，但是这个方案非常难实现，或者说对于我们来说代价过高，已经偏离了现在的目标。

如果把提供内置密钥看作功能性需求的话，多提供一种选择给用户确实更好；但如果把它看作是非功能性需求的话，提供了内置密钥会导致产品整体安全性降低很多。

如果要做的话，内置密钥生成算法是不开源的，传输使用 HTTPS，存在泄漏风险。

开源软件是否更容易破解这个不好下结论，但是公开加密算法不不意味着就能破解这一点是肯定的。

本贴的意义在于集思广益，只是我个人考虑的话难免会存在思路上的局限，这会限制思源的长期发展。

提供多一种密钥生成方式无形中也增加了用户的使用负担。比如你建议的三种选项，用户需要考虑到底使用哪一种，在难以抉择的时候可能会随便选择某一种（也可能会趋向于高安全级别），一旦这个设备上选择了这种方式生成密钥，那么其他设备上也要选择相同的方式，对于普通用户而言这一步就很可能会选错……

所以增加内置密钥很有可能会给用户带来额外的操作成本，操作步骤中的分支意味着配置不当的概率会增加，从而背离提供内置密钥提供便利的初衷。

嗯，已经调整到正文第一行了。

正文结尾已经加入说明，投票的前提是两种机制都提供，不是取代关系。

是设置云端的时候提供给用户选择，比如我们提供两个选项：

• 内置密钥
• 自定义密钥

用户设备 1 上选择了内置密钥，设备 2 上选择了自定义密钥，这样也是不能成功解密的。无法做到设备 2 上面自动给用户选择内置密钥。

再增加配置项的话会更复杂，用户误操作的可能性更高。

我目前没有看到你投票是赞同还是反对，有点难以理解你的意思，能投票后再补充一下评论吗，谢谢。

我们无法区别“新老”的，最多只能区别是否在当前设备上初始化过密钥，如果初始化过并且和云端内置密钥不一致，那么就认为是自定义密钥了。