@haierspi #10 我可能不是太懂这些 但我目前的状态是 服务器相比网盘来说稳定性不高可能随时丢了或者跑路，而且储存的太小没有网盘放心，但是同样来说同步的速度很快 有没有：服务器只是用来对比数据然后进行更改（小数据同步/但是是不是不现实？因为我不清楚是不是每次都要对比所有的数据），网盘作为长期存储可以开启要不要自动同步（需要同步的数据量很大）
@MK #13 每个插件都有自己专注的问题 和需要解决的痛点吧... 哈哈.. 至少我比较笨.. livesync 那个繁琐的设置 以及 部署服务端麻烦.. 把我劝退.. 所以我写的插件 基本都是设置简单.. 几下搞定..然后时间留给更重要的事情
@horrah #14 我可以理解为 网盘 也是一种集群服务器... 另外自己的服务器 是否稳定 跟 金钱投入 以及 服务器的放置地点有关系..所以不存在什么跑路这一说吧... 比如 你在阿里云上买了一个小鸡 vps 你会认为它明天就会跑路么? 你第二问题 是同步的策略问题.. 这个会慢慢优化.. 目前 插件的机制是 只同步你修改的笔记... 后续会加入 笔记内容更新 先只传内容 哈希值 ... 这样只要内容哈希一致就不需要把内容同步了... 还有就是 基于内容的更新 diffmatchpatch 会在大版本更新之后再考虑加入.. 毕竟 在一端obsidian上 你同时你只能编辑一个笔记而已.. 且在加入 哈希判断之后 那点 内容更新数据量 在 go + websocket 的执行效率面前不值一提.. 这也是为什么 obsidian-better-sync 只关注笔记文字内容的原因之一.. 毕竟如果加入了 附件等等... 一会更新几十兆 那绝对都是常态...
@MK #13 看了下 Self-hosted LiveSync 的实现原理,.. Self-hosted LiveSync 依赖 CouchDB 的 http API ... 所以你可以理解为 Self-hosted LiveSync 的作者 只是写了一个 c 端.. 并不是一套完整的C/S整套方案.. 另外 基于 http api 要实现实时更新 难免 是需要轮询 或者是 阻塞 长查询来实现实时更新的.. 这点在 手机端 可能会导致网络和电量的快速消耗.. 还有就是服务端是强依赖 CouchDB .. 无法实现各类扩展 联动功能 这点 obsidian-better-sync 的 c 端 和 服务端 完全是独立实现.. 服务端 obsidian-better-sync-service 为 Golang + Websocket + Sqlite 实现.. 所有同步数据全部走 Websocket 协议来实现实时更新.. 所以是真正的多端实时同步 (现在大部分直播平台基本都是基于 ws 协议,因为心跳等都是走的TCP,所以手机端比http协议消耗的更少) .. 而且 go 的程序 并发处理性能 更高.. 所以用户收益会相当高, 比如同步时间相当快..用户基本无感知等等.. 另外由于 服务端是独立实现 后续可以增加各类功能..比如备份到 云存储 或者 webdav 里 等等 当然还是要设置 功能边界 毕竟 搞多了抢官方同步的饭碗 我怕被下架.哈哈... 还有 目前 obsidian-better-sync-service 实际也 可以不用 sqlite ,略微改改 用 mysql 也可以... 当然项目创建之初采用 sqlite 是为了用户方便,不需要搭建数据库环境.. 还有就是设置超级方便..方便到什么程度..一句话就可以说明.. 服务端你架设好之后 在插件端粘贴配置就设施完了... 这点 self-hosted LiveSync 的设置 超级长的注意事项.. 还有步骤 1,2,3 我如果是一个真小白估计要理解半天... 比如CouchDB 是啥玩意... 至于 端到端加密...我是感觉有点多余..只要基于 ssl 的 wss 协议加密就好了啊... 无法理解为啥脱裤子放屁再搞一次加密 ( 纯个人想法 欢迎批评 )... 写的比较长哈... 希望能帮到你.. 有问题可以回复..
支持开源，感谢分享
@horrah #7 目前没 同步云存储的功能...
sqlite 数据库里 完整的笔记所有内容 一个笔记仓库 放一个sqlite 数据库
支持下，不过既然都要服务端，那跟self-hosted livesync其实没啥本质区别，在需要服务端的前提下用什么存储就没所谓了，而且couchdb对文档也专业对口
@haierspi #10
我可能不是太懂这些
但我目前的状态是
服务器相比网盘来说稳定性不高可能随时丢了或者跑路，而且储存的太小没有网盘放心，但是同样来说同步的速度很快
有没有：服务器只是用来对比数据然后进行更改（小数据同步/但是是不是不现实？因为我不清楚是不是每次都要对比所有的数据），网盘作为长期存储可以开启要不要自动同步（需要同步的数据量很大）
@MK #13 每个插件都有自己专注的问题 和需要解决的痛点吧... 哈哈.. 至少我比较笨.. livesync 那个繁琐的设置 以及 部署服务端麻烦.. 把我劝退.. 所以我写的插件 基本都是设置简单.. 几下搞定..然后时间留给更重要的事情
@horrah #14 我可以理解为 网盘 也是一种集群服务器... 另外自己的服务器 是否稳定 跟 金钱投入 以及 服务器的放置地点有关系..所以不存在什么跑路这一说吧... 比如 你在阿里云上买了一个小鸡 vps 你会认为它明天就会跑路么?
你第二问题 是同步的策略问题.. 这个会慢慢优化.. 目前 插件的机制是 只同步你修改的笔记...
后续会加入 笔记内容更新 先只传内容 哈希值 ... 这样只要内容哈希一致就不需要把内容同步了...
还有就是 基于内容的更新 diffmatchpatch 会在大版本更新之后再考虑加入..
毕竟 在一端obsidian上 你同时你只能编辑一个笔记而已..
且在加入 哈希判断之后 那点 内容更新数据量 在 go + websocket 的执行效率面前不值一提..
这也是为什么 obsidian-better-sync 只关注笔记文字内容的原因之一..
毕竟如果加入了 附件等等... 一会更新几十兆 那绝对都是常态...
膜拜大佬
@MK #13
看了下 Self-hosted LiveSync 的实现原理,..
Self-hosted LiveSync 依赖 CouchDB 的 http API ...
所以你可以理解为 Self-hosted LiveSync 的作者 只是写了一个 c 端..
并不是一套完整的C/S整套方案..
另外 基于 http api 要实现实时更新 难免 是需要轮询 或者是 阻塞 长查询来实现实时更新的..
这点在 手机端 可能会导致网络和电量的快速消耗..
还有就是服务端是强依赖 CouchDB .. 无法实现各类扩展 联动功能
这点 obsidian-better-sync 的 c 端 和 服务端 完全是独立实现..
服务端 obsidian-better-sync-service 为 Golang + Websocket + Sqlite 实现..
所有同步数据全部走 Websocket 协议来实现实时更新..
所以是真正的多端实时同步 (现在大部分直播平台基本都是基于 ws 协议,因为心跳等都是走的TCP,所以手机端比http协议消耗的更少) ..
而且 go 的程序 并发处理性能 更高.. 所以用户收益会相当高, 比如同步时间相当快..用户基本无感知等等..
另外由于 服务端是独立实现 后续可以增加各类功能..比如备份到 云存储 或者 webdav 里 等等
当然还是要设置 功能边界 毕竟 搞多了抢官方同步的饭碗 我怕被下架.哈哈...
还有 目前 obsidian-better-sync-service 实际也 可以不用 sqlite ,略微改改 用 mysql 也可以...
当然项目创建之初采用 sqlite 是为了用户方便,不需要搭建数据库环境..
还有就是设置超级方便..方便到什么程度..一句话就可以说明.. 服务端你架设好之后 在插件端粘贴配置就设施完了...
这点 self-hosted LiveSync 的设置 超级长的注意事项..
还有步骤 1,2,3 我如果是一个真小白估计要理解半天... 比如CouchDB 是啥玩意...
至于 端到端加密...我是感觉有点多余..只要基于 ssl 的 wss 协议加密就好了啊...
无法理解为啥脱裤子放屁再搞一次加密 ( 纯个人想法 欢迎批评 )...
写的比较长哈... 希望能帮到你.. 有问题可以回复..
支持一下，用CouchDB那个插件我觉得挺难用的。
支持