先从profile功能说起

虽然Commit 7953190提交上去了，也初步实现了user profile的展示。看上去代码也不是很多，逻辑也不复杂，但是这段补丁其实通过了开发组内多次重构与推敲才最终写出来的。




此user profile页面构想最初由xiwalng提出，xiwalng说缺一个展示个人信息界面，打算写出初稿。但是xiwalng写了一半就跑了，说“无法直接select+order by直接拉出用户topic+post展示个人信息，系统没有sql数据库太难写”。

后来由bitsmaker接着写了一部分，称现有组件功能太少，想要“多打几个洞”，最后由于一致性以及复用性要求。并未“多打几个洞”。但是bitsmaker指出现行用户唯一id定位模糊，xiwalng原来是打算使用32byte公钥，但是业务有大量使用域名当标识。而部分场景使用的又是mainkey的摘要。也就是说，现在有三套用户身份识别体系。

---

混乱的用户ID体系

由于最初开发过于杂乱，事实上大量模块都是由对这个功能感兴趣的朋友写的，大家围绕一个大致目标构建起来。由于实际设计与当初留下了的rfc格式协议说明偏差较大，基本上开发都变成了大家的自由发挥。

对于什么是“唯一用户id”，不同人有不同理解，有人认为是域名，有人认为是mainkey，还有人认为摘要相同就行。。。就这样，对核心理解设计完全不同的模块，就这样组装起来了，最后竟然还跑了几个月都未出现任何问题。也许是现在网络较新，大家都未更换过域名或者公钥，导致此bug一直未发现。

---

开发的排查与反思

虽然profile功能最后在大家的群策群力下最终写出来了，感谢huaxiong承担主要的前端开发，虽然huaxiong不想再碰个人信息模块的后端逻辑，但依然完善了前端。

虽然前期大家各自理解造成的偏差，造成了现在最核心的用户ID标识如此不统一。但是也感谢所有添砖加瓦的开发者来到这里共建。

---

后期的打算

profile功能无意间掀出了一个无人注意的基本问题

经过几天的开发组内的讨论后，决定以主公钥mainkey为唯一ID标识，域名只是验证公钥有效性的辅助。但是由于唯一ID标识的改动或许涉及核心逻辑。加上很多开发者都是由于兴趣前来，写一段功能就离开了。

加上先整理以及规划与改动，可能需要1-2个月才能彻底完成，由于“唯一ID标识”这个功能，不但涉及webui，更涉及核心模块kep-edge。往常的大多数更新，都是更新webui，而消息交换核心kep-edge并不受此影响。因此热更新也不会造成消息丢失。


此次更新设计消息交换核心，也许有概率导致发的帖子出现丢失，因此最近1-2个月大家先忍一下，尽可能减少在kepdb（即stalltrix官方节点）上发帖，可在自己的私有节点上发帖。避免重要帖子的丢失。

---

后记

即使内部流程再怎么修改，也会保证数据历史兼容性，以及对外导出模块ABI完全不变。因此不必担心出现类似其他软件的“大版本更新”之类的断档行为。后续版本也依然会保证与最初的v0.1.0版本的向前兼容。




可能最近这里表面上看上去会暂时清闲一段时间，并不是离大家而去了，消息交换核心无法热更新，为了避免体验到bug影响心情。大家最近先减少下发帖吧。即使发帖也本地备份一份。避免丢失。

不能发帖了吗？

只要病不被发现，那就是没病。把提出问题的解决掉。就没有这个bug了

@下耕(yw6qcv) 不是不能，而是自行承担丢失风险。最近一两个月可能不稳定

好吧，我先等几个月再来看看

为了避免再次发生之前service-worker类似的后期积累事故，开发组内讨论后决定不再边跑边更新。大家见谅一下

就喜欢来逛这里，能见识到到很多开发内部的见识，其他很多对方都是做贼一样的更新，要么不发公告，必须写的就写“修复已知问题”

以后把kep edge也加一个热更新吧，跑双核+故障回退

各位朋友，我们两个月后见了。

@gege(lbmy6w) 不得不说，很多软件内部确实是这种，哈哈

之前有人改登录界面的时候，没发现这个问题吗？

写很长内容的话，丢失确实对心情的打击比较大

@cpwin(qcox3k) 因为登录只改了前端，后端API还是复用的

等段时间没事，不过有没有人建一个群进去吹吹水？

好久没来看了，一来就看到这件事。。开发群的消息太多了不想看

不过说实话，更新这玩意很难吗，还需要2个月？，不是最多一星期就能搞定吧。改一下验证字段名不就解决了？

@nobody(vd3tmz) 不是那么容易吧？底层ID标识系统涉及主键，更改系统主键牵动的下游调用逻辑分支影响范围过大。工程量大没有办法

@ouplan(hxod2d) 谁叫你tm的去改主键ID的，为了方便类sql索引？以适应profile显示？

现在残缺的摘要验证与domain本来就是双主键ID，索引直接Map映射下旧虚主键到新实主键，实际的验证逻辑使用实主键。而索引使用虚主键ID定位+实主键确认。

本质上就这么简单你们开发群里还能讨论出几天，搞出五百多条对话？

@nobody(vd3tmz) 这种要一直维护Map状态吧，随着用户数的增多，Map必须记录的key映射会越来越大，到后期会是一个不小的包袱。

而原生主键key是无状态的能直接索引与使用。随着后期项目逐渐复杂化，原生主键key的简洁易用优势就容易体现出来




如果使用这种Map设计，以后应该会出现不少历史包袱

@ouplan(hxod2d) 我真想骂人了，你没仔细读我的话就开始乱猜，谁叫用外置Map来持续映射的

现有struct添加一个结构体记录mainkey[32]，这样就直接变为现成内置key了，没必要用一个外置Map来记录。而新数据写入的时候mainkey[32]同步写入

既然没有使用sql，何必追求sql的有序关系性结构？

@nobody(vd3tmz) 既然noman大佬有简洁优雅的方法，我也想学学大佬的神笔。解决方法大家讨论的真是太复杂了，或许真是当局者迷吧？

@nobody(vd3tmz) 没问题，先写出来能跑，没有bug，符合要求（尽可能复用已有组件，不引入外部组件）就能合并主线成为事实标准。

反正我们这里本来就是草根开发者社区，没必要被“正统规矩”自缚手脚。

@skymmap(ev3tup) 如果其他版本先写出来先上了，我们这种大版本重构岂不是白写了吗

这种就当分支预测失败，流水线被清空了吧😄

@ouplan(hxod2d) 很多时候虽然代码无法复用，但是抽象出来的逻辑却可以复用。如果代码本身无法抽象出好的逻辑，无非就证明了写这代码本身就如同电子搬砖一样的工作

@hua(gk2s6c) 听起来就像数字农民工啊，让我想起“码农”这词

@ouplan(hxod2d) 不一定不能合并，以前开发初期很多冲突都能想办法移植适配合并了。

楼上说的也没错，抽象出需要的组件合并进去。也能使代码以另一种形式存在。

@ouplan(hxod2d) 你想开点，很多产品花了1-2年打磨，结果被别人1-2月覆盖相同需求的产品超了。这种不也没有办法吧。

没有什么理所当然的标准，无非就是用的人多了就成了标准。