为什么Diaspora不支持ActivityPub（2019）

快速浏览后，“话语”线程不会清楚列出任何内容。 @denschub介意在这里收录他们吗？

人们要求tl是很常见的，但是没有。您不能用两句话来解释这个世界，也不会在这里发生。这篇文章是一个起点，但您已经知道这一点。这是另一面文字墙，用不同的单词解释同一问题，希望使问题更清楚。不，不tl; dr。

ActivityPub，如果有的话，是一种传输协议，对应用程序/表示层不负责。 ActivityStreams将对此负责。一般来说，ActivityStreams Vocab描述了可以与其他功能一起完成的一组操作。更具体地说，AS描述了[应用程序，组，组织，人，服务]可以[接受，添加，宣布，到达，阻止，创建，删除，不喜欢，标记，跟随，忽略，邀请，加入，离开，喜欢，收听，移动，提供，提问，阅读，拒绝，删除，TentativeAccept，TentativeReject，旅行，撤消，更新，查看]一个或多个[文章，音频，文档，事件，图像，注释，页面，位置，配置文件，关系，墓碑，视频]。

对于每种对象类型，AS描述每个对象可能具有的一组属性。完美的rfc2119可能就在那里，所有内容都是完全可选的。每个对象都没有真正需要的属性集（除了标识符），因此每个人都在猜测接收对象时要做什么。更有趣的是，如果您对AS为您定义的属性不满意，不用担心，您可以高兴地提出自己的东西：

在Activity Streams 2.0中，扩展名＆＃34;是“活动词汇表”未定义的任何属性，活动，参与者或对象类型。遇到不熟悉的扩展的消费实现绝不能停止处理或发出错误信号，并且必须继续处理项目，就好像这些属性不存在一样。

AP / AS不仅不能提供存在一组特定属性的任何保证，而且还可以存在任何其他可以想象得到的属性，并且通过设计是一种功能，将其举起手臂并像接收时没有属性就可以了。

我在这里很认真：我们应该如何基于此构建对用户有用的东西？从纯实施者的角度来看，AP / AS几乎就像提出了一个协议，该协议规定您可以通过电子邮件发送XML文件。我们并不是真的想告诉您这些XML文件中的内容，但是无论如何您都必须对其进行解析，并且必须以自己理解的方式行事。你们中的一些人称赞它为功能，实际上对实现很不利。您不能将无限量的可扩展性投入到机器对机器的通信协议中，并希望事情能够可靠地进行。

我很清楚，实施AP是一件很想做的事，每个人都在新添加AP支持的情况下写下豪华的新闻公告。很好，对他们有好处，但是我在我的职业生涯中花费了大量时间在Web浏览器和Web标准上工作（您知道，即使是一小部分的灵活性/歧义性也可能导致最糟糕的结果），我非常想将我的头撞在墙上，问自己为什么这个世界没有学到任何东西。是的，这么多项目可以声称支持AP真是太好了，但我真的很奇怪，为什么没有人似乎在考虑它的真正含义。

让我们稍微远离散居*，因为这根本与散居*无关。你认识JetLovers吗？好的，不用担心，我没想到您会：它基本上是一个社交网络，适合那些在飞机上花费过多时间的人。您基本上可以共享当前所在的机场（和计划的路线），并可以与刚好在同一机场甚至同一架飞机上的同事/朋友/ ...联系。我知道这个概念对你们大多数人来说听起来很奇怪，但是它很好地说明了这一点。 JetLovers可以实施AP。为此，他们可能会以“个人创建地点”的形式发送状态更新，因为这很有意义，对吧？

因此，Alice在Jetlovers上，而Bob在使用Mastodon。爱丽丝知道这两种服务都在使用ActivityPub，因为它们都声称写了精美的公告博客文章。因此，爱丽丝将鲍勃添加到她在JetLovers上的联系人中。

现在。怎么了？ Bob会看到Alice's Place的更新吗？ Mastodon不支持共享位置，那么如果他们共享一个位置会怎样？它们是否以文本形式显示GPS坐标？他们只是放下它吗？ NextCloud上的联系人同时支持AP的Carol会怎样？

我实际上并不在乎答案是什么。这是我要问的一个完全有效的问题，这是主要问题。这两个项目都支持ActivityPub，但这仅是笼统的术语，或者表示项目正在使用框架。对于用户而言，这毫无意义。支持ActivityPub对人们来说是一件很美的事情，使他们能够自吹自claim，声称他们致力于＆＃34;去中心化社交网络相互连接。＆＃34;在一定程度上，这实际上是对的：他们将书呆子彼此联系起来。就是这样。

我听到了实施AP的人们的恐怖故事，向我介绍了他们的解决方法，但仍然声称AP可以正常工作。这样的东西，哦，是的，如果我们由于不知道对象而无法显示该对象，那么我们只需链接到原始项目即可。＆＃34;是的，好像这是一个可行的解决方案。当然，您在GitHub上的人们单击该链接，就可以轻松地在远程pod上使用该项目，然后回到自己的实例，并找到一种方法可以对此进行评论/赞/不管。认为这是一种对用户有用的解决方案是天真的想法。用户将单击链接，阅读文章，搜索链接按钮或评论字段，甚至可能找到将其重定向到该远程节点的登录表单的内容……无论发生什么情况，他们都会感到困惑，再也不会回来再次因为这个东西令人困惑。

如果爱丽丝了解技术背景，则可以解释这些限制。但是，如果爱丽丝不是软件工程师，而是经常出差销售重型机械的女商人，会发生什么？ Alice不在乎您是实施标准的绝妙项目，并且这两种实施方式都是完全有效的ActivityPub节点。她只是意识到，由于某种原因，Bob看不到她的飞行计划更新，而她的纯文本更新才可见-此时，首先使用该服务没有任何目的，所以她停止这样做。

我还没有找到一个能够直视我的人，并认真地声称这种情况比简单的爱丽丝更好，所以您无法与鲍勃交流。 ;

当前的作法似乎只是看Mastodon并复制它们的实现，因为这似乎是使某些东西起作用的唯一方法。但是，这与支持AP无关，而与支持AP的Mastodon方言及其子集有关。而散居移民*不会发生这种情况。虽然功能集和UX之间存在重叠，但是差异太多。

如果diaspora *曾经支持AP，那么它很可能以外部服务的形式出现，就像我们处理Twitter的交叉报道一样。而且，无论@HankG和其他人试图在此处重新组合单词有多困难，我所说的都是得到整个diaspora *核心团队（我已经多次验证）的认可：diaspora *使用AP作为其联盟。目前的形式，根本不会发生。对我们来说，构建一个东西并不是真正的思想上完美的项目，它支持所有最新的华丽规范，而是创建一个对用户有用的东西。在这里，我们可以选择两种可能的情况：

实施AP，并使自己处于一个位置，我们必须解释为什么有时通信仍然可以正常工作，但是在某些端点上可能无法正常工作，民意调查将永远不会到来，人们可能无法向您发送可识别的私人消息，但＃39;只会显示为有限的帖子，哦，当与某些端点交谈时，地理位置标记始终会丢失。

没有实施AP，能够明确地说“不能，您不能与X进行通信”，但是您可以确定，如果存在某种形式的通信，它可以可靠地工作，并且我们相对可以肯定，没有内容被压扁，丢失或以其他方式转换。＆＃34;

对我们来说，选择1根本行不通。纯粹出于意识形态原因牺牲了UX。对于非技术人员而言，它使分布式社交网络更加混乱，这绝对不是我们所需要的。归根结底，我们已经在建立一致的用户体验方面做得很糟糕，我绝对不明白为什么人们乐于让情况变得更糟。