Glad to see there’s still interest in this topic. I’ve made some progress on a prototype solution for public post federation using Pastry; I’ll update this thread when it’s ready for testing on real pods.
In case this needs more clarification: the local database for a pod, regardless of whether it’s a relational database or a key-value store (and hard experience taught the D* team that a key-value store is not the appropriate choice), is completely distinct from the DHT-based distributed network layer (Pastry, in this case) I’m proposing to use to implement federated public post features. This is a “third way” which avoids the type of naive network search that puts a large burden on the network, while also avoiding the need to introduce central hubs.
IMO central hubs would weaken D* by creating a dependency on special, well-connected, resource-intensive nodes, which would be too expensive for the average person to run. This would erode much of the benefit of a decentralized D* network; it would make it much less democratic, more susceptible to interference and obstruction. It would also be a less robust solution than distributing responsibility for doing federated processing across many/all D* pods.