跳到主要内容

每周项目:Dat

·7 分钟阅读

本周的特色项目是 Dat,这是一个 获得资助的、开源的、去中心化的数据分发工具。 Dat 由一个 地理分布式团队 构建和维护,他们中的许多人帮助撰写了这篇文章。


A screenshot of the main view of dat-desktop, showing a few rows of shared
dats

首先,Dat 是什么?

我们希望将点对点和分布式系统的最佳部分带到数据共享中。我们从科学数据共享开始,然后开始扩展到研究机构、政府、公共服务和开源团队。

另一种思考方式是同步和上传应用,如 Dropbox 或 BitTorrent Sync,只是 Dat 是开源的。我们的目标是成为一个强大、开源、非营利的数据共享软件,适用于大型、小型、中型、小批量和大批量数据。

要使用 dat CLI 工具,您只需输入

dat share path/to/my/folder

Dat 将创建一个链接,您可以使用该链接将该文件夹发送给其他人 - 没有中央服务器或第三方可以访问您的数据。与 BitTorrent 不同,也不可能嗅探到谁在共享什么(有关更多详细信息,请参阅 Dat Paper 草案)。

现在我们知道了 Dat 是什么。Dat Desktop 如何融入其中?

Dat Desktop 是一种使 Dat 能够被无法或不想使用命令行的人访问的方式。您可以在您的机器上托管多个 dat,并通过您的网络提供数据服务。

您可以分享一些很酷的用例吗?

DataRefuge + Project Svalbard

我们正在开发一个代号为 Project Svalbard 的项目,该项目与 DataRefuge 相关,DataRefuge 是一个致力于备份面临消失风险的政府气候数据的组织。 Svalbard 以北极圈的斯瓦尔巴全球种子库命名,该种子库有一个大型地下植物 DNA 备份库。我们的版本是一个大型版本控制的公共科学数据集集合。一旦我们了解并可以信任元数据,我们就可以构建其他很酷的项目,例如 分布式志愿者数据存储网络

California Civic Data Coalition

CACivicData 是一个开源档案库,提供来自 CAL-ACCESS(加利福尼亚州追踪政治资金的数据库)的每日下载。他们进行每日发布,这意味着在其 zip 文件中托管大量重复数据。我们正在努力将他们的数据托管为 Dat 存储库,这将减少引用特定版本或更新到较新版本所需的麻烦和带宽。

Electron 更新

这个用例尚未具体化,但我们认为一个有趣的用例是将编译后的 Electron 应用程序放入 Dat 存储库中,然后使用 Electron 中的 Dat 客户端拉取构建的应用程序二进制文件的最新增量,以节省下载时间,同时降低服务器的带宽成本。

谁应该使用 Dat Desktop?

任何想要通过 p2p 网络共享和更新数据的人。数据科学家、开放数据黑客、研究人员、开发人员。如果任何人有我们尚未想到的很酷的用例,我们非常乐于接受反馈。您可以访问我们的 Gitter 聊天,并向我们提出任何问题!

Dat 和 Dat Desktop 的下一步是什么?

用户帐户和元数据发布。我们正在开发一个 Dat 注册表 Web 应用程序,将部署在 datproject.org 上,这基本上将是一个“数据集的 NPM”,唯一的注意事项是我们将只是一个元数据目录,数据可以存在于任何在线位置(与 NPM 或 GitHub 不同,在 NPM 或 GitHub 中,所有数据都集中托管,因为源代码足够小,您可以将其全部放入一个系统中)。由于许多数据集都很大,因此我们需要一个联合注册表(类似于 BitTorrent 跟踪器的工作方式)。我们希望让人们可以轻松地通过 Dat Desktop 从注册表中查找或发布数据集,从而使数据共享过程无摩擦。

另一个功能是多作者/协作文件夹。我们有宏伟的计划来开展协作工作流程,可能带有分支,类似于 git,但围绕数据集协作而设计。但我们目前仍在致力于整体稳定性和标准化我们的协议!

您为什么选择在 Electron 上构建 Dat Desktop?

Dat 是使用 Node.js 构建的,因此它非常适合我们的集成。除此之外,我们的用户使用各种机器,因为科学家、研究人员和政府官员可能被迫为其机构使用某些设置——这意味着我们需要能够以 Windows 和 Linux 以及 Mac 为目标。 Dat Desktop 可以非常轻松地实现这一点。

在构建 Dat 和 Dat Desktop 时,您遇到过哪些挑战?

弄清楚人们想要什么。我们从表格数据集开始,但我们意识到解决这个问题有点复杂,而且大多数人都不使用数据库。因此,在项目进行到一半时,我们从头开始重新设计了一切,以使用文件系统,并且没有回头。

我们还遇到了 Electron 的一些通用基础设施问题,包括

  • 遥测 - 如何捕获匿名使用情况统计信息
  • 更新 - 设置自动更新有点零散且神奇
  • 发布 - XCode 签名、在 Travis 上构建版本、进行 beta 构建,这些都是挑战。

我们还在 Dat Desktop 的“前端”代码中使用 Browserify 和一些很酷的 Browserify Transforms(这有点奇怪,因为即使我们有原生 require,我们仍然捆绑——但这仅仅是因为我们想要 Transforms)。为了更好地帮助管理我们的 CSS,我们从 Sass 切换到使用 sheetify。它极大地帮助我们模块化了 CSS,并使我们将 UI 迁移到具有共享依赖项的面向组件的架构变得更加容易。例如,dat-colors 包含我们所有的颜色,并在我们所有项目之间共享。

我们一直是标准和最小抽象的忠实拥护者。我们的整个界面都是使用常规 DOM 节点和一些辅助库构建的。我们已经开始将其中一些组件移动到 base-elements,这是一个低级可重用组件库。与我们的大多数技术一样,我们不断迭代它,直到我们做对为止,但作为一个团队,我们感觉我们正朝着正确的方向前进。

Electron 应该在哪些方面改进?

我们认为最大的痛点是原生模块。必须使用 npm 为 Electron 重建模块增加了工作流程的复杂性。我们的团队开发了一个名为 prebuild 的模块,该模块处理预构建的二进制文件,该模块在 Node 中运行良好,但 Electron 工作流程在安装后仍然需要自定义步骤,通常是 npm run rebuild。这很烦人。为了解决这个问题,我们最近切换到一种策略,即我们将所有平台的所有已编译二进制版本捆绑在 npm tarball 中。这意味着 tarball 会变得更大(尽管可以使用 .so 文件(共享库)进行优化),这种方法避免了运行安装后脚本,也完全避免了 npm run rebuild 模式。这意味着 npm install 第一次为 Electron 做正确的事情。

您最喜欢 Electron 的哪些方面?

API 似乎经过深思熟虑,它相对稳定,并且在与上游 Node 版本保持同步方面做得很好,我们别无所求!

是否有任何 Electron 技巧可能对其他开发人员有用?

如果您使用原生模块,请尝试使用 prebuild

关注 Dat 发展的最佳方式是什么?

在 Twitter 上关注 @dat_project,或订阅我们的 电子邮件新闻通讯