Safe Network: Secure P2P app system implemented in Rust

Also, MaidSafe consistently shares a dev update every week Perhaps now's a great opportunity for you to read up on the current state of development. Here's the most recent update: https://safenetforum.org/t/safe-network-dev-update-april-30-...

IMO they are an outstanding team both technically and ethically. In fact it was the latter that got me interested in the project in 2014 and my impression then has been confirmed many times since.

I wish folk could discuss the project and it's goals. Incentivisation is part, but a really small part of the project. As soon as I see a cryptocurrency comment I just lose faith and have barely any energy to engage. Folk need to forget money/coins and so on and focus first on the function and vision. All you get talking cryptocurrency is "it's a scam", "it's a fraud", "somebody told me X and it was false". Then let's look at some price chart and so on. It is really just a distraction and the arguments have an infinite lifetime. When I see projects on github/lab who mention cryptocurrency way up front I also lose faith. An incentive should not be the vision or function, it's an incentive it should never be a core goal or technology.

It solves ownership of data, and removes the need for large data centers by securely, anonymously letting users share storage space.

I'd caveat that we're still in alpha, but things are coming together very nicely.

The Safe Network (will) incentive user storage and uptime through cryptocurrency, though non-blockchain based, so avoiding a lot of throughput pitfalls there. So it can also act as a storage backed currency in some fashion.

It allows users to truly own and manage the permissions of their data without relying on any third party. And it provides enough flexibility for this to let folk make applications as well as store files.

I hope that helps some? I'm trying to avoid buzzwords :) I know that site has any. It's also worth noting that the dev hub is a bit out of date (things are still moving pretty fast.) But the community (https://safenetforum.org/) is very friendly!

Let me know if I can get more specific, I'll be about for a little longer.

(Oh, also there's some other links in another top level post I made that may be helpful)

2. Is also a reasonable point to make, but the nature of the goals here means it has to do a lot more than just sit on top of the existing protocols. It's a secure, decentralised, autonomous network/platform, which needs to be built from the ground up in order to solve the many problems we have with the existing web.

I'm not sure what you mean by monolithic. The ideas are new and can take a while to grasp but it's worth it.

3. The community have had long discussions about this so many will agree with you. But the best response I've heard to this point was from Tim Berners-Lee when he and David Irvine were at the Decentralised Web Summit in 2018. Someone said something similar to your point 3 to David and Tim jumped in and answered that it wasn't necessary by saying: and what was the killer app when I invented the web? Or something along those lines.

I'm not dismissing your point and many of us aren trying to come up with ideas for such killer apps.

Personally I suspect we already have some - take a look at the SAFE fundamentals for example. But it may well be something nobody anticipated. It's fun thinking them up though :-)

On (1): keep an eye out in the dev updates on the forum for the Safe Network App, this will fit the bill for what you are describing. Although remember, the network isn't complete yet, but we are on the trajectory for launch, so a fully featured version of the Safe Network App is on that same timeline.

On (3), I see what you are getting at, and this has been discussed a lot over the years. I'd make the distinction that there are killer _features_ of the network which will blow up, and enable all manner of amazing individual apps to be built on top.

There are a lot of features to highlight in that regard, as it's such a multifaceted project, but one I've aimed to highlight in this YouTube video is the 'Perpetual Web' which will have some pretty big implications:

https://www.youtube.com/watch?v=_GJZYS7ZJYs

And then there are some other really cool aspects that get me personally very excited, such as the serverless, infrastructure free nature of it (from a web dev pov), the possibilities for it to be a middle-man free ecommerce platform, and that's not to mention the private communications strand too.

It's similar to IPFS in terms of the goal of distributed file storage. But it incentivizes users to store in non-blockchain way, sidestepping a lot of the size and throughput issues there.

Connections are indeed anonymized. But as you can work with and update data in a distributed fashion, there's a lot of scope for applications. (We've previously built a simple twitter clone, using RDF data on an older testnet: https://github.com/maidsafe/safe-patter-js)

Things are still very much in development. Still Alpha stage. But There are things available for users to try!

The Safe Primer (maintained by community members) may be a good place to start:

https://primer.safenetwork.org/

The dev hub is sadly out of date with current things. The forum is very friendly and open to new folk and answering any questions: https://safenetforum.org

The main network website has more generalised info: https://safenetwork.tech/

Hope that's helpful!

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.

Then malice, it's a different module/behavior and requires we either prove the code (SGX etc. which currently is a bit too early) or we add malice detection across the board. This means nodes must not only be on-line or accepting messages, they must not create invalid messages etc. and this is not to difficult to deect. Then add to that the hard detection which is did the node process and forward/reply correctly? This is hard and requires a syncronicity assumption. I belive many projects focus on async everything meaning a node can reply at any time in the future and this is a bit tricky if you have memebrship changes (look at swim etc. for gossip). So for us we make the sync assumtion and have moved to allow a period (of events) that nodes must message (vote etc.) correctly. Then we apply the message malice detection. So malice detection is system wide and a very large area of decentralised networks at this level.

- shut down safecoin.org,

- if not possible : change the name of their own coin and/or project to make it clear it is not related in any way with safecoin.org

- in any case : advertise this issue more largely and more clearly ?