联邦政府尚未实现的潜力

互联网上有一些看起来很难解决的主要问题。我们如何防止我们的通信工具在少数动机可能与我们的利益不一致的人的权威下集中化？没有庞大的预算，我们如何建设互联网规模的基础设施呢？面对技术和社会问题，我们能让我们的系统变得可靠和容错吗？

联合的软件系统的关键特征是服务器由独立的、主权的实体控制，并且它们在一个由通信协议和社会协议组成的公共网络下共存。这在集中式体系结构和对等(或“分散”)体系结构之间占据了一种中间地带。联邦享有两者的优点，但缺点很少。

在联合软件系统中，用户组是围绕小型相邻的服务器实例构建的。这些服务器通常是小型服务器，仅需要适度的资源来支持其相应的有限用户群。至关重要的是，这些小型服务器使用标准协议相互通信，允许一个实例的用户与其他实例的用户无缝通信。您可以在您的实例上构建文化和共享认同感，还可以与其他实例联系并轻松连接。

然后，联邦系统的治理就会分布在多个操作员之间。每个实例都具有以下权限：

而且，因为有数百甚至数千个实例，用户可以选择他们喜欢其规则的实例，以及他们希望与其他实例进行对话的联合实例。这个系统还使得营销和垃圾邮件很难站稳脚跟-它优化了一个人与人交谈的自治系统，而不是让公司推销他们的产品。

扩大联盟的成本在这些运营商之间可管理地分配。服务器要求一般的小实例通常足够便宜，系统管理员可以轻松地自掏腰包支付费用。如果不是这样，通常很容易向用户募集捐款来维持运行。新的运算符一直都在出现，并且联盟对uPA的扩展稍微多一点。

与P2P系统不同，联合模型允许志愿系统管理员利用他们的技能将服务的访问扩展到非技术用户，而不会给那些非技术用户带来设置、理解、维护或保护服务器或深奥软件的负担。服务器也始终在线，并提供强大的身份和真实性保证-消除了整个类别的P2P问题。

ActivityPub是一种流行的新兴联邦协议，但它不是构建联邦系统的唯一方式。您肯定熟悉另一个不基于ActivityPub：Email的联盟。IRC和Matrix还在即时消息传递域中提供联合协议。就我个人而言，我不喜欢ActivityPub，但AP并不是获得联合的好处所必需的。许多不同类型的通信系统都可以用联邦INMIND来设计，并调整它们的方法以适应它们的特定需求，这在每个例子中都很明显。

简而言之，联盟分散了治理和成本，可以让我们解决没有联盟就无法克服的挑战。自由软件社区需要团结起来支持联邦，因为没有其他人会这样做。尽管有很多理由让它值得去做，但它对企业来说并不是有回报的。他们更愿意建造有围墙的花园，集中--这更有利可图！把控制权交到用户手中的民主软件是我们必须为自己夺取的东西。维瓦拉·费德里奇翁！

对我的一篇帖子有什么评论吗？通过发送电子邮件至~sircmpwn/[email protected][邮件列表礼仪]，在我的公共收件箱中开始讨论