The docs suggest that a Tendermint-based Vochain and Ethereum mainnet can use IBC to communicate:

We can also use interchain communication in order to pass messages between blockchains and trigger certain actions.

However, this is a non-trivial task – if at all possible – for blockchains with probabilistic finality like Ethereum 1.x. https://cosmos.network/intro#probabilistic-finality-chains described how this can work for moving tokens around using escrow contracts. The given example implies a messaging delay of 20 minutes and has a very limited use case.

If this is still the way to go, I think we need to document more about how this communication could potentially look like.

At the end of each rendered page there's a note like this:

Last Updated: 8/5/2021, 8:36:13 AM

I was expecting this value to be the last time that particular page was updated, but that's not the case; as I'm seeing pages that haven't been updated in the previous week, yet the "Last Update" for those pages is today.

Maybe what's currently showing is the last time the entire docs was built? If that's the case, I think showing this value in each page can be confusing.

Some of the documents contain diagrams where a piece called "DVote" appears, like this https://docs.vocdoni.io/architecture/component-interaction.html#prior-to-voting

It seems that dvote is a legacy name that was commonly used to identify client libraries interfacing the vocdoni-node. As a newcomer this is confusing because I see a piece called DVote but the text doesn't make any reference to it and I need to figure out what that is.

I also sometimes have trouble distinguishing the definition between vocdoni node and vocdoni gateway. For example, we have the repository vocdoni-node but it contains code to run a gateway. Is a gateway a superset of a node? if so, maybe the repository should be vocdoni-gateway?

The process overview page https://docs.vocdoni.io/architecture/process-overview.html should be a summary of the whole voting process, without entering into details. The current page is still following the old approach, I think we should make it generic and describe the process with the different approaches that we support.

In https://github.com/vocdoni/docs/blob/master/src/architecture/protocol/anonymous-voting/zk-census-proof.md
The current proposal doesn't use an elliptic curve for public key, but there are mentions of pk.X and pk.Y:

the public key of the private key is inside a Hash, which is inside the Merkle Tree with the CensusRoot (key=Poseidon(pk.X, pk.Y), value=0)

https://raw.githubusercontent.com/vocdoni/docs/master/src/architecture/protocol/anonymous-voting/zk-census-proof-poseidon-merkletree-diagram.png

The documentation uses the word "claim" to refer to an entry in the census. This is used in the census service documentation and other parts where the census is mentioned. The meaning of the word "claim" is not defined in the documentation, and it's not clear to me what it means. Who is claiming something? Maybe this comes from the iden3 codebase where an identity is defined as a merkle tree of claims made by the identity?

In any case, I think it would be much clear to use a different name like: "entry" in the census.

the serial process flag is not explained in-depth. It should be described for users & integrators.

One main question (pointed out by @brickpop) is whether all process types are compatible with serial processes, or just multi-question. This should be defined.