It's true: I've had trouble determining what exactly your point is, as you seem to think you know more about FaunaDB's architecture than you do.
You're under the mistaken impression that we have the same data/log architecture as described in the Calvin paper, which requires that every host talk with every other host. That is not true of FaunaDB.
What you describe is a very important distinction from Calvin, as this mechanism for deriving a global log is core to its design. Have you published this new approach in any public venue?
If not, we’re now in an unfortunate situation where neither your practical nor theoretical capabilities are public knowledge.
> every host talk with every other host
Only every shard
> you seem to think you know more about FaunaDB's architecture than you do
You are perhaps being uncharitable. The only public statements I am aware of about Fauna's capabilities relate to its Calvin heritage. I have only been asking if my understanding is correct regarding both Calvin and its application to Fauna. However, none of the prior issues you responded to were problems with the original Calvin paper either, at least by my reading.
> What you describe is a very important distinction from Calvin, as this mechanism for deriving a global log is core to its design.
The salient aspect of the paper is how it derives the log logically, not how that is mechanically implemented in a real system outside of academia.
> However, none of the prior issues you responded to were problems with the original Calvin paper either, at least by my reading.
I wasn't clear what exactly you do (or don't) know of the architecture which would lead you to believe this NxN messaging story, as that relates directly to your contention regarding the scalability (or not) of the architecture. That much is clear to me now.
You're under the mistaken impression that we have the same data/log architecture as described in the Calvin paper, which requires that every host talk with every other host. That is not true of FaunaDB.