start.txt · Last modified: 2019/07/15 23:17 by drirmbda | Approved (version: 29)

Welcome to the Independent SAFE Network Wiki

The SAFE Network project is vast and complex. While there are great resources available online for study, these resources still tend to be hard to locate and digest. The SAFE Network Forum contains many years-worth of great information but lacks concise and up-to-date summaries which would be convenient for newcomers to catch up.

The purpose of this wiki is to make the SAFE Network project more accessible. This is starting-out as a growing collection of personal notes of the editor trying to thoroughly understand the project, and is intended to evolve into an independent guide to SAFE Network.

All information here is unofficial. You are free to edit and contribute right here as you learn about MaidSafe and SAFE Network yourself. This Wiki fills gaps, referencing existing resources whenever possible. Opinions belong on the Safenet forum.

Before you can start editing your need to through automatic registration. This is needed to avoid spam. There are some rules to follow to keep this fun. The rules page also contains contact information, and legal notices.
Before reading this site you must accept that it is your responsibility to obtain expert judgment and advice before using any information from this site for your particular situation. You accept that you alone are responsible for any losses or damages resulting from using this website.
If you want to find out more about SAFE Network or start contributing, we want to be your guide. For specific topics look at the table on contents on the right. Otherwise pick a subsection based on the desired level of depth you are looking for.

The SAFE Network forum also has a start here page which you may want to have a look at.

Wherever you read MDSF, expand it to Maidsafe in your mind, and SFNW to SAFE Network. Feel free to edit the wiki.

Getting up to speed

(a document called SafeNetForDummies is available on Google docs but I lost the link to it)

Contribution ideas

(Marketing, improving documentation, and performing testing?)

Getting up to speed

  • A write-up of September 2017 can be found here.
  • The Documentation topic of September 2017 summarizes many concepts here.

Reading this wiki may one day provide an accurate technical introduction but we are only at the beginning. If you are in the process of trying to go beyond the basic level feel free to share your notes on this wiki.

Contribution ideas

(Testing and validation of code and concepts)

  • Become an ambassador in your region! discussion and pointers. Recognition on the SafeNetwork forum for your work may earn you an official SAFE Ambassador title. See Appendix section People for a list of SAFE Ambassadors.
  • Develop a DAPP prototype. A strong DAPP and developer ecosystem will be important for adoption and through adoption for stronger security.

Getting up to speed

  • Read all papers and patents (Appendix E)
  • Read all RFCs
  • Read all Documentation and Code
RFCs

MaidSafe requests input through a public RFC (Request For Comment) process. RFCs are accessible here on GitHub.

The list of RFCs by status can be found in that repository here.

MAIDSafe has internal “pre-RFC” documents on certain topics, which means that the published RFCs provide an incomplete picture of the status of technology development.

Rust Core Libraries Documentation
SAFE Web App
API Documentation

Contribution Ideas

MaidSafe has an RFC process and discussion takes place on the MAID Safe Forum. (Summaries of the issues and resolutions could be added here for each.)

Unsolved questions (still?)

Discussions

(participate in discussion of RFCs)

List of all RFC discussions

Cutting through marketing and hype, we are interested in which of the many good things SAFE Network will do for it's users will matter most to you. Understand what SAFE Network is really about, and why it's worth the wait.

Furthermore, understanding which features are at the core, and which are higher level or add-ons will help to focus development and create a stronger foundation made to last. The separation between core goals and non-core goals is unofficial, but an attempt to rank the importance of features.

The primary goal of SAFE Network is becoming completely autonomous; impossible to change, break or stop by any single entity or group of actors.

The first iteration of the SAFE Network will achieve the following core goals (discussion):

  1. de-centralize ownership of certain network functions so that they cannot be changed or disabled by any group of actors(*3)
    1. function: identity proofing
    2. function: access control
    3. function: communication
    4. function: information storage
  2. protect all information perpetually(*1) from unpermitted access, interception, tampering or deletion
  3. preserve stored information, and end-to-end communications, and global access to these perpetually(*1) and for free(*2)
  4. provide a digital medium of exchange
  • (*1) The meaning of perpetual is not clear yet. 30 years?
  • (*2) Free, except for the cost of broadband access and the user terminal.
  • (*3) That the threshold is to making changes is unclear yet. A majority?

A future iteration is expected to achieve the following additional goals

  1. function: computation

Trustless network, autonomous network, and de-centralized network may be very similar ways to express the same goal.

Open Questions
Open Questions

(List open questions here, along with links to forum discussion, until we find some answers.)

What is perpetual? What is the required size of group of actors to allow changes to the mechanisms of SAFE Network that guarantee the core goals?

Certain goals not included in the previous section, but on the roadmap, could be considered non-essential, or merely good-to-have. This is a list of such goals, and is subject to change:

Independent but important add-ons

  1. multiple identities
  2. de-centralized name resolution
  3. CLI interface and API

Convenient and promoting adoption

  1. SAFE Browser
  2. Language bindings

Nice to have but not as important

  1. RDF Format

Benefits will be the results of SAFE Network achieving its goals. Many individual benefits may not be unique to SAFE Network, but the combination of a large number of them might be.

Relevant to the user

  1. No censorship
  2. Perfect privacy
  3. Full control over own data
  4. No loss of data or access issues ever
  5. No loss of ability to communicate ever
  6. Always on; 100% availability
Cryptocurrency benefits relevant to users
  1. No transaction fees
  2. Anonymous and untraceable transactions
Open Questions

Does permanent availability of published data not contradict having full control over own data?

Relevant to the developer

  1. No need to implement and maintain reliable data storage
  2. No need to implement and maintain basic security measures
  3. No need to implement authentication
  4. Get paid for development of software
  5. Inherently scaling storage infrastructure

Relevant to technical progress

  1. Scalable immutable transaction ledger
  2. Scalable cryptocurrency (without a block chain)

Relevant to our planet

  1. Consensus at low power consumption
  2. Secure cryptocurrency at low power cost (in contrast to PoW)

Official Project Roadmap and a summary:

  • Alpha 2 - Live! - Interact with a network of MaidSafe vaults using SAFEBrowser - PUT limits apply, minimum forum membership level required. Data will not be carried forward to next releases.
    • Self-Authentication - logging into network without centralized permissioning
    • Self-Encryption - splitting files into chunks, hashing, encryption
    • Disjoint Sections - splitting (and combining/) sections based on network size
    • Message Relay - early iteration - messaging capability without signature verification
  • SAFE Fleming - Let's guess August 2019 - PARSEC, Node Ageing, Secure Messaging, and potentially (!) vaults at home and test SafeCoin.
  • SAFE Maxwell - Let's guess May 2020 - The scope is TBD but could include: test SafeCoin, wallet, vaults at home, farming, identity management, spam handling.

RFC Project Board Github

A good architecture of SAFE Network is incredibly important for long-term success. This section will be an attempt to give an accurate overview.

Layers 0-4 will provide the basis for communication, without modification. Internet/Routing (Layer 3) will be based on IPv4 and/or IPv6. Host-to-host Transport (Layer 4) will provide QUIC transport, which is based on UDP (a connection-less service). SAFE Network will not modify anything below and including Layer 3. SAFE Network will add to Layer 4, and functions in Layers 5, 6, and 7:

LAYER 7 - Application: Vaults, SAFE Browser, Authenticator, SDNS, (not sure about SFTP, SNTP, SIMAP) (tentatively placed here until verified)

LAYER 6 - Presentation: “Self-Encryption” (tentatively placed here until verified)

LAYER 5 - Session: Session ID and network entry point selection, Self-Authentication (tentative)

LAYER 4 - Routing: SAFE Network PARSEC Consensus, and Kademlia Distributed Hash Table-based Routing, using QUIC/UDP

Note on CRUST
Note on CRUST

CRUST will be replaced by QUIC (originally: Quick UDP Internet Connections), which relies on UDP/IP.

The SAFE Network is a virtual overlay network on the Internet, consisting of SAFE Network Nodes, which correspond to an instance of SAFE Network “Vault” software in the real world. Nodes are dynamically organized by the network as Vaults come, gain trust over time, and leave the network.

SAFE Network Address Space

SAFE Network Nodes exist in the virtual overlay network in a multi-dimensional space called the XOR Space. There is no correlation between geographical distance (or IP address distance) between physical nodes in the real world, and distance between the same nodes in XOR Space. This is the result of how Node IDs are allocated by the SAFE Network. People running a Vault have no control over this process, which is an important security feature.

In XOR space, the distance between Nodes is the XOR of the IDs of the two Nodes, which is read as an unsigned integer. Distance is used for routing in this space and for organizing Nodes into groups, as well as for allocating responsibilities over other entities in SAFE Network XOR space such as “Clients” and units of data (“Chunks”), which also have an ID using which distances to Nodes can be calculated in exactly the same way.

Clients need to connect to Nodes to access the SAFE Network and the appropriate node is decided based on distance. Chunks are managed by groups of Nodes, which are also determined by distance. Chunks of data derive their ID from a hash of the contents of the chunk.

  • Entities in XOR Space: Vault Nodes, Clients, Chunks (other?)
  • XOR Space addresses length: 256 bits

Organization of Objects and Entities

The XOR space is dynamically subdivided by a sectioning algorithm into a growing number of dis-joint XOR sub-spaces as the number of Nodes grows. The sub-spaces are called “Sections”. Nearby Sections of Nodes watch over each other, and within each Section a hierarchy of Nodes exists based on Age, which determines the level of trust, responsibility of a Node, and the power it has over other Nodes.

Sections run PARSEC consensus algorithms to make decisions, and sign decisions using a group signature so that neighboring Sections can verify them. Decisions (and events) are stored in Data Chains.

  • Algorithms: Sectioning, … (other TBD)
  • Section group size and split threshold: 8 (typical number which may be changed in the future)
  • Consensus threshold: 5 out of 8 (62.5% (of “quorum size”?))
  • Information held by Sections: Data Chains (of a Section, or a neighboring Section), Routing Table

Object and Entity Types

(open for review and contribution; may be incomplete or outdated, as of 2015)

  • Users accessing the network (clients)
    • Passports (ID linked to multiple sub-IDs)
      • Anonymous ID (MA-ID) - for anonymous network access
      • Public IDs (MP-ID) - for public network access
      • Share IDs (MS-ID) - can be associated with multiple Passports - for access to private shares
      • Proxy IDs (PM-ID) - for providing own resources
  • People providing resources to the network: vaults (farmers)
    • Vaults (instances of a vault node)
      • ClientManager vault persona - part of a group but independently relaying traffic between client and the correct DataManagers
      • DataManager vault persona - part of a group but independently forwarding requests to the correct DataHolders
      • DataHolderManager vault persona - part of a group but independently selecting and observing DataHolders
      • DataHolder vault persona - part of a group but independently judging validity of requests
      • (what is the 5th persona, or is the 5th not a persona but the client?)

(work in progress)

  • Storage of ALL information is in a network wide DHT
  • ALL nodes are connected to at least four neighbors
  • ALL inter-node communication is authenticated and encrypted (PKI)

3.4.1 IETF QUIC Introduction

QUIC (originally: Quick UDP Internet Connections), is a new Internet transport protocol that intends to replace TCP and TLS. It relies on UDP datagrams over IP. This is a good introduction. Standard IETF QUIC started as Google's QUIC or qQUIC but has significantly diverged and improved.

Multiplexing of multiple streams reduces the number of QUIC connections and handshakes and makes streams less sensitive to congestion and faster. Authentication and encryption are not delegated to a higher layer protocol like TLS resulting in higher speed and better security. A typical handshake takes only one round trip. However, UDP protocols are susceptible to reflection attacks and to avoid this the server can cryptographically confirm if requestor and destination are the same, at the expense of doubling the handshake duration.

There are some early adopter issues such as worse handling of NAT by the typical router designed with only TCP in mind. Second, connections are uniquely identified and tracked by connection ID because ports and even IP address of endpoints may change, which is a feature of QUIC. However, conventional routers may not be able to deliver the UDP packets correctly to the right end-point after such QUIC endpoint change. Finally, performance may suffer compared to TCP due to a general lack of off-loading capabilities of processing to OS or network interface hardware.

3.4.2 MDSF Lib quic-p2p

MaidSafe quic-p2p crate (0.2.0 docs,to do) is a library implementing QUIC using TLS 1.3.

Watch the master branch.

Notes

The library provides 2 connection types in P2P mode: Bi-directional and uni-directional.

Uni-directional type is used to force to prove a node's ability to accept incoming connections and create outgoing connections, which is a necessary requirement to be accepted as a network peer worker node.

The library provides 3 connection types of different identity certification levels:

  • Agreed CA certificates required
  • Private CA certificates allowed
  • No Identity certification required

The most recent 200 endpoints that are not behind NAT, and their certificates are cached and used for re-joining of nodes.

3.5.1 Kademlia Routing Introduction

Kademlia routing (it's just a name) was first proposed in a paper of 2002. A Kademlia route is a shortest sequence of nodes to query to locate a node with a given address, in a network of nodes with distributed routing tables. For a network with n node addresses the number of nodes to query is Order log(n).

Nodes build their individual routing tables from queries they receive during the routing process. Routing tables contain IP addresses and Port numbers for a limited number of certain other nodes. Communication between nodes during and after this process continues to be physically routed using conventional routing.

Nodes know exponentially less about nodes that are farther away, and are experts about nodes in their closest vicinity. Kademlia routes converge to an increasingly common route for each given destination address, as that destination is approached. This exponentially homing-in behavior from originating node towards given destination node is thanks to a special kind of mathematical distance that is used to decide which node to query next.

Kademlia's creators not only proposed an algorithm but also a “novel” distance metric, the XOR distance. It satisfies all requirements of a proper metric:

  1. Zero distance between two nodes always means that those nodes must be one and the same.
  2. Distances between two nodes are the same no matter which is the origin, and are always positive.
  3. The triangle inequality applies; for any three nodes there always is a distance between one pair that is equal or less than the sum of the distances between the two other possible pairs of nodes.

However, XOR distance is non-Euclidean, i.e. Euclid’s 5th “parallel” postulate does not hold. This results in some very interesting and hard to grasp properties:

  • Nodes observed from any particular node, all have a unique distance to that observing node.
  • Closeness (e.g. k-nearest nodes) is uni-directional or asymmetric, which means that a node n1 in the set of k-nearest nodes to node n0, does not need to be in the set of k-nearest nodes to n1.

This includes an answer explaining most of the above by @fraser in other better words. This is a long but useful write-up by @dirvine to help understand things better intuitively and pointing out many peculiarities of XOR distance. Finally there is this Medium post by MaidSafe on this topic.

Article of 2015 on Kademlia applications.

3.5.2 XOR Distance

The following table shows XOR distances in a 3-bit space, or 0..7, to help you grasp XOR distances better. Horizontally the table shows source node number, and the vertical axis is decimal increment to obtain the destination node number modulo 8. For example, distance from node 2 (on top), to node 4 (on skip 1 row), is 6.

The 2-nearest and 2-farthest distances are indicated to verify k-nearest relations. For example, note that the 2 closest nodes to n0 are {n1, n2}. The nearest two nodes to n1 are {n2, n0}. However, the nearest two nodes to n2 are {n3, n0}, where n1 is notably not included.

Source Node
xor 0 1 2 3 4 5 6 7
dist. 000 001 010 011 100 101 110 111
skip 0 [1] 3 [1] -7- [1] 3 [1] -7-
skip 1 [2] [2] -6- -6- [2] [2] -6- -6-
skip 2 3 5 -7- 5 3 5 -7- 5
skip 3 4 4 4 4 4 4 4 4
skip 4 5 -7- 5 3 5 -7- 5 3
skip 5 -6- -6- [2] [2] -6- -6- [2] [2]
skip 6 -7- [1] 3 [1] -7- [1] 3 [1]
  • In case of 3 bit address space, it is still possible to place the 8 possible decimal values (modulo 8) in decimal value order on a circle, and consistently read the relative distances off by measuring the distances along the circle.
  • In case of 4 bit address space, the circle representation works in most cases but the distance may be wrong by 1 unit of relative distance depending on node pair between which distance is measured. (Is there a parametric curve or surface that would still work? How many dimensions would one need?)

Post by @polpolrene. And Podcast on XOR by @fergish. Erick's page with some related information.

3.5.3 MDSF Lib routing

MaidSafe routing crate (0.37.0 docs, projects) implements “Kademlia-like” implementation of Distributed Hash Tables (DHT).

Watch the fleming branch.

3.6.1 Randomized Rumor Spreading

Randomized Rumor Spreading Karp et al. (FOCS 2000)

3.6.2 MDSF Lib safe_gossip

MaidSafe safe_gossip (0.1.0 docs, projects) implements Randomized Rumor Spreading.

3.7.1 Byzantine Agreement

PARSEC stands for Protocol for Asynchronous Reliable Secure and Efficient Consensus and is described in this whitepaper by MaidSafe.

3.7.2 MDSF parsec

MaidSafe parsec crate (0.5.0 docs, projects) is a library for reaching consensus on network events.

Watch the master branch.

3.8.1 MDSF application safe_vault

MaidSafe safe_vault crate (0.18.0 docs, projects) implements the SAFE Network node capable of data storage, publishing, sharing, (computation, and Safecoin transfers.)

Watch the master branch.

Notes
  • Entry: src/bin/safe_vault.rs.
  • Configuration: src/config_handler.rs
  • Vault instance: src/vault.rs - State(Elder/Adult);
In this section we will try to separate out and have a closer look at the mechanisms that will keep the SAFE Network working as intended. Each of these need to be checked for possible weaknesses that could lead to disastrous malicious attacks.

(work in progress - brainstorming phase. Note that it may not be meaningful to consider each of the items below prematurely, e.g. in the context of an alpha release.)

Data Integrity Guarantee

Node Integrity Guarantee

Protocol Integrity Guarantee

Data Availability Guarantee

Node Availability Guarantee

Data Confidentiality Guarantee

Node Anonymity Guarantee

User Anonymity Guarantee

User Identity and Access control Management IAM Security Guarantee

Access Console and App Security Guarantee

Unknowns due to lack of documentation

(this section is for listing potential gaps in documentation or changes since last review.)

(work in progress)

The following is based on a 2015 peer-reviewed paper. It may not reflect the current code, and the implementation at time of launch may differ from this too. However, it does provides a clear reference for discussion.

Distance in XOR space between entities plays a key role, see discussion elsewhere. Note that:

  • a client must be closest CM-Ps,
  • a data chunk must be closest to DH-Ps, DHM-Ps, and DM-Ps.
Maintaining Security of ClientManager vault Personas (CM-P)
  1. Four CM-Ps per Client
  2. Roles to be guaranteed (Primarily: maintain Client IP address anonymity)
    1. Identify 4 DM-Ps closest to a given key-value pair (data chunk)
    2. Forward request to the 4 DM-Ps
    3. Anonymize Client by protecting Client IP address information
Maintaining Security of DataManager vault Personas (DM-P)
  1. One DM-P per 4 DHM-Ps
  2. Roles to be guaranteed (Primary: data/DH-P availability (churn handling) andintegrity management)
    1. Validate request received from CM-Ps
      1. Check if CM-Ps are the nearest to the Client
    2. Select and maintain 4 random DH-Ps
    3. Determine nearest 4 DHM-Ps to each DH-P
    4. Maintain minimum level of data replication
Maintaining Security of DataHolderManager vault Personas (DHM-P)
  1. One DHM-P per DH-P
  2. Roles to be guaranteed (Primarily: monitoring DH-P availability and integrity, and maintain DH-P IP address anonymity)
    1. Validate requests received from DataManagers
    2. Observe their DH-P and report issues
      1. Maintain and check continued connectivity quickly
      2. Periodically perform PoR check of their DH-P
    3. Anonymize DH-P by protecting their IP address information
Maintaining Security of DataHolder vault Personas (DH-P)
  1. One DH-P per unique data chunk
  2. Roles to be guaranteed (Primarily: proof of resource)
    1. Validate requests received from DataHolderManagers
      1. Check if DHM-Ps are actually the nearest nodes to DH-P
      2. Confirm agreement among DHM-Ps about the request
    2. Store/retrieve key-value pairs (data chunk) as requested
    3. Provide Proof-of-Resource (PoR) to DataManagers (is this correct? or is it DataHolderManagers?)

(documentation of current and future plan would be nice)

Self-configuration process

SAFE Network will create a routed overlay network (OSI Layer 4) on top of an Internet of interconnected computing devices. All aspects from the overlay routing upwards should be de-centralized, consensus-based, and completely autonomous.

Self-Authentication

Self-Encryption

Maintaining the rules

Decentralized Consensus

All transactions or decisions are consented according to the rules of the network and recorded in a transaction ledger that acts as the ground truth to base future transactions on.

MaidSafe claims a world's first decentralized, asynchronous, Byzantine Fault Tolerant consensus mechanism that works in permission-less networks and that is open source.

PARSEC GitHub parsec repo

Incentive system to provide storage space

Open Items
Open Items
  • How to tweak and maintain code?
  • How to reboot SAFE Network to fix issues requiring it without losing data?
  • Decentralized Applications
One special mechanism regulating the network involves SafeCoin, a medium of exchange within the network, but with a reach well beyond it. This section is intended to consider this from an Economist's viewpoint.

SAFE Network will have a native cryptocurrency called SafeCoin, providing incentives to people to support the network with resources and applications, and charging network users for certain kinds of usage.

To raise funding for the project a token called MAID was created. MAID will be exchanged for SafeCoin at the launch of the SAFE Network.

(MAID creation to fund development)

(scenarios impacting the value of MAID at conversion to SafeCoin)

At this time it is expected that one MAID token will be exchanged for son SafeCoin.

Source: this, Project-Safe whitepaper April 2014(outdated??)

  • Pre-launch supply (MAID): 452 M (452,552,412 units)
  • Investor allocation: 226 M
  • Maximum supply: 678 M

5% of total supply [of 678M??] goes to early investor/family

5% of total supply [of 678M??] goes to dev team

(money supply, economic output, inflation)

  • SafeCoin will be almost infinitely divisible

5.3.1 SafeCoin supply

(following needs confirmation.) 4/2017, authoritative April 2017

  • Pre-launch supply (MAID): 452 M (452,552,412 units) - slightly* over 10% (10.5%) of total supply, available at day 1
  • Early investor allocation: 215 M - (about?) 5% of total supply available at day 1
  • Maximum supply: 4.3B (4,294,967,295; 2^32-1)

*) Slighyly more by a few million due to error at MAID sale. @neo

5.3.2 SafeCoin creation

(following needs confirmation.)

4/2017, authoritative April 2017,@neo

SafeCoin goes to

  • Farmers - Depending on supply of available but unused storage; the (instantaneous) farming rate.
  • Network maintenance - Every GET on average pays core devs 5% of farming rate
  • App developers - Every GET due to an App pays 10% of farming rate
  • PtP (Pay the Provider - under discussion) - Every GET for specific data could pay 10% of farming rate

Farming rate is explained in RFC-0012.

5.3.3 SafeCoin destruction

@polpolrene

SafeCoins are destroyed/consumed by the network at:

  • Account creation (address/ID)
  • Domain name purchase
  • PUT of data (immutable data will be much less expensive than mutable data)

What determines the exchange value of SafeCoin

Since SAFE Coin will regulate availability of (secure and perpetual decentralized) storage, it may be expected to be as stable as that commodity. However, speculation and application for predominantly other uses might change the situation significantly.

Dealing with MAID and SAFE Network tokens is much more complicated than dealing with cash. This should be a guide to make things easier.

What is MAID

MAID is a token that exists in the OMNI layer on the Bitcoin Blockchain.

What is SafeCoin

SafeCoin will be the native medium of exchange within SAFE Network, and is supposed to replace MAID at the time of launch of the network.

Warning: SafeCoin is NOT this.

Exchanges trading MAID

As a general rule, do not leave large amount of MAID (or any other coins) on an exchange.

  • HitBTC: MAID/BTC, MAID/ETH, MAID/USDT. Consider the high level of complaints on social media about losing access to funds. MaidSafe does seem to have some leverage over HitBTC and could help get issues resolved.

MAIDSafe decided to remove MAID from Bitker in July 2019.

Storing MAID offline

Storing large amounts on exchanges is not a good idea. However, before you create a paper BTC wallet and send MAID to it, read through the steps needed to send the MAID back from the paper wallet to an exchange and decide if is worth the trouble and the risks of making mistakes and of reduced liquidity.

Feb 2018 post

(what do you need to join.)

(how to start using apps.)

(how to start app software development)

(this will be the area of the tinkerers. How-to's, experiments, etc.)

Community SAFE Network
XOR Distance

A useful XOR distance calculator on the web. This is an example implementation in JS.

(deeper questions)

Perpetuity

(What does it mean to store information forever? What is forever? What is the scope of SAFE Network, and what will be needed to achieve true perpetual storage?)

A list of measures against which to measure “perpetuity”

Freedom

Equitable Access

Misuse of SafeNet

This section answers some questions that we could not easily find elsewhere. You can check the official FAQ for other questions.

Terminology

Clearnetwork : Refers to the Internet as we know it today, which is what SAFE Network will replace.

MaidSafe : “Massive Array of Internet Disks, Secure Access For Everyone”, the name of the entity leading the development of the SAFE Network.

MVP : Minimum Viable Product: As defined in 2016, not the final product with messaging and SafeCoin, but a working network for storage, that may not guarantee perpetual data storage yet as it would be un-paid. In 2019 the meaning has changed see here, and replaced by a concrete roadmap.

PARSEC : Protocol for Asynchronous, Reliable, Secure and Efficient Consensus: An open sourced library

SAFE Network : “Secure Access for Everyone Network”, the name of the new Internet.

(what has happened in the past 13 years?)

  • 2006: David Irvine's first plans of a SAFE Network
    • February 22, 2016: MaidSafe.net was founded
  • 2007: David completes a PoC in Python
  • 2008
  • 2009: Start of MaidSafeDHT and MaidsSafePD development, rewrite portions in C++
  • 2010: Founding of MaidSafe Foundation (and MaidSafe Inc.?) to protect technology from trolls and corporations
    • David donates all of his 80% share in the company - 50% to foundation, 30% to EBT(=?)
  • 2011
  • 2012: MaidSafeDHT replaced by RUDP (=?) and Routing
  • 2013: Vault code re-write from scratch completed and all libraries are open-sourced
  • 2014: Raising 8M$ of funding through MAID ICO
  • 2015
  • 2016
  • 2017: MAIDSafe team expanded to 30+ people; front and back-end teams
  • 2018: The PARSEC Milestone is completed
  • 2019

2014 MaidSafe "the story so far", 2018 post

Tidbits

  • Sigmoid x was a company that was later folded into MaidSafe.
  • MaidSafe has sponsored work at Strathclyde University in the past.

(who are those people on the forum and what are their interests? Categories? Who are most well-known? Ranking by date of first post?)

MAIDSafe Team on the SAFE Network Forum

SAFE Network Forum Moderator Team

Official SAFE Ambassadors: @dimitar (Bulgaria); @Sotros25 (US); @oetyng (Sweden)

Community Doers

(Somewhat arbitrary and incomplete list of people and their projects. Add your SAFE Network community heros here.)

@happybeing since April 2014 and still active, eg SAFEDrive

@dimitar since August 2014, eg First SAFE Ambassador (Bulgaria)

Relevant forum posts: March 2018, June 2019

MaidSafe supported
Community analyses
Peer Reviewed
Mentions of MAID/ICO

(list not reviewed)

(This is a community best effort list. Do not rely on this information for any purpose, do your own research and obtain your professional advice.) Believed to be up to date as of June 2019.

E.2.1 Patents Granted (US)

E.2.2 Patent Applications (US)

E.2.3 Published Applications (Worldwide)

(similar projects and status, failures, successes)

  • Napster (P2P file sharing) 1999
  • Freenet (distributed publishing) 2000
  • BitTorrent (P2P file sharing)
  • Bitcoin (decentralized trust and digital ledger) 2009

Archive

Github Archive (Deprecated/archived repositories)

(Note that some information may have become outdated and incorrect.)

SAFE Project whitepaper

Safenetwork.org 'Community' Links

Safenetwork.org 'Documentation' Links

Introductions by MaidSafe and community

SAFE Crossroads Intelligent and simple.

Fundamental Principles

App Directory

David's Blog

Miscellaneous

Introductions by third parties

SafeNetwork Roadmaps and Updates