Maidsafe coin Details+Update

  • Maidsafe (MAID) Release accumulator v 0.7.0

    (cargo-release) version 0.7.0


  • Maidsafe (MAID) - Crust roadmap for beginning of 2018

    2017 was a good year for Crust: the codebase was ported to Tokio Futures based networking

    which is becoming the default in Rust community, code became simpler and more maintainable, NAT traversal was greatly improved with external p2p crate and on top of that multiple transportation protocols became possible with current UDP and TCP implementations.

    If you’re here, it means you’re wondering what’s next. Crust is already able to fly, but before seating hundreds of passengers, we need to put more effort to assure it’s robust. Hence, we will be giving a lot of attention to testing.

    Unit and Integration Tests

    Currently Crust has both unit and integration tests. Unit tests try to verify whether small pieces of code work as they are expected to. Whereas integration tests check if different pieces work together. kcov reports quite large code coverage by tests - 80.6%. As good as it sounds, it’s mainly because of high-level integration tests that exercise a lot of code. We would still love to have more unit tests - they help a lot to indicate and locate bugs and allow us to move faster while developing new features without regression.

    uTP Testing

    uTP is a transport protocol that works on top of UDP. It was first used in torrent clients which was a great success. Because of smart congestion control algorithm used by uTP,
    it’s very suitable for applications like torrent clients and SAFE
    Network vaults. The algorithm is able to dynamically adapt to network
    load at a given time and not disrupt internet connections, while still
    utilizing the unused bandwidth fully. So we are very excited to have uTP support in Crust
    as one of our transport protocols. This is still a very fresh work and
    still needs to be properly tested: we’ll do some more manual testing and
    write more automated integration tests. Eventually, it would be nice to
    go into the wild with this and test how it works with all sorts of
    network configurations. Hence, we’re planning to release some tools
    available to the community so that everybody interested could
    contribute. More on that later though.

    Automated Soak Testing

    We heavily rely on CI to avoid regression. We have builds for all major platforms: Windows, Linux and macOS. That works well for functional tests and to assure decent code quality. But when it comes to performance, that’s a different story. Historically we have found bugs that would only start occurring after sending hundreds of megabytes over a connection. Ideally, we’d like to have automated soak tests. Unfortunately, it’s not feasible to run them on regular CI services like or, because running long lasting performance tests would hurt our regular testing experience. Hence, we need a separate testing environment for that and we’re planning to build it ourselves in MaidSafe HQ and run tests on our own machines. We’re planning to run soak tests regularly (maybe nightly) to detect any flaws as soon as possible.

    Isolated Network Simulation

    Crust implements a lot of NAT traversal techniques. Making sure that they all work as expected, especially hole punching, takes a lot of effort and, unfortunately, we haven’t found ways to do that automatically yet. Luckily, there’s a solution to this.

    It’s possible to write a Rust library that allows launching a thread into it’s own isolated network environment where it only has access to a virtual network interface. From outside the thread we can then read/write packets directly to/from this interface in order to introduce latency, packet loss, or any other form of communications-mangling. Using iptables we can also set up these threads with their own NAT rules.

    To showcase how this could be used, it could allow us to write test cases that look something like this:

    // Example Crust test
    fn test_connect_to_peers() {
        let (tx, rx) = mpsc::oneshot();
            || {
                let service = Service::new();
                let addr = expect_event!(service, Event::ListenerStarted(addr) => addr);
                let peer = expect_event!(service, Event::BootstrapAccept(peer) => peer);
                // we connected! now exchange data or something.
            || {
                let service = Service::new();
                let addr = rx.recv();
                let peer = expect_event!(service, Event::BootstrapConnect(peer) => peer);
                // we connected! now exchange data or something.

    In the above code, the two Crust services would each have their own IP address, be behind their own NAT, and be communicating over a lossy connection with latency.

    We already have basic proof-of-concept of this working. It’s Linux-only and isn’t yet fully developed so you can’t spin up a virtual internet with a single command, but all the essentials are in-place. Hence, that looks quite promising and exciting since nothing like this exists yet. Folks, what do you think?

    Testing Tools

    The right tools for the right job might save you hours of work. So we are looking forward to enhance our testing toolbox.

    One of the ideas we have is “router probing tool”. The problem is that routers in the wild exhibit all kind of weird and wacky behaviours which effect our ability to hole-punch and reliably maintain a connection. It would be good if we could catalogue these behaviours and their relative prevalence. This would help us know how Crust could be improved and how urgently certain improvements may be needed. A way to do this cataloguing would be to release a tool to our users which runs a set of tests while communicating with a set of external servers, then reports the test results back to us. Eventually, some form of this test could be integrated into the p2p library in order to avoid the need for the user to do their own manual configuration.

    The second tool we’re thinking of has nothing to do with automation. We’re planning to build a small peer-to-peer application on top of Crust. Probably it’s going to be a secure p2p chat since chat applications are like hello world of networking and that would be perfect proof of concept that Crust is working properly. Such tool would also aid in testing how Crust acts in different network setups with different routers, etc. This app will be, of course, open source and binaries will be publicly available to the community. So everybody will have a chance not only to test drive it but also will be able to pitch their own ideas and contribute to development if they want to.

    Finishing off for Alpha 3

    Finally, we will build a small DHT layer on top of Crust to create a standalone application. This will require a functional bootstrap cache and secure serialisation. The bootstrap cache will help us retain peers to whom we could connect directly to before so that when we disconnect from the network and want to go online again, we will use those peers to proxy to our overlay network. In addition, those peers will also be used as rendezvous servers. Every message sent by Crust eventually will have to be encrypted, but that should not be tons of work since we already have secure_serialisation library. With this, we will have concluded the goals of Crust crate for alpha-3.

  • MAIDSAFE-FS – Decentralizing Online Files | Application | SafeAppStore software

    We have recently decided to announce the final & larger half of our planned applications, SAFE-FS.io45

    The SafeAppStore software is as complete as it can be at present, as we have released most of our designs4 (#21), many updates, and a revised financial report for the project. While we await SAFE’s APIs for further development–which we are quite ready for–we have decided to begin our much larger application that we have been quietly organizing.

    SAFE-FS44 aims to become a flagship application on MaidSafe’s SAFE Network, to push itself and the network as a whole into the mainstream public eye. It aims to be the first-to-market and most widespread manager for public files & search on SAFE, while being as sleek and user-friendly as possible. We see these public files as perhaps the most important type of data, and the ability to manage and find them online could be the major driving force that powers PtP economics, and incentivizes users to upload popular files to SAFE.

    Our deliverables for you today include:

    • a detailed website of detailed information on all aspects of our company & technology (safe-fs.io44)
    • a live concept for users to upload files to and search through in real time (
    • a redesigned community forum to host our documents and discussions (
    • a visualization of our running costs and expected expenditures
    • recently released SafeAppStore Company Financial Report
    • an aggressive marketing campaign for SAFE-FS and SAFE, with an interactive SAFE-FS Marketing Calendar7, for users to browse our Marketing Events & suggest others
    • several new social media accounts for additional updates and communication

    This is an open source project which we are providing resources for, so that the SAFE Network will be allowed to be pushed forward, allowing our application to be used by a much wider audience. After securing the proper SAFE Network domains and audience, our extensible codebase will be made open source, so that it may be integrated into other apps and attract more users and developers to our platform.

    Many features of the app such as governance and votes on aspects of the software may be dictated by the SFSC involved, including the permanent, autonomous network rewards program. Additionally, based on SAFE-FS popularity and use, it can be used as a vehicle for potential future growth, based on amount of users and total size of the SAFE Network and our application.

    In short, many file storage platforms of today such as Dropbox, Google Drive, Amazon Cloud, Facebook file manager and others do not offer you any encryption, and certainly none that protects you from the snooping / selling by the company itself. SAFE-FS creates a completely open, transparent, immutable and 100% physically secure file storage and retrieval option that is not possible with the current infrastructure of the internet, and aims to be a highly successful and scalable company that pushes encryption and affordable privacy into the mainstream alongside MaidSafe’s SAFE Network.

    We are very excited to announce this, although we didn’t expect to begin SAFE-FS until much later. However, as we are still awaiting the SAFE Network APIs, we need to best utilize this time, and organizing this app and boosting our current marketing efforts will allow us to do so.


  • MaidSafe Progress Roadmap

    Here’s something to show people when they ask how long to launch.

    I don’t have enough time to fill it all in but maybe @moderators can make it a Wiki so everyone can add to it.

    MaidSafe Progress

    2006 David Irvine has first plans of SAFE Network and finishes version in Python

    2007 - 2014 MaidSafe pitches SAFE to hundreds of Universities & groups for support.

    2010 MaidSafe protects its work from trolls & big corps with tens of patents, to ensure the technology stays GPL open source & free for all the people of the world.

    2014 MaidSafe raises $8m in the first major ICO ever, to fund SAFE’s development

    2013 - 2015 TEST 1 - 17 networks & Alpha 1 & 2 are successful in proving underlying technology

    2017 MaidSafe expands its team to 30+ people with teams for frontend, backend etc


    • Alpha 3 for routing
    • Alpha 4 for vaults from home
    • Alpha 5- To be Announced ?? :rage: :anger: Wat?? Yes, if needed then there could be some more. “Ugh!!” :anger:
    • Beta for test SafeCoin
    • Launch for changing the world
    • Post-launch apps such as DEX etc

    etc etc etc…

    You guys get the point.

    This will be great to have, to show the progress of what has been done and the capabilities of the group doing them, so people can gague for themselves how long left.

    The more details everyone adds, the more powerful this becomes, to show people who ask.

  • MaidSafe Dev Update - Marketing, SAFE Authenticator & API & More

    Here are some of the main things to highlight this week:

    • Yesterday, we released a new video40 that explains how the SAFE Network differs from blockchain-based solutions.
    • The poll for choosing a proposal for the Safecoin Video Animation CEP13 is closing tomorrow. Forum users who are at trust level 12 and above can vote here.
    • The Marketing team has created a new Medium publication ( to collect content related to the SAFE Network in a single location.
    • All members of the SAFE Client Libs team will soon join the Routing team (some have already joined) to help with Routing development.


    New video released

    As mentioned in last week’s update about the marketing plans for H1 20185, we are keen to share with the community the broad messages that we’ll be focusing on when talking about the project.

    One of these messages highlights our distinct approach which differs from, and we believe improves upon, blockchain solutions. In order to support this message, we released a new video yesterday40. We’d be grateful if you could all share widely please across your own social media channels. We need this message out there to build upon the differentiation as the year moves on.

    SAFE Network Primer

    We also identified that we have a challenge in directing people towards resources. Just before Christmas, we received an early present from @jpl and @polpolrene in the form of a lengthy document called ‘The SAFE Network Primer’. The product of a huge amount of time and effort, this is a 30-page introduction that can be shared freely with anyone who is new to the project and looking for a summary. It’ll also be useful to those who perhaps have been following the project for a while but don’t have the time to forage around the Forum as they field questions from others. We now have a final version of this document and we’ll be pushing it out to the community any day now. Once again, we’d ask everyone to share it as widely as possible. Thanks again to @jpl and @polpolrene for all their hard work.

    Community Engagement Program update

    We’ve seen a good deal of interaction in our CEP to create a Safecoin video. We received four fantastic submissions, all quite different and the poll will be closing tomorrow (Friday 19th). The team has tried to stay out of the conversation on the Forum as far as possible in order to ensure that the community isn’t influenced in any way and we’d encourage you to vote if you haven’t already. We’re looking at a few changes for the next CEP, including the funding mechanism given the backlog on the network so we’ll keep you all updated.

    New Medium publication

    Over the years, there has been a variety of written commentary spread out between blogs (individuals and the company) and on other websites. As an experiment, we’ve now pulled together a Medium publication ( to collect the content in a single location. Medium brings with it an additional virality that extends beyond our existing networks by tapping into individual social networks (and also through regular email updates). Moving forwards, we’d like to curate content about the Network that’s posted on Medium (a good example is @goindeep’s recent posts). So if you create anything, please let @dugcampbell or @sarahpentland know.

    Team meeting at HQ in April

    Whilst MaidSafe employees are widely distributed around the globe, we’re keen to bring the team together more regularly. To start this process, we’ve arranged a weekend in April when everyone will descend on our Scottish HQ so that we can brainstorm and build out a few strategies in person. More on this to follow.

    Reddit reminder

    Finally, thanks for your support on the migration to r/safenetwork8. We now have well over 1,000 readers and we’ll continue to focus on growing this community each week. As a reminder, please support us by subscribing to the subreddit - and also re-sharing any relevant articles that you find elsewhere on r/safenetwork8.

    SAFE Authenticator & API

    We upgraded the system_uri library to the recently released v0.4.0 in safe_app_nodejs, and removed the libwinpthread.dll as a dynamic library dependency since it is now being statically linked in safe_app.dll. We also fixed some minor issues in the safe_app_nodejs documentation reported by @DaBrown95 (thanks, DaBrown95!). A new patch version of safe-node-app (v0.6.1) has been published on with these changes, and the updated documentation was also published at

    @hunterlester is working on making sure the example apps can receive the authorisation URI from the Authenticator even when they are launched in dev mode. He has also been working on upgrading Node.js to v8.x on the example apps as well as in safe_app_nodejs.

    We are also working on adding a new function to the safe_app_nodejs API (already available in safe_app lib) which allows the user to retrieve the list of containers, and permissions granted for each of them, from an authorisation URI, i.e. without the need to connect to the network to be able to retrieve such information.

    @joshuef just got back and he is fully focused on Peruse browser development. We’ve had some initial design meetings to define the UI/UX to be implemented in Peruse before we can officially release the first version. In parallel to this, we keep fixing bugs and applying enhancements to it.

    The C# API has been progressing well. The safe_app API implementation is ongoing and the authenticator bindings are also being worked in parallel. Tests must be wired up to validate the implementation before we start integrating it with the Xamarin applications. As mentioned in last week’s dev update, improvements to the C# API to make it more dev friendly have been implemented in the ongoing WIP branch1.

    SAFE Client Libs

    A couple of obscure bugs have been reported by the community2 member @jlpell and the front-end team. We’re actively investigating and debugging both of them: the first one concerns the app revocation procedure, which previously had other issues which were fixed and covered with tests. Now, the first look at it shows that this case is different, so we’re trying to reconstruct the pre-conditions and the environment that lead to this error. Another problem with SAFE Client Libs was discovered by @bochaco and it causes memory errors and segmentation faults in some circumstances. To get this fixed & covered, we’re also checking the comprehensiveness of our test suite and looking for ways to extend and improve it.

    After we get done with the fixes and the immediate tasks, we’re planning to move the entire team to help with Routing development. @adam has already joined it and @marcin and @nbaksalyar are currently catching up with the recent progress and documentation.

    Meanwhile, we’re also continuing with small improvements here and there. E.g., continuous integration build times started to get too long and constantly failed with a timeout error which affected our workflow. We split the build process into several stages which now run in parallel and make build times more manageable.

    Routing & Crust

    In Routing, we are still mostly fleshing out the flows for splits and merges. A less complicated algorithm is now being aimed for. It is anticipated that this refined approach shall cause less potential issues, however, the edge cases still need to be considered to confirm it’s viable, which is time-consuming and consists of many active in-house discussions. Apart from that, work on the ageing simulation has been restarted. We identified a number of issues that need to be resolved, the biggest of which is making the simulated messages reflect the proposal more closely. Current simulation code simplifies some details of message flows a lot, which we suspect might be significant for the results. The other issues are new features that we would like to test, like using alternative relocation triggers or modifying some minor details in the way peers age.

    In Crust, we finally found out the issues with uTP connections. Actually, the problem was in the p2p crate with connection information exchange: it would simply timeout too soon - 20 seconds of being idle. For now the timeout value was extended, but in the future, this could possibly be made configurable. The other issue in Crust that made it so hard to debug this uTP problem was that when p2p failed, it wouldn’t display an error. Additionally, IGD was disabled for rendezvous/hole-punched connections. That was redundant anyway because if we detect an IGD enabled device, we can connect directly to it instead, which is more reliable. Also, we did a fair amount of code refactoring, we fixed a lot of linting issues and wrote more tests for both the p2p and crust crates. All in all, during the past week we made a couple more steps towards more robust peer-to-peer connections with Crust and it was pretty fun to see peer-to-peer chat16 working - no intermediate servers, obscure cloud services, APIs, etc. just real, old-school networking

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.