Laverna: 同步到非商业存储

或者自有云...

看看vol.cc。 他们有一个自定义的基于 Go 的服务器，可以将内容保存到文件中。 您可能只需插入它即可轻松进行本地存储。

是的，插上自己的云将是完美的

同步到 OwnCloud 会很有趣。

Bittorrent Sync 选项也不错。

+1 为 owncloud

正如@michielbdejong写的关于 StackEdit 的那样，在里面可能会发现通用的多供应商数据存储连接器的有趣方法。

此外， remoteStorage现在也

+1 为自己的云！

+1

+1 Cozy.io、Owncloud、Bittorrent 同步。 其中任何一个都会很棒！

我认为这个线程表明需要一种将 Laverna 连接到存储提供商的标准化方法。 每个人都有自己喜欢的个人数据托管程序。 这没有错，但现在开发人员已经提供了可行的商业 (Dropbox) 和非商业 (RemoteStorage) 方法，我更希望他们专注于扩展项目的其他方面。 从长远来看，为用户提供自行连接的工具将腾出时间。

我还想要 Google Drive 同步（甚至 Google Keep 同步）

+1 - 我也同意@andtheWings。

但就目前而言，我认为添加 2 个服务：GoogleDrive（主要，因为大多数人已经在使用它）和 OwnCloud（广泛使用的 Dropbox 非商业替代方案）将覆盖非常大的用户群，并向更多人开放 Laverna 笔记。

这确实可以扩大社区。

请注意，remoteStorage 使 Google Drive 和 Dropbox 同步开箱即用。 在5apps.com 上查看。

_Edit:_ 浏览器中的 Bittorrent Sync 听起来很冒险。

@almereyda Err，你能不能更具体地说明我如何通过 remoteData 将我的笔记存储到 5apps.com 的谷歌驱动器？

@almereyda如果说“开箱即用的同步”，您的意思是在您自己的控制之下，那么OwnCloud 也是如此。

但我的观点是传播 Laverna 的用法并使其易于被公众采用。 我相信 Google Drive 是那里缺失的链接。 大多数人都有一个谷歌帐户，他们可以直接使用他们的谷歌驱动器，而不是通过另一个服务注册和设置重新启动。

由于这里的大多数人更喜欢 OwnCloud（包括我）并且它是开放的/非商业的，我肯定会推荐一个首先通过 Google Drive 开发的选项。

我选择使用 Laverna，希望它可以演变成能够取代 Evernone 的东西。 我正在使用 OwnCloud 来替换 Dropbox、Google Drive 等。 我采取了这些步骤，以便我不再需要依赖这些服务并同意他们的条款。 我知道添加与 Dropbox 等服务同步的选项会增加受欢迎程度（我鼓励这样做），但对我个人而言它不适合。

@SandeepPinge

万岁！

面向大众的 GDrive / 面向真实用户的 Owncloud！
恕我直言，Owncloud / GDrive 是一款出色的免费 / 专有软件组合。

我在自己的网站空间上运行 Laverna。 为什么我不能将数据（加密）直接保存到网络服务器？ 或者我可以在我的网络服务器上实现 RemoteStorage 吗？ 我没有SSH访问！

我认为 Laverna 不被认为是托管应用程序，而是在本地运行并在本地存储文件。 我也更喜欢托管解决方案，因为它使设备之间的同步更容易。

当地的？
如果我想要本地笔记，我使用 notepad.exe。
;-)

Laverna 被设计为非托管的，即默认情况下将数据存储在本地浏览器上。 更多信息在这里： https :

“我们没有人可以访问您的个人数据，因为我们使用的是 IndexedDB 和 localStorage。事实上，您的所有信息都只会存储在客户端。”
这意味着，afaik 数据存储在本地（在浏览器可以访问的文件夹中）。 但是可以使用 Dropbox（希望其他替代品很快）来同步笔记。

大家请注意，远程存储现在在 Cozy Cloud 中可用，因此您可以轻松地旋转自己的实例。

此外，由于 Laverna 支持 remoteStorage，但它似乎是一个旧规范，已经有人将其集成到 ownCloud 中。

@michielbdejong @skddc你能快速浏览一下 Laverna 并检查它为什么无法与 5apps 同步吗？ 它曾经可以工作，我相信在 0.10 版本之前。 他们只是没有更新客户端吗？ submodule有意义吗？

我不熟悉 Marionette 或此应用程序的源代码。 然而，我们总是在这里帮助和回答所有的问题，包括一般的和具体的代码。

谁在此应用程序中维护 RS 支持（或一般维护应用程序）：我们非常期待在 Freenode 上的 #remotestorage 中欢迎您，或者在论坛或 GitHub 上讨论任何内容。

我也会添加 Syncthing (https://syncthing.net/) 和 Seafile (http://seafile.com/en/home/)。

1+为OwnCloud！

1+ 自有云

自己的云会很棒。

自己的云 +1

自己的云+1

自己的云+1
我和@Putdeksel 的情况完全一样
通过使用自己的存储系统完全控制您的笔记将是惊人的。

通过使用自己的存储系统完全控制您的笔记将是惊人的。

是的，它 _is_ 令人惊奇，并且通过 Laverna 的 RemoteStorage 支持已经成为可能。 您甚至无需绑定到单个服务器实现，但任何使用 RS 协议的服务器都可以存储您的笔记。 ;)

@skddc 老实说，我还没有研究过 RemoteStorage。 但遗憾的是，从我所见，我的提供商提供的服务器似乎不支持它。 希望它会在不久的将来！

+1 ownCloud。

OwnCloud 同步会很棒。

+1 为 owncloud！

我可以在这里向所有 ownCloud 用户推荐一些东西吗：

如果 ownCloud 支持用于每个用户数据存储的开放协议，那么应用程序开发人员（不仅仅是这个应用程序的）支持 ownCloud 会_容易得多。 这个应用程序已经支持 remoteStorage，所以如果 ownCloud 支持 remoteStorage，开发人员不必为他们的应用程序添加特殊的 ownCloud 支持，那么所有支持 remoteStorage 的应用程序也将自动使用 ownCloud 作为远程存储服务器。

因此，我认为如果您要求/投票或为 ownCloud 本身提供 RS 支持，那就太好了！

跟随这次谈话已经几年了，我必须支持
@skddc的最新评论。

七月2016年25 14:22，塞巴斯蒂安Kippe [email protected]写道：

我可以在这里向所有 ownCloud 用户推荐一些东西吗：

应用程序开发人员（不仅是此应用程序的开发人员）_更容易_
支持 ownCloud，如果 ownCloud 支持每个用户的开放协议
数据存储。 这个应用程序已经支持远程存储，所以如果 ownCloud 是
支持远程存储，而不是开发人员必须添加特殊
ownCloud 支持他们的应用程序，那么所有支持 remoteStorage 的应用程序都会
自动还与作为远程存储服务器的 ownCloud 一起使用。

因此，我认为如果您要求/投票或贡献 RS，那就太好了
支持ownCloud本身！

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265，或者静音
线程
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

我+1这个问题！

嗯，实现 webDAV 会不会很困难，因为这可以被视为一种开放标准，允许 laverna 连接到数十个不同的存储提供商？

为什么不将数据存储在指定的本地目录中，人们可以通过 Seafile 或 ownCloud 桌面客户端等同步客户端将他们的数据同步到云中？

为什么不将数据存储在指定的本地目录中，人们可以通过 Seafile 或 ownCloud 桌面客户端等同步客户端将他们的数据同步到云中？

这只能在应用程序的潜在打包版本中实现，而不能在 Web 上实现。 这也是 remoteStorage 解决的问题以及为什么在 Laverna 中使用它。

到目前为止，这里有人打开过有关集成 remoteStorage 的 ownCloud 问题吗？ 我只能强调这会有多好，然后 Laverna 会自动支持 ownCloud。

这只能在应用程序的潜在打包版本中实现，而不能在 Web 上实现。 这也是 remoteStorage 解决的问题以及为什么在 Laverna 中使用它。

我实际上从未成功拥有功能齐全的 remoteStorage 同步。 我试了很多次，每次都很难对付。 我对 IndexedDB 数据不太满意...

我对 DAV 同步比较熟悉。 @wwebfor告诉我还有另一种在烤箱中同步的方法，想。

我实际上从未成功拥有功能齐全的 remoteStorage 同步。 我试了很多次，每次都很难对付。

你是说在同步修复一段时间后它失败了，你打开了一个关于它的问题，没有得出结论？

我还没有看到任何此类问题或请求，但我很乐意为您提供帮助！ 不确定“每次都很难与所有人打交道”是什么意思。

我对 IndexedDB 数据不太满意

嗯，它基本上是现代浏览器中本地唯一可用的数据库（当然除了 localStorage），所以实际上没有其他选择。

你是说在同步修复一段时间后它失败了，你打开了一个关于它的问题，没有得出结论？

不，我问过 Gitter，我得出的结论是，我必须在我使用的每个浏览器上清理所有数据，因为它似乎可以在干净的浏览器上正常工作（从未使用过 Laverna）。

不确定“每次都很难与所有人打交道”是什么意思。

我使用的每个浏览器（或桌面客户端），每次我使用其中一个。

嗯，它基本上是现代浏览器中本地唯一可用的数据库（当然除了 localStorage），所以实际上没有其他选择。

是的，是的，我明白了。 但我的意思是我不习惯这种同步数据的方式。

对我来说听起来像是升级问题。 所以，当你写...

我实际上从未成功拥有功能齐全的 remoteStorage 同步

......这是否意味着它仍然不起作用？ 如果是这样，那么我仍然很乐意提供帮助。

+1 用于 webDAV，比“仅限自己的云”解决方案标准得多。 让我们保持开放。

与其集成大量无意义的新潮人解决方案（如 remoteStorage），为什么不使用久经考验的 webDav？ 我的意思是什么意思？ 如果行业标准事实上是别的东西，你为什么要强迫用户屈服于你的意愿？

说是的，rs 支持这一点，这对大多数人来说没什么用。 但我不想使用另一个我不关心的协议。 您支持商业 Dropbox，但拥有笔记意味着我不想将它们保存到 3rd 方服务器。 您只是不想了解您的软件只有在人们愿意使用它时才能生存，因为它的友好性和灵活性。 相反，你的目标是强硬地武装他们去做他们不想做的事情。 这些都是开发人员和精通技术的人，你只是不明白这个简单的事实。

@technodrome我不是代表 Laverna 开发人员，而是作为 remoteStorage.js 开发人员。 也许不清楚，我试图帮助这里的人（如果你仔细阅读历史，我从未尝试过任何其他事情）与告诉人们离开不同，因为他们的意见无效或被其他人听到。 据我所知，这当然是表达他们意见的正确地方，我不知道为什么你在这个线程中的第一条评论如此敌对。 让我们彼此善待，因为这对我们所有人来说都是无偿的志愿工作！

相反，你的目标是强力武装他们去做他们不想做的事情

我看不出如何免费提供开源软件对任何人都有好处。 如果这些都是开发人员和精通技术的人，那么肯定有人可以提供 WebDAV 支持，如果有意义的话？

那么，让我们客观地看一下WebDAV的可行性。 这是我能想到的问题的（可能不完整的）列表，需要解决这些问题才能集成 WebDAV。 （这些基本上就是最初创建 remoteStorage 协议的原因。实际上，RS 一开始就使用 WebDAV，作者决定将其删除，转而使用更简单的 REST API，基于现实世界测试和经验）：

1.CORS

浏览器的工作方式是像 Laverna 这样的非托管应用程序直接从 JavaScript 连接到服务器。 这带有限制，即服务器必须为所有请求提供跨源资源标头，并支持对可以操作数据的 HTTP 动词的 OPTIONS 预检请求，例如 POST、PUT、DELETE。 大多数 WebDAV 服务器不支持这一点。 因此，许多 WebDAV 服务器开箱即用与 Laverna 不兼容。

问题：即使人们不关心那些服务器不兼容，应用程序如何检测是否存在支持？ 由于浏览器故意不提供有关连接失败原因的 JS 代码详细信息，这实际上变得更加困难，因此需要某种发现机制。 此外，必须向用户解释究竟是什么原因，以及他们可能必须切换服务器才能使用该应用程序。

RS 中的解决方案：该协议要求开箱即用的 CORS。 此外，发现是通过 Webfinger 处理的，用户地址可以在其中返回所有配置信息，还可以在其中宣布服务器的额外功能。

普通 WebDAV/Laverna 的解决方案：有什么想法吗？

2. 权限/授权

权限必须在服务器端和 WebDAV 中的每个帐户处理，因为协议中没有内置这样的东西。 某些文件夹的访问权限不存在。

RS 中的解决方案： OAuth 2.0，因此应用程序开发人员可以决定他们需要访问存储的哪一部分，用户可以轻松查看那部分，并在一个简单的对话框中决定授予访问权限。

普通 WebDAV/Laverna 的解决方案：这基本上是不可能的，但当然可以跳过该功能并自愿让 Laverna 访问一个人的所有数据。 不优雅，但肯定不是实施的阻碍。

3. 离线/移动支持

这不是 WebDAV 的特别问题，也不是完全在 RS 规范中解决的问题。 但对于支持移动的 Web 应用程序来说，它仍然是一个重要因素。 桌面和移动连接都经常掉线，人们不希望他们的笔记因此而被保存。 因此需要使用某种离线存储，并与远程服务器智能同步（当然，如果您想创造良好的用户体验，则每次删除后都无需重新验证）。

这里有两个问题：

问题一：服务器需要支持Etags，所以可以先搭建同步机制

RS 中的解决方案：通过在目录资源及其项目列表以及单个文档本身上都需要 ETag，这在协议中得到部分解决。 基于此，可以使用 HTTP 标头（例如If-None-Match和响应（例如空304用于请求未更改的事物和412用于拒绝）来构建同步机制覆盖在不同时间在不同设备上更改的内容。

普通 WebDAV/Laverna 的解决方案：不幸的是，Etag 支持只是 WebDAV 规范中的一个 SHOULD，因此许多服务器不支持它，有些甚至明确要求他们的用户关闭支持，即使他们拥有它，因为它已实现以一种非执行的方式。 （对于服务器开发人员来说，这实际上不是一个简单的问题；我当然可以证明这一点）。 但与 CORS 类似，这是可能的，因此这里的解决方案将再次归结为功能发现和指导用户配置他们的服务器或告诉他们必须切换到另一台服务器。 幸运的是，这比使用 CORS 容易得多，因为可以通过检查响应头从 JS 中检测到这一点。

问题 2：编写实际的同步机制或使用提供同步机制的库

RS 中的解决方案：很早就，规范作者之一开始创建一个参考客户端库来为想要将 RS 集成到他们的应用程序中的人们解决这个问题。 它仍在维护和开发中，并且已经在数十万种不同的连接、设备、操作系统、浏览器、Cordova 等上进行了实战测试。 它也被用于Laverna。 第一次提交可以追溯到 2010 年 11 月，因此这当然不是“新潮人解决方案”。 如果它有错误，有人很乐意帮助解决这些问题，并且任何反馈都是并且始终受到赞赏（因此我在此线程中积极响应）。

普通 WebDAV/Laverna 的解决方案

请原谅并指出此列表中包含的任何错误或错误事实。 我基本上把所有这些都写在了我的头上。 我很快就会把这个转移到 RS wiki，并请一些人审查/编辑我写的东西，因为我认为这实际上是对 WebDAV 和 RS 之间差异的一个相当有用的解释，以及 RS 如何解决 WebDAV 的问题还没有，当谈到完全在浏览器中运行的客户端 Web 应用程序时（这是可以理解的，因为 Web 平台功能在当时并不真正存在，而且离线优先 Web 应用程序的整个概念并不是事物）。

@technodrome如果您想实现获得 WebDAV 支持的目标，那么指出任何这些问题的潜在解决方案（或使它们完全无效的事实）可能会有很长的路要走。

抱歉，但如果您无法理解常识用户的观点，因为您觉得它伤害了您的感受或意见，那么问题出在您身上。 专为人们设计的软件被定义为不止一个人使用——而不仅仅是你。 因此，应该邀请每个人发表意见，因为集思广益和想法是推动项目前进的动力。 从为 webDav 或其他标准化协议支持发布 +1 的人来看，不仅仅是我。

你试图扭曲我所说的，把事情个人化，即使它们是在一般层面上的个人意见。 但关键是 - 如果开发人员不提供任何保存用户数据的标准化方法，那么是的 - 他/她正在强力武装用户使用开发人员的偏好。

精通技术的用户不等于程序员。 不要仅仅因为它适合你的修辞就妄下结论。

另外，我清楚地表示我很欣赏这些工作和努力，而且我确实做到了。 这并不意味着我会因为你这么说就盲目同意一切。 这是我的权利，也是你的权利，有数百万种方法可以解决这个问题。 当然，您正在推动您的产品，但让我们在这里有点民主，并提供适合更多人的选择自由，而不仅仅是您。

虽然您列出了大量它无法工作的原因以及为什么您的 RS 解决方案可以治愈所有疼痛，但我确信作为本地守护程序（客户端、服务器）运行的中间端点（Go 应用程序？）可以处理授权和启用多种可能性来集成您想要的任何协议。 与维护一整套技术相比，它肯定会带来更少的头痛，这些技术可能会或可能不会在两年内被遗忘和过时。

另外，我的评论并不是要证明任何人是错的，只是说有一定的行业标准，并且事情成为这样的标准是有原因的。 如果你不能理解这一点，恐怕没有任何论证可以说服你相信除了你的真理之外的任何其他真理。

嗯，我读到了双方的好论点。 最终拥有我的存储对我来说是一个要求，并且因为服务器上的（加密）存储是项目核心的一部分而去 turtl。
如前所述，如果产品不能满足您的所有需求，并且在这种情况下似乎有其原因（当然人们仍然可以争论），那么寻找更接近您的需求和要求的产品。
我相信很多人都可以在 Dropbox 上托管他们的文件。 无需全力以赴，尤其是在开源产品上。 我理解并分享这种挫败感，但开源有很多商业计划，有时它们不符合我们的要求。 只需要处理它。

勒24 FEVRIER 2017年12时27分33秒GMT + 00：00，technodrome [email protected]一个écrit：

对不起，但如果您不能理解常识用户观点
因为你觉得它伤害了你的感情或意见，那么问题就来了
与你同在。 供人们使用的软件是由定义使用的
不止一个人——不仅仅是你。 因此，每个人都应该
被邀请提供意见，因为头脑风暴和想法是什么
推动项目向前发展。 并根据发出 +1 的人来判断
webDav 或其他标准化协议支持，不仅仅是我。

你试图歪曲我说的话，甚至把事情当成个人来对待
尽管它们是在一般层面上的个人意见。 但要
重点 - 如果开发人员不提供任何标准化的方法
保存用户数据，然后是 - 他/她正在强力武装用户
使用开发人员的偏好。

精通技术的用户不等于程序员。 不要妄下结论
只是因为它适合你的修辞。

另外，我清楚地表示我很欣赏这些工作和努力，而且我确实做到了。
这并不意味着我会盲目地同意一切，因为
你是这么说的。 这是我的权利，也是你的权利，有数百万种方式
如何着手解决这个问题。 当然你在推动你的
产品但让我们在这里有点民主并提供自由
适合更多人的选择，而不仅仅是你。

虽然你列出了一大堆为什么它不能工作的原因，以及为什么你的
RS 解决方案是治疗所有疼痛的方法，我相信中间人
作为本地守护程序（客户端、服务器）运行的端点（Go 应用程序？）可以
处理授权并启用许多可能性
几乎可以集成您想要的任何协议。 它肯定会带来更少
比维护一整套技术更令人头疼，这可能或可能
不会在两年内被遗忘和过时。

另外，我的评论不是为了证明任何人错了，只是想说
有一定的行业标准，事情是有原因的
成为这样的标准。 如果你不能理解，恐怕
没有任何论据可以说服你相信任何其他真理
比你的。

——
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看：
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

——
Envoyé de mon appareil Android avec K-9 邮件。 Veuillez 借口 ma brièveté。

因此，应该邀请每个人发表意见，因为集思广益和想法是推动项目前进的动力。 从为 webDav 或其他标准化协议支持发布 +1 的人来看，不仅仅是我。

是的！ 我确切地说明了这一点，然后花了时间和精力指出我认为需要解决的问题才能实现您的愿望。 我没有为了“适合我的议程”而扭曲任何东西，我积极邀请您和其他任何人指出我的客观分析中包含的任何错误，我还邀请您帮助推进您自己的偏好/想法的实施。

不幸的是，在您的后续评论中的指控中找到实质性论点或新事实并不容易。 但有一段话至少包含一个想法：

我确信作为本地守护程序（客户端、服务器）运行的中间端点（Go 应用程序？）可以处理授权并启用许多可能性来集成您想要的任何协议

所以是的，这在理论上当然是可能的。 问题在于它与您自己在同一段落中的观点和论点完全冲突：

与维护一整套技术相比，它肯定会带来更少的头痛，这些技术可能会或可能不会在两年内被遗忘和过时。

您的想法将意味着：创建、测试和维护全新的技术堆栈（“客户端、服务器”），以便 Web 应用程序能够远程存储数据，并跨设备同步数据。 除了发明和维护这个全新堆栈的问题外，在所有设备上运行该本地程序也相当困难，最重要的是移动设备。

另外，我的评论并不是要证明任何人是错的，只是说有一定的行业标准，并且事情成为这样的标准是有原因的。

我完全同意这一点！ 我详细解释了为什么 WebDAV 确实没有成为客户端 Web 应用程序的标准，以及为什么创建 RS 协议——最初甚至将 WebDAV 作为 API——作为一种新标准，使每个用户、自托管可以为这种确切类型的应用程序存储。

它实际上是一个相当简单的协议，与“技术堆栈”相反。 如果您还没有看到它的部分的快速说明，您可以在这个网站上找到它。 -- 另外，关于“webDav 或其他标准化协议支持”，这正是RS 的意思。

现在，您当然可能对 WebDAV 不是客户端 Web 应用程序过于可行的解决方案感到消极，但这并不会以某种方式改变手头的事实，或者让我成为一个自负的混蛋来指出它们。 拜托，拜托，让我们理性地讨论一下，避免个人指责。 我真的只是想帮忙，绝对没有消极的必要。 再说一遍：我实际上是在努力帮助您实现目标，而且我绝对不是在主张 RS 是唯一的解决方案。 如果有人能想出任何其他解决方案来实现相同的目标，那么我是最后一个基于个人偏好或意识形态反对它的人。

Laverna 作为 Web 应用程序，只能支持 HTTP 作为传输协议，并且需要 CORS 才能正常工作。 然而，出于某种原因，人们提出了 BitTorrent Sync 或 WebDAV 之类的东西，其中之一不通过 HTTP 运行，并且都没有将 CORS 作为其规范的一部分。 事实上，前者甚至没有规范，它是一个专有协议。 @technodrome甚至将 WebDAV 的使用称为“常识用户视角”，但同样，从浏览器内的 Javascript 应用程序中使用 WebDAV 在一般情况下不起作用，因此无论视角如何都没有意义. 关于使用中间代理添加 CORS 标头的讨论也不符合我对良好 UX 的想法。

我认为这确实表明，这个讨论主要由希望“一般软件自由”并抛出一些已建立协议的名称的人主导，而不是真正从技术角度认真研究这些选项中的任何一个并确定它们是否适用的人是工作的正确工具。 再次，我想喊一声@technodrome，谁除了抛出发脾气，因为他（理解）察觉@skddc的倡导remoteStorage作为先令推动自己的议程，同时@skddc是在这个线程的第一个为他提议的协议提出一个体面的论点。

或许我们应该承认，即使在这个问题开了三年之后，也没有标准。 这给我们留下了三个选择：

1. 押注远程存储，尚未成为标准
2. 无论如何都使用 WebDAV，但需要 CORS 标头。 实际上，这意味着仅支持 NextCloud 和 ownCloud。
3. 使用自定义 API 编写自定义 NextCloud 插件

广告 1：remoteStorage 作为协议非常好，但我认为客户端库还没有。 事实上，我最后一次使用 remoteStorage.js（客户端库）的体验并不好。 一切正常，但仍然到处都是小错误，我只是不认为高级“数据建模”API 可用。 不过，最后一部分应该无关紧要，因为您可以编写自己的数据模型并读写原始文件。

广告 2：这完全可行，但现在您必须将自己限制在 NextCloud/ownCloud，同时还要处理 WebDAV 的巨大复杂性。 我想我可以为曾经使用该协议的每个人发言，当我说如果用户不能从中受益时，仅仅为了使用标准而使用 WebDAV 是不值得的。

鉴于 Laverna 已经有 remoteStorage 支持，我确实认为投入更多时间修复 rs.js 客户端库是一个很好的前进方式，尽管我们可能需要 NextCloud 支持让任何人使用该后端。 一个专门的 NextCloud 应用程序也是 IMO 的一个不错的选择，尽管它错过了更多标准的目标。

你好呀，
请向https://github.com/Laverna/laverna/issues/971#issuecomment -411423965 报告该项目的状态。

有一个美好的一天/夜晚，
干杯，
尼萨尔