为何选用IPFS构建Berty—防审查的消息传递应用程序

欢迎来到本博客系列的第一部分，它将深入了解有关Berty及其工作原理的所有知识！在这些文章中，我们将向您介绍Berty的内部工作原理，回答一些常见问题，并解释一些我们最大的决定。在本系列的第一部分中，我们将重点介绍为什么选择使用IPFS构建Berty。

我们的最终目标

如您所知，Berty的目标是构建一个防审查的消息传递应用程序，以保护您的隐私。您的消息传递应用程序可能会保证将消息保持“私密”，对吗？不幸的是，这不是那么简单！

主流消息传递应用程序存在三个主要问题：

用户交换的所有消息都会通过并存储在中央服务器上。这意味着您的消息及其元数据都集中在一个地方，使它们更容易受到监视和检查。

并非所有应用程序都承诺端到端加密（E2EE）。一些消息传递应用程序使用E2EE来防止存储在中央服务器上的消息被发件人和收件人以外的任何人解密。不幸的是，并非所有应用程序都提供此功能，而其他应用程序则将其设置为启用设置。

并非所有流行的应用程序都是开源的。这使得检查消息是否经过适当加密以及所有通信实际上是否安全具有挑战性。

鉴于这些问题，我们决定创建Berty：一个开源消息传递应用程序，该应用程序在任何地方都使用E2EE，并且不依赖任何中央服务器。我们希望您（而没有其他人）拥有您的数据。

为什么集中化存储有问题？

让我们暂时了解细节。大多数情况下，服务器由IAAS提供程序拥有，例如Amazon Web Services，Google Compute Engine或Microsoft Azure。开发集中式消息传递应用程序的公司通常从这些IAAS提供者那里租用服务器（硬件），并且仅负责配置它们并安装允许用户之间交换消息的软件。

这些第三方IAAS提供商在主流消息传递应用程序熟悉的徽标后面，它们在使用服务方面几乎没有责任。因此，通过使用这些应用程序，您可以信任那些几乎不负责任地保护自己的数据的公司-无论其Big Tech客户的服务条款如何。这些提供商的合规性取决于其诚实度。

除此之外，即使政府或黑客对中央服务器进行了安全保护，它仍然更容易阻止或攻击中央服务器。过去，这已经发生过好几次了，而且一些政府仍在阻止其公民获得某些服务。

tl;博士：与Berty的分布式体系结构相比，集中式模型的实现较为简单，并提供了一些性能优势，但它会为您的隐私造成单点故障。它更容易受到审查和监视，并且要求用户盲目地信任相关参与者。

在没有中央服务器的情况下构建消息传递应用程序

我们如何摆脱在用户之间传递消息的中央服务器？解决方案非常具有挑战性：分发。

简而言之，使用Berty，不需要服务器，因为没有用户仅仅是客户端。每个对等点都承担P2P网络上客户端和服务器的角色。

在集中式系统中，交换的数据不会通过单个点传输，也不会存储在单个位置。

因此，监视和收集来自此类网络的数据要复杂得多，尤其是当网络承载来自大量不同应用程序的数据时。在这种情况下，特定Berty用户的元数据和消息就像大海中的一滴水。

另一个关键点是，阻止P2P网络要复杂得多。唯一的解决方案是设置深度数据包检测以分析流量（昂贵），尝试识别特定协议（复杂）并将其阻止。实际上，关闭也是不可能的，因为有必要关闭网络上所有可用的对等设备，并防止任何人在其终端之一上重新启动对等设备。

在项目开始时，我们决定研究可用的不同技术解决方案。每个Berty开发人员都将自己摆在角落，以构建他们认为最合适的概念证明（POC）。最后，有三个主要选择：

100％自制

使用BitTorrent

使用IPFS / libp2p

让我们尝试分解每一个选择：

1、100％自制

这似乎是一个不错的选择，因为没有限制（您可以使用任何技术实施任何想法）。简而言之，与我们所考虑的相比，并没有太多的约束。

问题：

很多设计，编写和维护的代码。

没有以前的经验（因此，犯下与他人相同的错误的可能性很大）。

没有同龄人，很难启动P2P应用程序。

没有活跃的社区可以帮助或开始。

结论：

这是对未知世界的一次巨大飞跃。太大。我们不喜欢变量（很有趣，因为我们是开发人员！）。我们必须采用已经存在的东西：具有网络基础设施和经验的社区。这样，将重点放在实现我们梦dream以求的消息传递应用程序的主要目标上会更加容易。

2、BitTorrent

如果您知道“对等”一词，则您可能知道BitTorrent！这是众所周知的P2P数据传输协议。该协议于2001年4月设计，并在2002年夏季由程序员Bram Cohen实施。BitTorrent是P2P的乳齿象！

尽管网络规模庞大，但BitTorrent的体系结构主要用于使用跟踪器共享种子。即使可以使用BitTorrent来实现消息传递应用程序，我们仍然认为我们需要更通用的东西。

问题：

专为洪流共享而设计

没有我们所需的通用，模块化和完整

结论：

有必要检查其他选项。

3、IPFS

另一个引起我们关注的项目是InterPlanetary File System，这是一种用于通过超媒体分发可寻址内容的对等协议。尽管IPFS项目比BitTorent还要年轻，但它已经成熟。

该项目似乎更令人印象深刻，因为IPFS背后的协议实验室（Property Labs）有一个很好的主意，可以通过提供libp2p将项目分成几部分，并使IPFS网络部分的所有代码独立，这是一个提供所有必要工具的库创建P2P应用程序。

该库经过精心设计，模块化且功能强大。而且每个部分都可以与自定义代码完全互操作和互换。这使我们能够扩展和定制现有功能以满足我们的特定需求，同时得到IPFS的经验和社区的支持。

最重要的是，golang提供了该库的主要实现之一，它是：

我们已经掌握的技术

一种可以在任何平台上编译的语言，包括移动平台（使用gomobile）

4、IPFS与LibP2P

对于Berty v1，我们决定使用libp2p而不是使用完整的IPFS节点来实现自定义网络。这意味着我们使用的是与IPFS相同的基础库，但是对其进行了定制，以使我们的节点无法与传统IPFS节点完全互操作。

在此阶段，我们开始开发直接传输的第一个版本，允许两个设备通过蓝牙连接进行离线通信。您可以在此博客文章中找到更多信息。

在Berty的第一个版本中，我们所有的通信都是同步的：用户只有在联机并相互连接时才能互相发送消息。

对于消息传递应用程序来说，这显然是一个糟糕的情况，并且在试图找出解决方法时，我们提出了一个非常接近Orbit-DB Javascript库已经在做的设计。

Orbit-DB使在IPFS上灵活地组织数据成为可能。该库基于IPFS日志：基于IPFS上存储的内容的不可变日志。

经过讨论后，我们得出结论，将Gobit Orbit-DB移植到golang中比从头开始实施非常相似的解决方案更为明智。

在将自定义libp2p网络与全节点IPFS进行比较时，我们偶然发现了一些重要的见解：

与使用自定义节点相比，使用完整的IPFS节点将使我们能够更好地受益于IPFS现有网络并为之做出贡献。

我们可以开发IPFS的通用移动版本，这将对社区有用，并利用他们的贡献来改进项目。

我们将开发的其他项目（直接运输驱动程序，go-orbit-db等）也将更加通用，从而加强与社区的协作。

因此，我们决定放弃我们的自定义网络，基于一个完整的IPFS节点从头启动Berty V2，并启动以下项目：

gomobile-ipfs：

o 一个IPFS节点，适用于移动平台并绑定了本机语言。我们的目标是针对移动限制对其进行优化，并基于低功耗蓝牙，Apple MultipeerConnectivity和Android附近添加直接传输。

go-orbit-db：

o 原始Javascript库的golang端口。从长远来看，我们希望这两个版本完全兼容。

关于为什么不使用区块链？

这是一个反复出现的问题。您为什么不在区块链上创建消息传递系统？

答案很简单：区块链需要共识，互联网和等待验证的时间，这是我们在Berty中想要避免的事情。最重要的是，与匿名交换消息相比，区块链更适合在没有中央授权的情况下验证交易。

最后，我们正在开发的架构与区块链截然不同。Berty协议从头到尾都采用“无共识”的原则构建，并且可以在没有Internet访问的情况下运行。

使用纺织品呢？

好问题！

纺织提供了一套开源工具，可以通过IPFS快速开发去中心化应用程序，包括移动平台。

我们喜欢他们的工作，并向大多数询问我们如何为他们的项目开始使用IPFS的人提供建议。这是一个很好的统包解决方案，但是在我们的特定情况下，我们需要更大的灵活性。

结论：

总结一下，这是Berty目前的工作：使用IPFS，我们正在研究gomobile-ipfs，go-orbit-db和直接传输驱动程序，以构建将在我们的消息传递应用程序中使用的P2P网络。

目前，我们的担忧之一是即使IPFS已经完成，我们也必须自己实现堆栈的很大一部分。

另一点是，我们的协议需要IPFS所不具备的特定功能，这些特定功能对于我们的基础结构发挥最佳功能至关重要。

因此，我们需要具有比移动应用程序更好的正常运行时间并且对网络性能约束更少的对等方，以确保高可用性。因此，我们希望Berty Desktop用户将担当此角色，并且用户社区将建立服务器高可用性对等设备，其唯一目的是帮助网络。

—-

编译者/作者：星际大陆

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。