Plancast 并不算早，它需要具备合适基材和网格的智能体

2012 年，我为 Plancast 写了一篇事后剖析，这是我花了三年时间创办的一家初创公司。前提很简单：人们制定计划，计划值得分享，而您信任的人提供的即将发生的事件会显示您不知道自己想做的事情。它不起作用。这篇文章讲述了原因。

十二年后重读这本书，表面的诊断仍然成立。制定计划的频率太低，无法维持每日的进食习惯。与分享照片相比，分享未来计划会产生较弱的虚荣循环。计划会过期，因此任何单一内容都有数小时的保质期。大多数计划都是本地的，因此大多数网络的计划在大多数情况下都是无关紧要的。最深层的问题是：人们不想在周围了解他们没有亲自受邀参加的活动。没有邀请的意识感觉就像被排斥。大多数人也不想与整个网络共享每个计划。错误的人可能会出现，或者房间不再感觉可控。

2012 年我错过的是，这些都不是真正的产品机械问题。它们是基材问题。当时可用的基质，即集中式社交网络内的提要，对于它们中的任何一个来说都是错误的形状。我尝试围绕具有特征的基板进行工程设计。从每个指标来看，底层仍然是一个很低的上限。

到底出了什么问题

对于计划共享来说，提要是错误的原语，因为：

feed 假设内容有稳定的流。计划不会如流水般到来。
馈送奖励广播。计划需要针对受众。
一个提要具有一个折叠功能。 Plancast 按活动日期选择“最早的优先”，社交源按发布时间选择“最新的优先”。无论哪种方式，它都是一种按时间顺序排列的排序。计划受益于许多查询功能，而有用的功能（您的信任图表中的谁要去、本周四适合什么、谁在城里）根本很少按时间顺序排序。
提要使关注您的每个人都可以看到每一条内容。计划需要范围。
feed 将消费视为面向用户的表面。计划需要与其他系统（日历、RSVP、交通、天气）组合。
Feed 集中调解。计划本质上是人与人之间的事。

一旦这份清单摆在桌面上，我在 2012 年提到的每一次 Plancast 故障都是下游症状。底层无法表达计划共享的实际意图。

我需要的基材

我现在构建的基板有两块，在 2012 年都没有可用的形式。

个人 AI 代理的持久、仅附加状态。 这就是我正在构建的 Neotoma。代理所做的每一次观察（添加联系人、回复事件、发出邀请、确认出席）都会成为具有出处、模式约束和不可变历史记录的类型化实体。用户自己的人工智能代理从中读取和写入。没有集中的社交图谱。用户拥有国家。

**地址簿和信任范围的主权网格。**这就是 Darkmesh（我的 Anand Iyer 的原始分支）的用途。 Darkmesh 允许一个人在明确同意的情况下将其上下文的可寻址切片（特定联系人、特定组、特定范围）发布到其他人的网格节点。同意是在网络边缘进行的。除非接收者的网格节点已承认发送者的范围，否则发送者的代理无法将消息放入接收者的状态。

个人人工智能代理通过网络相互交谈。声明他们关心每个用户自己的 Neotoma 的持久生活。没有中央服务器保存每个人的计划。

最初的任务如何变得容易处理

Plancast 最初的宣传是：出于对计划的共同认识而进行的偶然聚会。错误在于认为共享意识必须来自提要。

在这种新的基材上，相同的音高分解为不同的工作。

事件摄取是自动的。 我的代理已经知道我在 Luma 上回复的事件、我日历上的事件、来自 Eventbrite 或 Meetup 的确认电子邮件中的事件。它将它们作为具有出处的“事件”实体写入我的 Neotoma。我从来没有在任何地方输入过它们。
共享是经过同意和处理的。 当我回复某些内容时，我的代理可以标记应该知道我要去的范围。这些不是提要帖子。它们针对的是通过网格传播的观察结果，仅到达其节点已承认我的范围的人。
发现是一个查询，而不是一个提要。 “我的世界中正在发生的事情”的最自然的表面不是流。这是我问我自己的经纪人的问题。 我的信任网络中的谁将在接下来的两周内去往何处。这些活动中哪一个适合我这个星期四的晚上。谁在我一年没见过的城里。 每个查询都是在检索时通过我的 Neotoma 加上我的网格已承认的任何范围来计算的。没有饲料。
邀请是一流的。 这是2012年作品坚持的部分，也是大多数产品尝试都跳过的部分。

邀请实际上应该如何运作

Plancast 确实有明确的邀请，但它们是手动的。他们位于您的订阅者已经可以看到的计划之上。饲料仍然是第一个表面。标记您的标签、提及或元数据具有相同的形状：首先是环境可见性，其次是个人点击。真正的邀请应该颠倒这个顺序。

在此基底中，邀请是接收者自己的状态的键入实体。大致：

邀请函
  发件人：contact_id
  收件人：contact_id
  事件参考：事件 ID
  范围：“1:1” | “小团体”| “co_attending_set”
  note_to_recipient: 字符串（强制，非空）
  关系_basis：字符串（为什么这个人，为什么这个事件）
  slot_budget_used：整数（每个事件预算）
  expires_at：时间戳
  Conditional_on：可选的仲裁谓词
  出处：代理/来源/时间戳

从这个形状可以得出一些结论。

如果网格未承认发送者的范围，则底层拒绝传送。 这会以机器速度在唯一可以杀死它们的层：网络边缘杀死冷质量邀请。

每个活动的邀请预算强制进行选择性。 每个活动都有少量、可配置的邀请时段供发送者使用。强制执行“不要用软管攻击你的地址簿”的是基质，而不是意志力。 2012年虚荣心与选择性的张力成为一个底线参数。

**预先许可拉动是主要模式。**当我的代理运行其常设查询时，它只会看到其自己的代理将我标记为他们在该特定活动中欢迎的人。 “我的网络中的谁要去”和“谁会欢迎我在那里”的交集比“我的网络中的谁发布”要小得多。它不是饲料。它是一个权限门控索引。

个人上下文在类型级别是强制性的。 note_to_recipient 和 relationship_basis 是必填字段。空不是有效状态。我的代理可以从我的 Neotoma 图中起草它们（最后重叠、共享上下文、共同联系人），但人工确认的线路是默认的。这就是 2012 年那篇文章所指出的，它坚持认为人们希望感受到亲自受到邀请。基材使个人笔记成为结构性要求，而不是可选的礼貌。

**拒绝是无声的且未归因。**收件人回复“接受”、“通过”或“铅笔”。只有“接受”对发送者可见。 pass 解析为“无应答”，没有已读回执，也没有任何原因。接收者保留私人出处。您可以在不暴露的情况下审核自己的社交负荷。

Quorum 是一流的原语。 2012 年的一篇文章将拖延称为最大的失败：人们保留选择并拒绝提前提交。底物直接用“conditional_on”解决这个问题：“如果 Aaron 和 Diwaker 也承诺，我会去 X。”底层观察谓词并解析它。没有协调员角色，没有群聊线程，没有碎片。

与现有事件图的可组合性。 当接受邀请时，代理会进入拥有规范 RSVP（Luma、Eventbrite、日历）的平台并写入实际预订。 Neotoma“attendance_commitment”实体对于谁信任谁去哪里保持规范。第三方回复对于场地和门口保持规范。两条记录，每个问题一个事实来源，相互关联。

代理实际上正在决定什么

仅当代理在本地执行重要工作时，上述系统才有效。这两个问题在循环的两个方向上都是具体的。

出站，谁会欢迎这个计划。 当我的代理看到我回复了某件事时，它会针对该事件对我的联系人进行评分，而不是针对我。有用的本地信号：

其 Neotoma 与此人有共同话题或共同参加活动的联系人，
去年我曾经历过类似事情的联系人，
明确选择加入某个类别的联系人（向我举报有关该城市的现场音乐的信息），
自己观察到的日程或位置与事件窗口重叠的联系人。

该代理会生成一个排名候选列表，而不是自动触发。时段预算由我花费或经过我的确认，并且“relationship_basis”字段是根据相同的评分填充的，因此我可以在发送之前了解为什么推荐一个人。

入站，哪些通过网格的计划值得呈现。 我的代理针对传入邀请和我的范围承认的环境出勤观察运行对称查询。本地信号：

我最近与相关人员一起参加活动的频率和频率，
该主题是否符合我一直关注的类别，
我自己的日历是否有空间，
我关心的法定人数是否正在形成。

大多数传入的 ping 都会被归档，而不是浮出水面。浮出水面的内容带有特工自己的简短段落，说明为什么是这个而不是其他。

这两个方向都很繁重，而且都停留在本地。没有中央排名。每个用户的代理都会根据用户拥有的状态进行计算，并且评分可由该用户检查。这就是使体验开始看起来像基础设施的原因，可以代表您行事，而无需成为平台。

观察到的关系如何演变

在提要中，关系图一旦形成就基本上是静态的。你关注别人，很少取消关注，其他一切都是平台为你解释的信号噪音。在这个基底中，图表是由观察形成的。

每一次打字都会轻微地改变一种关系。发送的邀请会将边缘向一个方向移动。接受邀请会让事情更进一步。两个座席记录的出勤重叠再次使情况进一步恶化。两个节点接触的录制对话、共享笔记或项目实体都会在两个接触之间的边缘留下观察结果，并带有出处和时间戳。

反之亦然。当什么都没有发生时，边缘会衰减。与您上周末看到的联系人相比，您一年内没有邀请、参加或写过的联系人是一种不同的优势。衰减不是删除。历史仍然存在，可供检索。但明天代理的相关性评分将使用最新的权重，因此一年的沉默会先损失可见性，然后再损失关系本身。

这以重要的方式颠倒了 feed 模型。提要使图表成为输入，使活动成为输出。该基底使活动成为输入，使图形成为输出。关系的演变是因为行为是结构化状态，而不是因为有人在 2014 年点击了一次“关注”，并且该平台从那时起就一直假装边缘仍然具有某种意义。

这不是什么

这并不是试图取代人工编写的邀请函。 Substrate 的作用是让手写邀请的发送成本更低、发送更有把握、更难被垃圾邮件发送。上面的每一层都旨在将体验推回到 2012 年我正确识别的实际社交货币：你信任的人特别想到你。基材无法制造这种想法。它可以拒绝提供替代品。

哪些内容仍然开放

有些事情我还没有很好的答案。

邀请预算应如何命名和更新。每个事件、每周、每个网格？与录取率挂钩？
当关系发生变化时，网格范围变化如何传播。在不破坏关系的情况下撤销范围会是什么样子？
当参与者运行不同的网格实现时的跨网格互操作。是否需要薄协议层？
当先前承认的发件人开始发送垃圾邮件时的滥用处理。谁来施加惩罚，是接收者的网格节点还是整个基板？
其规范 RSVP 位于付费墙或登录后面的活动的迁移故事。

这些都是真正的问题，但它们是在已经有效的基础之上的产品和协议问题。它们并不是建筑上的未知数。

为什么我现在写这篇文章

几周前，Oo Nwoye 在一篇关于智能体记忆的最近文章上发表了公开评论，并用大量的文字询问 Plancast 是否应该在人工智能时代复活。答案和上面的一样。最初的使命是对的。基材错误。基材现已存在。

我不认为答案是将 Plancast 重建为应用程序。答案是将邀请、出席和信任范围构建为主权个人状态层上的原语，让代理完成摄取和路由的工作，并让社交机制从邀请是对持久状态的类型写入而不是环境提要事件这一事实中显现出来。

如果您在附近已经建造或正在建造任何东西，我想谈谈。

要点