<= Back to FRONT

(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.)

• Hacking a SAFE App discussion

• Brain storming thread

(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.

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

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

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

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)

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.

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

RFC-0057 Safecoin Revised

Farming Reward System Proposal

Perpetual Auction Proposal

• Security challenges
  • Parsec security
• Exploration and simulation of farming rewards

• Chunk distribution within Sections

• Road to Fleming Big Questions