Hope I can help.

1. Not 100% sure what you mean here. Our data goes via our self_encyption process. That chunks the data and stores it as immutable where the name == sha3 of content. This is self validatable data to us.

2. Small partitions are not a huge issue, but partitions that are long-lasting and over 60% or so are. This is not detailed yet, but all data is signed by a section chain. The section chain is the BLS aggregate of the section elders. All sections in the network have such a chain back to the genesis key/block. This allows data to be republished if necessary and really helps with partitions. This is allowed as data is signed by a valid network section key that is held in the section. However, transaction data is very different and we don't have a final conclusion there as theoretically one side would get consensus and the other does not. This seems to be a decent answer, but it can be much better. We are currently looking at some crdt types here, such as nonzero counters and so on, so that could allow transactions to happen on both partitions, but it's not trivial and we need to consider is partition permanent or even long enough that so many members change that quorum is lost. Again not the end of the world, but there is no final conclusion there just yet.

3. Our fundamental is all data is chunked and encrypted. So the data is encrypted by self-encryption (a take on convergent encryption), but perhaps easiest to think the user strongly encrypts data and only they have the key. Even public data is like this, but the passwords to decrypt are held by the user in a map that names each chunk with a created password (that comes from the data itself, not created by the network). For public data, chunks are still encrypted, but this data map is held in immutable state.

4. At the moment they are not sandboxed, this should not be the case on launch.

5. CRDT is what all data on the network should follow, this is being formalised more right now and we hope to see more containers in rust-crdt as well as a bft-crdt extension to this. It's an area we are currently looking to provide and it's coming along well.

6. Requests are signed by the client (we use BLS there to allow multisig). Network node events are signed by the p2p nodes (ED25519 there). Network agreed events (consensused) are BLS aggregate signed.

7. No, not at this time.

8. I worked in large scale network design from the 90's and hated novel/NT etc. as they we way to complex and for small companies horrendous. I created a project called eboxit, an all in1 linux intranet/internet box in 1996 but could not fund it. I realised during that process that these boxes could collaboratively back each other up if they used encryption etc. I then realised it was mental to do that and folks computers could collaborate to create a server like device. Then I realised it was not novell/NT etc. at fault, it was any server and any centralised and controlled by humans system that was at fault. Then 2002-2006 I worked on some form of a first step, little did I know how involved it would be or how difficult funding and building teams from the West coast of Scotland would be. However now OSS has really moved on and with a community it's easier to attract great Engineers. Not geniuses or the best in the world, but the comitted to the vision, just get it done Engineers. That agreed vision make them the best in the world for this specific project ;-)

8 We share that and more. I also believe that AI/neuroevolution/SGD etc. will make huge strides soon and do so with a bang. I am desperate to get time on that, but SAFE is needed first, either this project or another that frees and secures the worlds people to learn, create and communicate without any loss of privacy.

Oh yea, grit, determination and sacrifice are so important. Especially when we got into crypto (btc etc.) as this brought huge amounts of people, but also scammers and folk calling fraud, scam etc. That takes a personal toll when you have already given so much, but the project is important so the price has to be paid.

user:	dirvine
created:	August 22, 2013
karma:	5