Maidsafe coin Details+Update



  • Maidsafe (MAID) Release accumulator v 0.7.0

    (cargo-release) version 0.7.0

    Download:https://github.com/maidsafe/ac...



  • 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 https://travis-ci.org/ or https://www.appveyor.com/, 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
    #[test]
    fn test_connect_to_peers() {
        let (tx, rx) = mpsc::oneshot();
        internet_simulator::run(&[
            || {
                let service = Service::new();
                service.start_listening();
                let addr = expect_event!(service, Event::ListenerStarted(addr) => addr);
                tx.send(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();
                service.add_contact(addr);
                service.bootstrap();
                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 (mockup.safe-fs.io8)
    • a redesigned community forum to host our documents and discussions (forum.safe-fs.io5)
    • 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.

    #Decentralize #SAFE-FS.io



  • 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

    Future:

    • 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 (https://medium.com/safenetwork34) 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.

    Marketing

    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 (https://medium.com/safenetwork34) 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 npmjs.com with these changes, and the updated documentation was also published at http://docs.maidsafe.net/safe_app_nodejs1.

    @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



  • MaidSafe Dev Update - SAFE DevCon 2018, New Video, new Dev Hub & More

    Hi all, we’re still buzzing from SAFE DevCon 2018 on Monday of this week. Thank you all for attending, watching and commenting online - and of course a huge thanks to each speaker who presented on the day. It was a pleasure for the MaidSafe team to share the stage with you. It was amazing to see the community come together and we’re happy to reveal that planning has already started for a bigger and better SAFE DevCon 2019….

    You can read further about SAFE DevCon in our most recent blog post . The videos of the individual talks will be out within the next week or so (subscribe to our YouTube channel to get notified when they’re posted). And in case you missed the big news, please head on over to take a look at our new DevHub , read about our licensing announcement  and of course please do watch and share the new Safecoin video .

    With the global MaidSafe team together at HQ in Scotland for the first time ever, we had a packed weekend of activities, together with the preparations and follow-ups from SAFE DevCon. On top of that, the majority of the team has been travelling back home this week - in some cases literally to the other side of the world - so we’re not going to put out a full weekly Dev Update today.

    But never fear, next week, things will be back to normal. So in the meantime, we heartily recommend that you all go and congratulate @happybeing who has been working tirelessly on his SOLID plus SAFE integration (as presented at SAFE DevCon 2018) and got some well-deserved support from none other than Sir Tim Berners-Lee  himself last night! If you haven’t already, there’s something to shout from the rooftops.

    It’s been a huge week for the SAFE Network. Thanks as ever for your support



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

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

    • We’re happy to announce that we’ve been asked to participate in the Decentralized Web Summit  in San Francisco this summer.
    • @dirvine and @nicklambert were interviewed about the SAFE Network for a BBC Radio show .
    • @sarahpentland put out a Medium article on Safecoin  that’s provoked some discussion on this forum topic  that’s worth checking out.
    • The C# bindings are progressing well. A pull request  has been raised to merge the latest code with the upstream repository. This pull request is a huge step forward, as it adds support for .NET Core - Windows, Linux, macOS (x64), .NET Framework (x64), iOS and Android.
    • It’s been a huge week here in Routing. It’s one of those weeks that stands out in the history of the development of the project and one that will go down as being a key milestone by the time we reach Beta.

    Marketing

    Decentralized Web Summit

    We’re happy to announce that we’ve been asked to participate in the Decentralized Web Summit  in San Francisco this summer. This is a crucial gathering of the top minds and projects working in the area and a follow-up to their excellent 2016 conference which had people such as Tim Berners-Lee and Vint Cerf speaking (previous videos here ). We’ll be sharing further details of our plans for the event closer to the time.

    SAFE Academy Update

    Work has continued on the SAFE Academy this week. There’s still plenty to do to get the first version out the door but we’re happy to report that the schedule has now lined up for us to release the initial version of the SAFE Academy by the end of June.

    Press: BBC Radio

    @dirvine and @nicklambert were interviewed about the SAFE Network for a BBC Radio show .

    Safecoin Medium Post

    @sarahpentland put out a Medium article on Safecoin  that’s provoked some discussion on this forum topic  that’s worth checking out.

    A mystery…

    Finally this week, we received this lovely gift through the post…

     

    20180517_162235-0120180517_162235-01.jpeg3024x4032 2.38 MB

     

    However, there was no address or note with it so unfortunately we have no idea who sent it! So - if it was you, please let us know so we can thank you properly! (Or perhaps you want to keep it quiet in case everyone wants one…)

    User Experience & Website Design

    This week has seen the newly expanded UX team really firing on all cylinders; taking on their first major task: the SAFE Network website.

    After a false start with an external agency, the decision to take this entirely in-house is proving to be an excellent choice. User Experience design is always best tackled holistically, and while the website is only one fraction of the larger picture, considering it alongside all the other moving parts will undoubtedly be beneficial to the whole.

    Building a Design Process

    The first part of this project has been to build out our own design process; which in this case will be collaborative, iterative, adaptable and above all human-centred: just the way we’d like to proceed on all projects. In this case though, it’s going to be quite rapid: it’s exciting for the team and will help us prove and improve the process for future design challenges, of which there will be many.

    Target Users and Design Personas

    The next phase of the project was tasked with defining and refining who our target users are, and a period of research to flesh these out into more focused Design Personas, tightening up the brief around them. These Personas are both a communication and a design tool, and they’ll allow us to evaluate proposed design solutions with clarity.

    Information Architecture & Messaging

    We then bounced straight into building out the core messaging and Information Architecture for the site. An engaging process, but a challenge when such a complex and multifaceted project is the subject of your attention. Some of you may have noticed a corresponding spike in the Post-It Note share price.

    Content Meets Design

    The output from the IA process then informs the next layer of the project, where content meets layout design. We’re breaking from the traditional, more linear model of Plan Content > Write Content > Wireframe > Visual Design by collaborating and rapidly iterating to grow and develop content and visual design together. This allows both halves of the puzzle to inform each other and evolve together, with a more cohesive end result. Plus, it’s just a lot more fun.

    Mood Board and Approach to Creative

    Alongside this we’ve started to get our hands dirty in creative: taking cues from the vision and inspiration of the project to generate ideas and examining in detail all the elements which will come together to make this a communicative and effective website: colour, typography, texture, movement, patterns and depth.

    It’s also a chance for us to see how similar projects and other websites in the same space are placing themselves from a design point of view. We can then talk clearly about who we are — be a distinct voice amongst the noise — and yet identify and stay within established design patterns where it helps the user.

    Clear, orderly, and understandable; while being different, vibrant and human at the same time.

    The Mood Board in our project is more than just a way to collect inspiration, it is a design tool in its own right, and it lays foundation for a rich palette of design elements that we can build the project upon, and can form the basis of a style guide and design system that can have influence beyond the website.

    We’ve made some good strides forward this week in design; exciting not only for the website but for the prospects of all the challenges we’ll be getting our teeth into in the months to come.

    Big props to @SarahPentland, @dugcampbell, @nicklambert, @shankar, @JimCollinson and @shona for all their work on this.

    SAFE Browser, Authenticator & API

    Now that the bindgen branch of safe_client_libs has been merged upstream, @lionel.faber is continuing his work on the Java bindings to expose the APIs for safe_app & safe_authenticator. We have encountered a number of roadblocks and we’re working our way through them. The progress for the NFS issue and the JNI implementation task can be tracked on JIRA.

    The C# bindings are also progressing well. A pull request  has been raised to merge the latest code with the upstream repository. This pull request is a huge step forward, as it adds support for .NET Core - Windows, Linux, macOS (x64), .NET Framework (x64), iOS and Android. CI is failing at the moment. Once this is resolved, the pull request will be merged with the upstream repository. safe_mobile will also be updated once this pull request is merged.

    We are reviewing several PRs submitted during the last week for our safe_app_nodejs package which bring some enhancements to our tests and also to the initialisation function of a safeApp instance. The initializeApp function was not returning a Promise as it was supposed to, which was also preventing us from correctly handling errors that could happen in that stage, e.g. a failure to initialise the native lib logging feature.

    Some other changes we started to work on are in relation to allow an application to disable the installation of the system_uri library. This will be particularly useful for mobile applications which would make use of the mobile native libraries.

    We also started some research on how we can support sharing links to content using the content’s address itself, i.e. without the need to map it to a public ID. We will be sharing more details as soon as we have a well-defined proposal.

    SAFE Client Libs

    This week we worked on making the full public API in safe_app accessible from Rust . What this means is that someone using safe_app from pure Rust should have access to the same functionality provided by the FFI interface. This is especially important now that safe_app has a different license than safe_core and routing, so we re-exported all required functionality from these two crates in particular.

    We’ve also kick-started the process of replacing C libraries with pure Rust versions where we can. As a result, we expect to simplify the cross-platform support: if we have only Rust dependencies, it means that we can build our libraries for every platform where Rust is supported. In some cases, it’s possible to build libraries without involving the Rust standard library and libc, which means we can build libs even for embedded platforms without any operating system. While this is a desirable goal, we decided to start with easy targets to dip our toes. The first library to undergo this change is self_encryption , where we replaced the Brotli compression  library with the pure Rust implementation . The pull request is ready to be merged; however, we want to take an extra step as a precaution to make sure that with this library change we are still compatible with the existing data stored on the Alpha 2 network, as both libraries produce different binary strings as a result of the compression algorithm output. The progress can be tracked in this JIRA task.

    We’re also continuing to improve our continuous integration and deployment scripts. The pull request  to provide better deployment scripts has been merged, and we’re finalising our work on automatically running the SAFE Client Libs builds on Android and iOS, producing complete libraries for both mobile platforms.

    Routing

    It’s been a huge week here in Routing. It’s one of those weeks that stands out in the history of the development of the project and one that will go down as being a key milestone by the time we reach Beta.

    As you may have gathered by this stage, we’ve made amazing progress in this area since the last Dev Update - to the extent that in the next week or so, we’re announcing something big. Very big. To answer the inevitable question, no, it’s not the Alpha 3 release. But to say we’re excited about this is an understatement. We’ve got a few things to tidy up at this side - but we’re hoping to be in a position to share this with you next week - watch this space!

    Crust

    Another week spent on polishing our uTP implementation. Bear in mind that it’s still at its infant stage, so we keep hitting some bugs. Since last week we’ve been implementing graceful uTP connection shutdown, which will act exactly like TCP. It’s almost done, but in the meantime, we found a couple new bugs which must be fixed first:

    1. in some cases, connection close sends two Fin packets instead of one - the remote peer doesn’t expect that
    2. our congestion control implementation panics recalculating packet delays

    Fixes for both issues are on the way and should be implemented in a matter of days. A nice side effect of those fixes is that with every change we keep adding more automated tests. Hence, tokio-utp is getting more robust and comfortable to work with :slight_smile:

    Speaking of testing, we keep investing a big piece of our time in netsim. Note that it’s still under heavy development. We’re highly experimenting; library interface, source code structure is radically changing. Currently, the documentation might be out of sync, but that’s a natural transitional stage



  • MaidSafe Dev Update - June 14, 2018

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

    • We’ve just released a new ‘Getting Started’ video . This is intended to be a quick and easy introduction for newcomers to help them get past a few of the common questions that are often posted on the Forum.
    • @dugcampbell was a guest on the Future Tech Podcast .
    • The Peruse browser code has finally been merged into the peruse branch  of the MaidSafe repository, therefore from now on all the issues for Peruse shall be reported in this repository and any pull requests meant to be for the codebase maintained by MaidSafe shall be sent there.
    • You can download Peruse v0.6.0 from here , where you can also see some known issues. This new version, while still a proof of concept, is heartily recommended for all devs as it features the future of the DOM APIs. Gone is the complexity of managing the handles, and you can now experiment with the safe-app-nodejs based API without having to build from source.
    • This week we are releasing a new batch of SAFE Client Libs libraries: safe_bindgen 0.5.0 , ffi_utils 0.5.0 , safe_core 0.30.0, safe_app 0.7.0, and safe_authenticator 0.7.0. This is a major release since January this year that comes with a lot of goodies, the highlight being the bindings generator.
    • Work has continued on the implementation of PARSEC and we’re very close to being able to start testing the protocol for real. The first cut of the algorithm is in our repository  and there will doubtless be some issues which will be exposed and fixed as we implement the tests and example code, but progress on this is good

    Marketing

    First up this week, we’ve just released a new ‘Getting Started’ video . This is intended to be a quick and easy introduction for newcomers to help them get past a few of the common questions that are often posted on the Forum. This will be updated regularly going forwards to reflect any changes that are rolled out across the Network.

    The team has spent much of this week working with the UX/Front-end team in honing the content for the website and providing feedback on various designs (of which more below), in addition to working through a number of broader marketing planning sessions.

    @dugcampbell was also a guest on the Future Tech Podcast  and talked about the SAFE Network during an interview with Crypto Core Media.

    Finally, a quick heads up to anyone based in Melbourne - @mav is organising a get together on Sat 23rd June  - get in touch if you’re in that part of the world and fancy chatting about all things SAFE!

    User Experience & Website Design

    As it turns out, it’s true: the faster you go, the more time slows down. This barely-provable-in-a-lab theory now has solid anecdata to back it up:

    This week the website team has managed to pack in a Newtonian physics busting task completion rate. @Shankar put in 15 hours on coding a pixel-perfect homepage before your coffee went cold—waved through a PR review almost undisturbed—before rolling on to the demands of responsification, to coin a word.

    All this while @Shona and @JimCollinson somehow managed to complete a multitude of page layouts—everything from FAQs, to Safecoin, to the Roadmap—before even starting them.

    What happens if you’re driving at the speed of light and you turn your headlights on? Nothing, if it isn’t logged in Jira.

    And the great thing about moving this fast is that the designs mature quicker too; patterns emerge, the rhythm of a site starts to become apparent, and yet it all still feels fresh. It’s not ready for the wild just yet, but let me put it this way: by the time we’re finished, you’ll have aged but six weeks, while the website will be ready for high-school.

    It’s been an Earth-week of hard work, high energy, and a bit more fun than strictly necessary. But then again, we’re reinventing the internet here folks, so it’s all relative.

    SAFE Browser, Authenticator & API

    The Peruse browser code has finally been merged into the peruse branch  of the MaidSafe repository, therefore from now on all the issues for Peruse shall be reported in this repository and any pull requests meant to be for the codebase maintained by MaidSafe shall be sent there.

    During the last week, we were internally testing Peruse, and fixing a few issues we discovered during that process. Today, we are making available a packaged (non-official) version of the latest code available in GitHub. We still have to migrate our CI and automated building scripts onto the MaidSafe repository, which we will have ready for the next release, and this is why this version is not published in the MaidSafe repository.

    You can download Peruse v0.6.0 from here , where you can also see some known issues.

    This new version, while still a proof of concept, is heartily recommended for all devs as it features the future of the DOM APIs. Gone is the complexity of managing the handles, and you can now experiment with the safe-app-nodejs based API without having to build from source.

    We have also created the playground3.0 branch  of our Web API Playground tool which is fully compatible with this new version of the Web API, and it can already be used to explore the new API.

    The new Web API is the same API as the one exposed by safe_app_nodejs with the exception of the authorise function which replaces the openUri function exposed by safe_app_nodejs as it sends the request to the Authenticator using the internal Peruse communication channel rather than the system URI. We highly recommend using the Web API Playground tool to get acquainted.

    And further to all of that, it’s worth noting this API change is a breaking change for all the web apps out there (sorry devs! But look: no handles!)

    We are now working on enhancements to the authorisation pop-up to show the same type of information shown by the SAFE Beaker Browser, as well as working on the implementation of the reconnect feature which is also supported by our Beaker Browser fork.

    SAFE Client Libs

    This week we are releasing a new batch of SAFE Client Libs libraries: safe_bindgen 0.5.0 , ffi_utils 0.5.0 , safe_core 0.30.0, safe_app 0.7.0, and safe_authenticator 0.7.0. This is a major release since January this year that comes with a lot of goodies, the highlight being the bindings generator which builds upon the foundation laid by the moz-cheddar library that is intended to be used for generating C headers from the Rust code. We took the existing code in moz-cheddar and improved it in a lot of ways: now we support generating bindings for multiple languages, starting with Java and C# - and hopefully with other community-supported language bindings in the future.

    @marcin was on vacation last week but he did get a PR merged  that dramatically decreases Travis CI timeouts, which have been impeding our ability to merge changes in the past. This PR works by splitting out the builds performed by Travis into multiple stages and by fixing an issue that was preventing proper usage of Travis caches. Additionally, we are upgrading all crates to Rust 1.26.2.

    Routing

    Work has continued on the implementation of PARSEC and we’re very close to being able to start testing the protocol for real. The first cut of the algorithm is in our repository  and there will doubtless be some issues which will be exposed and fixed as we implement the tests and example code, but progress on this is good. All being well, there should be a running example by this time next week, and we’ll be working towards the second milestone which will see support for changes to the membership list (i.e. allowing nodes to join and leave the section while maintaining the integrity of the consensus process).

    Crust

    Remember that last week we started reworking encryption in Crust. This week we pushed an initial implementation to https://github.com/maidsafe/safe_crypto  which is based on rust_sodium for now. Initially, we had encryption traits, but when we started integrating them to Crust, we noticed how much more complex code was getting: all the functions and structures that used crypto primitives had to be made generic. So instead we decided to export concrete crypto related types in safe_crypto. The work on integrating those types in Crust is still in progress.

    netsim  is so cool that we want to shout it to the rest of the world. But no software project can flourish without good documentation. Hence, we started working on tutorials and examples on how to use netsim for misc scenarios.

    As mentioned last week, the tokio-utp crate has now been moved to https://github.com/maidsafe/tokio_utp . One more tokio-utp bug was discovered which only reproduces on Windows. Under heavy load, our implementation starts losing packets and at some point, when memory buffers fill up, connections are reset. This should not happen, because that’s the whole point of congestion control - don’t send more packets than the other side can handle. We started investigating, but haven’t found the root cause yet. But we will



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