1. The "Factom Federated Servers": Are they somehow centralized? Can I run a Factom node? Is there a process involved in joining the Federation? .
Like in bitcoin, there will be different classes of nodes all communicating over a flood fill P2P network. Yes, you can install a node and propagate messages around the network. I think the question you are asking is "Can I run an authoritative node?" as in, can I be a miner. That is a more complicated question. You would basically need to win elections to become part of the federation. Users who purchase entry credits are the ones who cast votes. This is what Milestone 3 is for.
2. If Factoms are like ETH and EC's (Entry Credits) are gas, could an Ethereum dapp serve as a potentially more decentralized Factom?
hmm, interesting question. My first reaction is: probably not. The Ethereum VM is really slow, described as "the computing power of a 1990's mobile phone". There will be a lot of data flowing through factom, and I don't immediately see how all the data can be put into factom, and not into ethereum's state too. The whole point of factom is to offload data from the main blockchain.
Perhaps with something like zk-SNARK, you can put the proof of honest dealing in ethereum, but the proof would need to extend all the way down to the network card firmware to prove you weren't filtering, and would take 10000x longer than just doing the computation once. Even then, you could probably filter (censor) before it got to your machine. The goal is to make it censorship resistant, which is really hard. The best we know how to do is make it expensive to censor.
I haven't though about redesigning factom as an Eth program very hard, but I would love to be proven wrong.
3. There is a Factom chain. If this chain is lost or the network should die is the data on the BTC chain still "useful"? Or to put it differently, does the data stored on the BTC chain make sense without reference to the data stored on the Factom chain?
Bitcoin is used in Factom to do multiple things.
- Prevent Factom from undetectably rewriting history. The hashpower prevents the Federated servers from erasing history.
- Show the users of Factom that the blockchain is not forked. It also provides a sibyl resistant communication amongst Federated servers, and to the clients.
All the user Chains in Factom are under the Merkle root placed in the bitcoin blockchain. I think you are referring to the Factom blockchain, though.
The Federated Servers (like the miners) are only there to build the head of the blockchain, and to arbitrate between conflicting state changes. The only state changes that the Factom servers arbitrate between relate to Factoids and Entry Credits. After the blockchain is built, anyone can pass it around, verify it, and retain it even if the Federated Servers disappear.
This is one of the reasons why it makes sense to run your own node, to make sure you have a copy of all the data.
4. Quote from 'Factom Ledger by Consensus':
Quote
Placing Offensive or Illegal Entries into Factom
Censorship is very hard and perhaps nearly impossible in Factom. No data in the Directory Blocks, nor the Entry Blocks will be plain text. The Entries themselves can contain any information at all, but Entries containing offensive material can be identified and removed from any particular system using Factom. Even though Factom secures such information, that does not mean users are forced to hold the offensive material.
So this might mean that the answer to 3 is No, but more importantly how can information be deleted and who decides what is deleted? If Factom is not censorship-resistant then this poses a problem.
Good question. Again, it is complicated, and likely is a nomenclature issue. This is the equivalent of saying something can be deleted from bittorrent. Also, pruning in Bitcoin is a good analogy. If you know about some data on your system that you don't want to retain or serve up, you can delete it from your system.
Factom's (and blockchains in general) power is in proving the negative. If a community agrees on the head of the blockchain, then they agree on the history taken to get there. Everyone can examine the same history to arrive at the same state. The problem is that forbidden knowledge may be embedded in that history. The assumption is that this forbidden knowledge doesn't change the application state, but needs to be examined by new entrants to prove it does not affect the state.
It turns into an oracle problem at this point.
One can imagine an oracle, for example the Illegal Prime Number Detection Censorship Authority (IPNDCA) who scans the blockchain for the forbidden prime numbers. When they find the forbidden data, they would identify it by its Entry Hash and place that into their own Chain.
If IPNDCA flags innocuous data, others in the community can present the data and the signed hash showing it was flagged and the oracle would lose credibility.
If the forbidden data does affect the state, then the oracle probably needs to be aware of this, and communicate this appropriately.
What is more likely is that the forbidden data is there but ignored, like how some forbidden data exists in the Bitcoin blockchain, but doesn't seem to be causing legal troubles.
