Maidsafe coin Details+Update





  • SAFE Network Introduction Video:




    Features of the SAFE Network

    The SAFE (Secure Access For Everyone) Network is made up of the unused hard drive space, processing power and data connection of its users. It offers a level of security and privacy not currently available on the existing Internet and turns the tables on companies, putting users in control of their data, rather than trusting it to organisations. A number of features make this possible:


    Login and secure your data with no middle man.






    No need to give your password to anyone, or ask a third party’s permission to access your data. Your information, and access to it, belongs to you!

    Your PIN and Keyword are used to locate your data on the network and your password, which never leaves your machine, is then used to decrypt it locally. This means that no one needs to hold a record of your files, or your login details and there’s no need to ask anyone for permission to access it. This process is called Self-Authentication and enables you to find, unlock and decrypt your own data.



    Self-Encryption: Data which encrypts itself, with itself.





    Files uploaded to the network are broken into pieces, encrypted and distributed across the network. This process is called Self-Encryption.

    When a user uploads (or saves) a file to the network, via one of the SAFE Network apps, the file is automatically broken up into chunks. These chunks are then encrypted (encoded so that only authorised parties can read it), randomised and stored on the computers of other SAFE Network users. These encrypted chunks are completely unreadable and inaccessible to anyone other than the owner.


    Distributed network with opportunistic data caching.




    The SAFE Network is fully decentralised, with files distributed and stored all over the world, on different devices. This allows the network to be robust to attacks, with no central point of weakness.

    The distributed nature of the network provides your data with physical security, meaning that no third party can access or delete it, as can happen with existing centralised solutions. The feature called Opportunistic Caching automatically creates more copies of popular data closer to where it is being requested, so popular websites and other data feeds will actually speed up as they get more visitors, rather than slow down and crash as they do on today’s web.


    Data availability and built-in redundancy.





    The network is programmed to keep duplicate copies of each piece of data at all times. As users turn their computers off, the network makes more copies and stores them on other machines, ensuring that users always have access to their files.

    This constant movement of data (called churn) is a key part of the security that the SAFE Network offers because there is no central point for hackers to target as the data locations keep changing.


    Unneeded duplicates are automatically removed.



    Once a file is uploaded, other users who upload the same file will be automatically referred to the original, limiting the number of copies and reducing the computing resources needed to store it


    Crowd sourced internet:


    Rather than using data centres and servers common within today’s internet, which are prone to data theft and surveillance, the SAFE Network uses advanced P2P technology, that joins together the spare computing capacity of all SAFE users, creating a global network. You can think of SAFE as a crowd sourced internet. It is on this network that everyone’s data and applications reside.

    All you need to join this network is to download the free SAFE software, create your account and tell the network how much space you are going to provide. It’s that simple!


    Safecoin:


    Global distribution without human intervention.

    Safecoins are distributed entirely by the algorithms within the SAFE Network. Human beings are not involved in the process. Only 4.3 billion coins will ever be in circulation at one time and each will have its own unique identity. Safecoins will be recycled when users exchange them for network services, ensuring there is always a supply for users to earn


    Farming: an incentive for a crowd sourced Internet.




    Safecoins are given as an incentive to users for providing their resource to the network. This resource is their: storage space, CPU, bandwidth and online time that enable the encrypted chunks of network data to be stored and retrieved from their computer. The process of providing resource and receiving safecoin in return is called ‘Farming’. Each piece of encrypted network data is stored in a Farmer's ‘Vault’, a data storage and management location on the Farmer's computer which they cannot read, or access. The SAFE network is designed to self-manage these resources


    Resource based economy




    As network data is retrieved from a computer, the network pays safecoin to the user. This payment doesn’t take place every time data is retrieved, instead it is more like a lottery, where the Farmer is rewarded at random. The safecoin is automatically paid by the network into the user’s safecoin wallet address that is tied (cryptographically) to their vault. The amount of safecoin a user can earn is directly linked to how much resource they provide to the network and how often their computer is available to the network (turned on).



    Proof of resource.





    The resource provided by each Farmer is continually checked by the network to make sure that it is still available. It does this by attempting to store a random piece of data. Should the network find that the resource committed to the network is no longer available, it reduces the rank of the vault thereby reducing the earning potential of that specific Vault.


    A new market place.






    Safecoins can be used to access and use network applications, with part of the ‘payment’ going directly to the application developer. Safecoins can also be bought by users unwilling, or unable to provide resource to the network. This creates a market of buyers and sellers so that farmers can sell the coins they earn for another currency. These transactions will take place on an exchange, another SAFE Network application, or directly between individuals.



    Decentralised Applications





    The ecosystem around the SAFE Network is already starting to blossom and a number of exciting apps* are already being built by third party developers using the SAFE APIs.

    Applications that provide access via the Launcher API ensure that you can access all apps with the same PIN, username and password used when you created your SAFE account. This means that you stay in control of your details at all times.

    *The projects listed within the link above are built and maintained by independent parties.


    Team: https://maidsafe.net/company.html

    Download: https://maidsafe.net/alpha.html





  • safe_vault

    safe_launcher

    safe_core

    routing

    self_encryption

    https://github.com/maidsafe

    Links:


    [ref Network] MaidSafe Network website : www.maidsafe.net

    [ref Autonomous] Autonomous Network, David Irvine, Fraser Hutchison, Steve Mucklisch : https://github.com/maidsafe/MaidSafe/wiki/unpublished_papers/AutonomousNetwork.pdf?raw=true

    [ref Routing] MaidSafe Routing github site : https://github.com/maidsafe/MaidSafe-Routing/wiki

    [ref BitCoin] Bitcoin : A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, https://bitcoin.org/bitcoin.pdf‎

    [ref RUDP] MaidSafe RUDP github site : https://github.com/maidsafe/MaidSafe-RUDP/wiki

    [ref Persona] Vault Documentation : https://github.com/maidsafe/MaidSafe-Vault/wiki/Documentation

    [ref Escrow] The Escrow service for Bitcoin : http://btcrow.com/

    White Paper:https://github.com/maidsafe/Whitepapers/blob/maste...



  • MaidSafe Announces Equity Funding Round on BnktotheFuture

    http://cryptocentral.info/topic/430/maidsafe-annou...






  • RFC 42 – SAFE Launcher API v0.6

    https://github.com/maidsafe/rfcs/blob/master/text/...




    Summary

    Expose low level API from launcher to allow applications to allow thrid party applications to access the building blocks of the SAFE Network.

    Motivation

    Exposing low level apis allow dynamic applications to be built on SAFE Network. Using the StructuredData API third party applications can build and manage their own data structures to fit their needs.

    Detailed design

    Expose low level building blocks via launcher for third party applications, which will allow building their own data structures. Moreover, dynamic applications can be built on using the appendable data api.

    The low level apis use the FFI interface for low level API as detailed in the safe_core low level RFC

    APIs for,

    are exposed from the launcher through the REST interface.

    Permission

    Application must request for LOW_LEVEL_API access permission to invoke the low level api to store or read encrypted data. Since low level apis can be used to create data in the network, it might be possible where the data created by the apps cannot be deleted by the user again to retrieve the lost space. Thus, it makes it important to request user for the permission to access low level apis.

    Unauthorised access

    Unauthorised access is granted for reading public data using low level api by default.

    Handle Id

    The low level apis return Handle-Id corresponding to the data type that is being worked with. For example, the structured data will return a DataIdentifier-handle-Id using this Handle-Id, the operations can be performed on the structured data.

    It becomes the applications responsibility to drop the handle after the usage.

    Limitation

    Ability to work with versioned data is exposed only from low level APIs. Launcher's NFS API doesn't support versioning yet.

    Drawbacks

    If the handle id is not cleaned up properly it can lead to memory leak. safe_core can purge if the number of handles goes above a certain threshold.

    Alternatives

    Nil

    Unresolved questions

    Nil



  • MaidSafe Dev Update – October 11, 2016

    Last week we released the second dev tutorial15. Since we are trying to make a new release roughly every two weeks, you can expect Dev Updates between releases to be a bit more quiet

    In addition to working on the next dev tutorial, the front-end team is discussing improvements related to app authorization, permissions and data sharing between applications.

    We are also thinking about how SAFE Launcher can be scaled to various platforms (e.g. mobile, embedded, etc.). For example, SAFE Launcher currently needs to run in the background and continuously proxy HTTP requests to the SAFE Network, but on some mobile platforms that wouldn't necessarily be possible. It would be preferable if mobile apps could communicate directly with the SAFE Network.

    There are multiple approaches we are looking at, and we're planning to have a detailed discussion about potential changes to SAFE Launcher this week. We'll write a summary of the discussion and post it on the Dev Forum. The ideas we'll present will still be open to debate by the community and we’d love to hear your thoughts and feedback once we post that topic

    SAFE Launcher

    APIs that were integrated late into safe_core are being updated in launcher. The API for handling versioned structured data is being updated and tested from launcher.

    The test module for the APIs is being updated to work with electron-mocha6 and once this switch is done, the CI system should be able to run the test suite again.

    As said in the introduction, this week has been more related to discussions on how the launcher should be shaped for the future and how the APIs should be exposed.

    SAFE Core

    We have started the async overhaul this week and are using (relatively much more recent) rust-async-paradigm crates tokio-core1 and futures-rs1. That is the direction Rust community seems to be moving and lot of work is going into them. We have created a separate dev branch to allow master to continue to be usable with present Launcher etc., as it is a big and a breaking change. A lot of work has gone into that already in 2 days and there is steady progress.

    Routing & Vault

    This week we have another member joining the Routing team: Diggory Hardy18

    With 2 new members in Routing and Andreas getting back, we are now looking at our next milestone: user running vaults from home. This is our number one priority.

    The big issue we need to address for vaults from home is being able to prune out vaults that are so low resourced they kill the network. Along with RFC 37 – Disjoint Groups2 (which is already underway), to address the issue of low-powered nodes, we are looking at RFC 45 – Node Ageing9.

    We are also discussing what other changes we need to make before being able to start testing vaults from home again. For example, data chains (which will provide data republish) is not a priority for now, this will come after we are able to test vaults from home.

    Dev Outreach

    With @lightyear starting full time in October, we've started planning our dev outreach strategy. We are currently researching events and have submitted applications to the ones we think most suitable. In comparison with previous years, we are going to be attending more events than ever through 2017 as this is a key part of our strategy in pushing engagement on the back of the alpha and early tutorial releases. We will keep you posted about the events we’ll take part in, of course.

    Each event varies and we will use a combination of talks and workshops where possible. While talks are great for introducing concepts, we are excited by the workshop format, enabling Ben and other members of the team to bring app developers up the learning curve.

    We see dev outreach as a key part of our strategy moving forward and growing the developer outreach team during 2017 will be one of our priorities.

    In addition to attending conferences, we will also be seeding and working with members of the community interested in presenting SAFE at meetups, or run their own developer events and workshops. We will support this activity as much as possible. If you are interested in doing any of these, please get in touch with @lightyear or me (@frabrunelle).

    If you have any suggestions for conferences you think would help us spread the word in the developer community, please post them here1.

    Bitcoin Wednesday, Amsterdam

    We are going to be speaking at Bitcoin Wednesday in Amsterdam on the 7th of December so if you guys can make it through for that event we would love to see you there. We will keep you posted about the details.

    Chaos Communication Congress, Hamburg

    Ben is also planning to be at the Chaos Communication Congress this year2 (December 27th – 30th, 2016 in Hamburg). We are still waiting to hear back whether he got accepted to give a talk there, but he is planning on going either way. And he was wondering who else was planning on coming and whether anyone would be interested in organising an Assembly with him4.

    SAFE Browser

    Last week we created a new Dev Forum topic6 to give feedback on SAFE Browser. @joshuef also created a topic with a general todolist of what he’s working on: Safe Browser Dev Updates (@v0.3.2)2.

    There's an updated release of the Safe Browser to 0.3.2.

    This features a more robust 'safemode' toggle, including a navbar icon showing that you are on the safe network exclusively. This can be toggled by clicking the icon, or going into the File menu. This will reload all tabs upon toggle, blocking/enabling insecure (non safe) content.

    Funding

    MaidSafe’s funding round20 on BnkToTheFuture ends in about 14 hours. £1,246,869 have been raised through 226 backers so far. Thanks again to everyone who invested, supported and helped out with this round!

    Bug reporting

    If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo. If you’re not sure where to open an issue, you can simply create a new topic on this forum and add the #bug tag. @lightyear and I are subscribed to the #bug tag, so we will automatically receive a notification whenever someone adds the #bug tag to any topic. We’ll take care of opening an issue on GitHub if necessary.

    If an issue is specifically related to the SAFE API, then it makes sense to use the SAFE Dev Forum. But for issues related to end-user applications (e.g. SAFE Launcher, SAFE Demo App, SAFE Browser, etc.), it's fine to use the SAFE Network Forum. Most users already have an account here

    Also, to make the process of opening an issue on GitHub easier, we will start adding Issue Templates3 to most of our repos.



  • Top 8 Reasons to Invest in Maidsafe Shares

    1) ALL SAFE APPS THAT DO NOT ADOPT THE GPLv3 LICENSE OR USE THE SAFE APIs MUST PAY MAIDSAFE 1% OF THEIR REVENUE ALWAYS. I can't stress how huge this is. Once SAFE's network-effect takes hold, giant companies will be forking over crazy amounts to keep their source code private.

    2) MaidSafe is positioned to receive a large part of the 5% of ALL generated SafeCoins, that are set aside for core devs, for the forseeable futur (until other groups and programmers start helping in this area). That is a huge income. (They may also be among the largest farming groups early on when farming is most profitable)

    3) MaidSafe is currently among--if not The--top SAFE application dev teams in the world, as they created the world's first SAFE email system within a week or two. They could dominate the app scene with ease--especially early on, when SafeCoin sees its giant rises--if they so choose. Don't forget 10% of ALL generated SafeCoins go straight to the app devs.

    4) These stocks are LIMITED, AND MORE MAY NOT BE OFFERED AGAIN! They allow the possibility for future MaidSafe IPO with huge gains, or possible MaidSafe acquisition for giant gains from current tiny price point (of barely $1M USD), or large possible fiat/ SafeCoin dividends paid regularly.

    5) MaidSafe is a hyper-efficient company, as their systems scale infinitely, disrupt companies with billions in profits (and billions in equipment expenses), but has no infrastructure costs of its own. That sets the stage for insane profitability.

    6) Even just the current Alpha release is enough to be licensed to large data centers for profit, as it would eliminate data losses during server crashes. So I know we all aren't happy it isn't 100% finished being fully decentralized yet, but don't overlook the technical marvel of what a networking achievement it is, with its vaults and routing.

    7) Finally, last place is the original USB sticks straight from MaidSafe, and live SafeCoins sent straight to you at launch, both of which could become extremely valuable. Also an amount of free BTC every day from BNK (so the $1k is offset by all this).

    8) oh &..............Con$$$ulting. Period.

    So anyone who believes that SAFE will be successful at all would be foolish to not invest anything into the company that is in the best position to profit hugely from it!!

    (not legal advice etc) (also I made this shortened version of @fergish 's podcast to focus on the parts that talk about profitability. It's the one I keep referencing above.)

    Register & Invest!



  • Safe Browser Dev Updates (@v0.3.6-2)

    0.3.5

    Download:
    https://github.com/joshuef/beaker/releases/tag/v0.3.5

    New pre-release is available here: https://github.com/joshuef/beaker/releases/tag/v0.3.6-0 with updated error handling and more promisey base APIs

    Todo

    Here's the general todolist, vaguely in the order in which I'll attack them:

    SAFE Mode Toggle button/indicator. So you know you're safe.
    Straighten out Appveyor deployfor naming and to only have one link.
    - Linux/Windows safe: protocol integration, so safe: links will (optionally) load the browser
    Investigate localhost development... what can we do here to facilitate this
    - Add launcher detection (helper in safe-js), and appropriate notification
    - Safe network sync for browser data.
    - Add 'You can access the resternet' type screen when in SAFE mode. Instead of ugly broken screen.
    - Setup some helpful default 'favourites' for safe (suggestions welcome, I'd probably start with email [as per @polpolrene's suggestion] and a site list )
    - Investigate beaker shortcut issues.
    - (almost ) update package naming to match maidsafe standards
    - rename windows unpack folder
    - ensure production environment used for builds & remove BeakerDev menu

    safejs specifics

    improve safejs promise error rejection for DNS/NFS/Auth
    - improve safejs promise error rejection for new APIs
    - improve safejs test coverage
    improve safejs response parsing
    improve safejs handling of streaming APIs and html5 streaming




  • Maidsafe-EASIEST API TUTORIAL website:




    It's this new SAFE API Tutorial Website

    Logical extension from APP ZERO. I want it to be extremely approachable, and eventually have tutorials and walkthrough code for anyone creating web apps with safe-js. (the site will ultimately be SAFE-hosted, once the examples work, so that people can click the boxes to make the commands actually execute with launcher)

    Auth was covered by APP ZERO, but it looks like creating the basic folders is the logical next step, and a bit confused by the example code both on the MaidSafe website (bare-js? didn't work) and safe-js gh readme.

    tl;dr NEED HELP WITH CREATING DIRECTORY IN SAFE-JS so I'll tag @joshuef @DavidMtl (did you get your SimpleSafe working?) @happybeing and anyone else can help, submit PR's etc (site repo, & code repo)



  • New authentication flow + Granular permission control

    Today, we are presenting the RFCs related to the new authentication flow that was first explained in the topic about the future of SAFE Launcher.

    New authentication flow

    The current authentication and permissions handling flow relies on SAFE Launcher, a stateful intermediate between any particular app and the network. While this allows for fine-grained control over the access flow and user setup, it has the drawback of requiring the process to always run, keep a local state and proxy all network requests. This is particularly cumbersome on embedded devices and mobile, where we cannot provide this pattern reliably.

    RFC 46 – New Auth Flow proposes to replace SAFE Launcher with SAFE Authenticator (a stateless alternative).

    This RFC outlines a new process to give applications authorised access to act on the SAFE Network with the user's credentials. In particular, it is designed for the mobile and embedded use case in mind.

    Highlights

    At the core stands a rethinking of the data flow and authentication responsibility. Rather than requiring every app to go through the launcher to use the user's credentials, in this approach, the user creates "sub-credentials" per app and assigns them to the app. The app can then access the network with these credentials independently from any other process running. We call these credentials appKeys (as they are a public-private-key-pair attached to a user's maidsafe keys), which an app can interact with the network directly with.

    Apps will have to directly interact with the network. We will restructure safe_core to provide all needed facility for that, as well as the proposed authentication flow against the authenticator. That means that each App has to bundle their own safe_core and link to that library. The library will expose all necessary functionality also through FFI to allow for binding in other environments than rust.

    The root container is the main entry point for the user and most apps to interact with. It is a locally encrypted container stored at a random location on the network known only to the user, that generally only the authenticator has write access to. It reference will be stored in the user’s session packet on account creation. Keys starting with an underscore (_) are reserved for internal usage by the authenticator, while the authenticator may also allow the creation of other keys later.

    When creating a user account the authenticator will create the following minimal set of containers within the root container, each one with its own random network address:
    • _apps/net.maidsafe.authenticator/
    • _documents
    • _downloads
    • _music
    • _pictures
    • _videos
    • _public
    • _publicNames

    It is recommended that apps should only request the rights read and insert - which we will refer to as the BASIC-access. To promote the usage of this, APIs should provide a short-hand for this. Furthermore, the Authenticator may require a multi-step authorization from the user if it encounters an app that asks for more permissions than these and may allow the user to disable specific permissions asked for.

    Discussion topic for RFC 46 – New Auth Flow1


    Granular permission control

    Existing data types don't support granular access control which is required for mobile platforms where access to the network through an intermediary like SAFE Launcher is complicated: each app would have to receive full permissions to modify and fetch data on a user's behalf and private keys to sign it. This compromises security and allows malicious apps to get full access to the user's data.
    To mitigate that, MutableData provides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version of AppendableData. It combines StructuredData and AppendableData features and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.

    RFC 47 – MutableData proposes to combine StructuredData and AppendableData into a new single data type, MutableData, similar to HashMap.

    <code>pub <span class="hljs-keyword">struct</span> MutableData {
        <span class="hljs-comment">/// Network address</span>
        name: XorName,
        <span class="hljs-comment">/// Type tag</span>
        tag: u64,
        <span class="hljs-comment">// ---- owner and vault access only ----</span>
        <span class="hljs-comment">/// Maps an arbitrary key to a (version, data) tuple value</span>
        data: BTreeMap<Vec<u8>, Value>,
        <span class="hljs-comment">/// Maps an application key to a list of allowed or forbidden actions</span>
        permissions: BTreeMap<User, BTreeSet<Permission>>,
        <span class="hljs-comment">/// Version should be increased for every change in MutableData fields</span>
        <span class="hljs-comment">/// except for data</span>
        version: u64,
        <span class="hljs-comment">/// Contains a set of owners which are allowed to mutate permissions.</span>
        <span class="hljs-comment">/// Currently limited to one owner to disallow multisig.</span>
        owners: BTreeSet<sign::PublicKey>,
    }</code>

    The current features of Appendable Data will be covered by Mutable Data, but rather than just append, Mutable Data will support many discrete actions (e.g. “List entries”, “List keys”, "List values”, “Get value”, “Insert”, “Update”, “Delete”, etc.). These discrete actions will mutate specific key-value pairs directly on the network, rather than having to replace the entire content. Consistency and permissions will be enforced by the vaults. Mutable Data will also allow to create multiple type tags (just like Structured Data).

    The reason for this change is that we want to provide granular permission control over data changes within the network (rather than on the client side). Many things, that so far happened in the launcher (so we can develop faster) but should be done by the network (like stronger enforcement of permissions), will finally move into vaults.

    Secondly, we propose to introduce a new paradigm on the data type itself to handle permissions. Expanding from the owner-or-public-model, we propose to have field on the data type (called “permissions”) which maps signing keys to a list of actions that a key is allowed to perform on a particular data object. Every discrete action is checked by the vaults against the permissions assigned to that key and will only succeed when the required permissions are present.

    Highlights

    The proposed data type defines discrete actions on data that doesn't require a user to replace or fetch the entire structure contents. This is enabled by functionality similar to this of the HashMap data structure or a key-value database such as Redis.

    Permissions can be modified granularly by issuing actions similar to those used to update data. Only owners and apps having the ManagePermission permission must be allowed to issue such requests.

    Pending writes must support granular changes in data or permissions. Ownership transfer and encrypt key changes also must be represented by separate pending writes.

    Limits

    The MutableData data type imposes the following limits:

    • Maximum size for a serialised MutableData structure MUST be 1 MiB;
    • Maximum entries per MutableData MUST be 100;
    • Not more than 5 simultaneous mutation requests are allowed for different keys;
    • Only 1 mutation request is allowed for a single key.

    These numbers were picked as a starting point. They will be profiled and updated via testnets as the performance of the network improves.

    Discussion topic for RFC 47 – MutableData1


    Authorize apps on behalf of the owner to mutate data

    If the requests made by the permitted apps need to be charged these must all go through the Maid-Managers and they should know about the owner that an app is associated with so that they can charge the correct account.

    RFC 48 – Authorise apps on behalf of the owner to mutate data details how apps route their mutation requests to Data-Managers and how revocation works.

    Highlights

    We require all mutations to go via the owner's Maid-Managers. Maid-Managers will keep a list of sign::PublicKey which is the representation of the apps the owner has allowed to mutate the network on their behalf. Maid-Managers will then forward the request to the appropriate Data-Managers. The type MutableData thus does not need to store any signatures and Data-Managers will use the group authority to trust the requester of the mutation. Then they will use the permissions field to allow or disallow the mutation itself.

    Ownership transfers are a special case. The apps are not allowed to do this operation. They will need to ask the Authenticator to do this. Maid-Managers shall enforce that change_mdata_owner only comes from the owner. Data-Managers shall enforce that current owner of the data matches the incoming Maid-Manager group.

    Once the owner decides to revoke permission of an app to mutate network on their behalf, they will go to the Maid-Managers and delete sign_pk for the app. Hence the app can no longer perform any mutating operations on behalf of the owner now as the owner's Maid-Managers will reject it not finding it in the list.

    Discussion topic for RFC 48 – Authorise apps on behalf of the owner to mutate data