Maidsafe coin Details+Update



  • MaidSafe Dev Update - Test 18

    Today, we are pleased to be releasing Test 18 for all forum users who are at least trust level 1

    This is a new network, so trying to access data from Test 17 won’t work (you need to create a new account). We are planning to take Test 17 offline this weekend (both the internal test and Test 17 itself).

    Here are the main changes compared to Test 17

    • The storage limit has been doubled from 500 operations (store and amend) to 1000 per account.
    • Add new FFI function to get the account info from the network (number of available/used mutations)
    • Implement operations recovery for account creation, app authentication and app revocation.
    • Modify the client Rate Limiter paradigm to not put an upper threshold on number of clients with unique IPs to bootstrap off a proxy.

    It’s also now much easier to run your own local network (because of the
    new developer configuration options that have been added to Routing,
    Crust and Vault). See this Dev Forum topic for more info.

    Earlier this week, we started to document how to use the mock, local and
    actual network (for developers who want to build SAFE Network
    applications and websites). See this Dev Forum topic to read our first draft.

    For Test 18, we are intending to have some front-end updates next week
    to introduce an option for apps to request access to arbitrary Mutable
    Data objects (see this JIRA task for more details). The network itself shouldn’t require an update (unless something unforeseen occurs of course).

    Based on the feedback from the community, we are redesigning the UI for Web Hosting Manager app. You can see the new design in this Dev Forum topic. Please do share your feedback on the latest design.

    SAFE Browser v0.4.0

    To connect to Test 18, you need to use SAFE Browser v0.4.0.

    Accounts can be created using the authenticator bundled with the SAFE Browser. To open it, click on the Authenticator icon in the toolbar of the browser.

    This testnet is limited to forum users who are at least trust level 1 See this topic11 for more information.

    To obtain an invitation token, trust level 1 forum users can use this website20, which can also be accessed via the SAFE Browser itself when creating an account.

    Each client account is limited to 1000 operations. It’s worth noting that this number is just a temporary placeholder and is shared between all the apps on a given account.

    Please be aware that we might need to restart this test network, wiping all data that is stored on it. We will announce this in a dev update (when possible) prior to taking it down.

    Download

    Changelog

    • Freeing of safe_app object handles. Object handles created by the applications will be automatically freed on closing the tab or even on refresh.
    • Toggle safe browsing. Allow browsing of clearnet sites by toggling from File > SAFE Browsing Enabled
    • Index file to be read automatically. Providing the <service>.<publicid> as the URL loads the index.html file of the service.
    • The number of store/modify operations completed for the account is displayed in the Authenticator.
    • Enhancements to the NFS API are now being exposed to the DOM layer for web applications.
    • safe: protocol URLs will be opened in the SAFE Browser when opened from external links.
    • localhost: protocol is now supported. In order to open a URL like localhost:<port>, the URL must be converted to localhost://<anything>:<port>, where <anything> can be any characters but not empty, for example, localhost://p:3003/.
    • Several UI enhancements and minor fixes have been introduced, like ordering the application list, reducing the header size, loading overlay has rounded edges.
    • Issues with the building process for mock and real network have been resolved.
    • Compatible with Test 18.

    Known limitation

    • History and bookmarks are not saved in the network right now.

    Example applications

    Known limitation

    • Public IDs created via examples are not exchangeable between the apps.
      • This is the error reported with the Access Denied / Requested Entry not found error. This issue is related to the permissions of the service/mail mutable data. The root folder with the default folders are designed for easier sharing and collaboration between apps. Applications can request access to these while the authenticator manages the app access levels. In the case of public IDs, the public ID is added as a key into the _publicNames container. A corresponding MutableData is created by the app and the permissions for the same are set by the app. This MutableData is then added as the value to the public ID entry. Now when the second app tries to add a service to the MutableData created by the first app, it doesn’t have the permissions to do so as this was not created by the authenticator. To resolve this, we are going to introduce an option for apps to request access to arbitrary Mutable Data objects (see this JIRA task9 for more details).

    Web Hosting Manager v0.1.2

    When uploading files using Web Hosting Manager, the maximum file size is 25 MB per file.

    Download

    Changelog

    • Present more user-friendly error messages.
    • Long public ID and service name are truncated and shown on the UI.
    • Internal use of the NFS API has been adapted to recent changes in safe_client_libs master branch. The NFS API was using ImmutableData to store the files and now the API is updated to save DataMap pointers. For each file, a pointer to the data map is stored in the MutableData entry representing that file. The actual data map is stored in the network either encrypted or plaintext depending on the privacy level specified.
    • Window resizing is now disabled.
    • Compatible with Test 18.

    SAFE Mail Tutorial v0.2.2


    Download

    Changelog

    • Compatible with Test 18.

    SAFE Web API Playground

    A new tool called SAFE Web API Playground is now being formally maintained in MaidSafe’s safe_examples repository6, which allows any developer to learn and experiment with the DOM API in a friendly and interactive way.

    It is meant to help people aiming at creating websites/webapps that need to access the SAFE Network DOM API, which is available on the global window object in the SAFE Browser.

    Instead of having to upload your site to the network every time you want to test some code, you can simply use this tool to experiment and get a deeper understanding of how each API works.

    In order to use it, follow the instructions found in its README, and either upload it as a web app using the Web Hosting Manager application or just run it locally and access it from the SAFE Browser using the now supported localhost protocol (see above for details).

    It is also available on the test network at safe://webapi.learn/, however, it is much faster when accessed locally.

    Repository

    Clone it from GitHub



    Example HTML files

    An examples.html file has been published with the safe_examples release. This file showcases some basic use cases of the DOM API, like authorising an application, creating MutableData objects, as well as reading and iterating over MutableData entries. You can upload this file using the web_hosting_manager application and publish it as a website, and then run any of the three examples available from the SAFE Browser.

    Another file called leaking.html has been also published with the safe_examples release. This file can be used for testing the browser capability of freeing safe_app object handles. If you click on one of the example applications it will create a client and authorise the app but it won’t free them, causing a leak in clients. After running any of these examples more than twice you will start getting a connection error due to the limit in the number of clients being reached. Refreshing the page will automatically free all leaked objects allowing you to run any of the examples again.

    Support

    If you need help with anything related to SAFE Browser, Web Hosting Manager or SAFE Mail Tutorial, please use the #support category of this forum.

    Where should I report issues?

    If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.


    SAFE Authenticator & API

    • Upgrade safe_client_libs to latest in master branch.
    • Support the new NFS API from safe_client_libs. The safe_app_nodejs library was internally using ImmutableData to store the files, but this is now being handled directly by safe_client_libs.
    • Allow the logPath function in the API to receive a filename parameter to automatically generate the log path for it. The path will be the same as the path of the safe_core lib log file.
    • The appToken parameter in the DOM API functions was renamed to appHandle to make it more consistent with what it really is.

    SAFE Client Libs

    The pull request for operations recovery in safe_authenticator has been merged now, but this road doesn’t end here and we are planning on several upcoming improvements and fixes for this feature - all of them required to be sure that we have covered most of the known edge cases and this feature works as intended. One of the possible limitations is the concurrent app revocation: for instance, if a user wants to revoke apps on their PC and a mobile device at the same time, it’s guaranteed by the design that nothing wrong should happen, but we want to verify it and we’ll be improving our test suite. Also, we already have a plan to improve, optimise, and simplify some things related to how apps authentication and revocation work, so that’s what we’ll be working on for the rest of this week. However, as these changes are mostly just nice-to-haves and the main functionality is implemented & tested, we’re releasing new versions of the SAFE Client Libs crates with what we already have.

    The team also made a few additional changes. @marcin@canndrew has finished his work on the new feature to share Mutable Data objects between apps through the Authenticator, and his pull request will be merged soon. @adam has updated the repository to use the recent stable Rust version (1.19).

    We’ve also been involved in debugging an interesting bug that was
    reported by the front-end team as we weren’t sure of its origin (on the
    Rust side or on the front-end). As it turned out, it was neither: we’ve
    traced it down to node-ffi (the library that we use to communicate
    between JavaScript/Node.js and Rust) and discovered that this library blocks the execution
    thread while waiting for a callback to return a result. This comes into
    a conflict with our rule about non-blocking front-end callback
    functions and this behaviour caused SAFE Browser freezing in certain
    circumstances. We’ve tracked down & fixed these particular cases but
    the problem still remains and soon we’ll be discussing how to fix it
    properly.

    Routing & Vault

    The Local Network support via dev options is now fully integrated and tested in both Routing and Vault. There were a couple of fixes regarding rate-limiter. In this commit1, we make sure to send enough information to identify and clear the message from the acknowledgement manager in case we get the rate-limit exceeded error. When this error happens, the whole message is forgotten by Routing and the upper libraries are informed, which then have the responsibility to handle it the way they want. Safe_core for instance is going to retry the operation after a wait so that it doesn’t keep getting the same error back. This PR changes GETs to PUTs (mutations) as all it is testing is whether the request reaches the correct number of nodes at the correct destination. GETs are charged for the worst case as we don’t know in advance how much traffic it is going to cause. Changing to mutations allows the test clients to invoke the RPC pertinent to the test without getting an interference from the rate-limiter.

    For vaults, we now get the group size and quorum from Routing where it can even be tweaked now that Routing has a config file. The rest of the changes2 in vaults were to integrate with the Routing changes.



  • MaidSafe Dev Update - Authenticator & API, SAFE Client Libs & More

    Last week, we released Test 18. The focus during this week has been on getting all the issues that need to get completed for Alpha 2 (including those reported by the community) added to JIRA and making sure there are no loose ends.

    With Test 17, we had the rate limiter quite relaxed and a lot of traffic was allowed. In Test 18, it is kind of the opposite since there are many more reattempts and retries that need to be happening from the clients. We are now working on striking a good balance between these two extremes and we’ll be updating the rate limiter to improve its performance and give a better user experience in terms of data traffic. With these changes, a lot more future requests should go through in the first attempt.

    Advisory and Endorsement Requests

    Members of the team, especially David, are getting quite a lot of direct approaches, either through lengthy DMs and LinkedIn messages, from people looking for advice on other projects, or to endorse ICOs. While we would like to be in a position to help, our focus on network development does not allow us time to read these messages in many cases, let alone respond. Please do not be offended by this, it doesn’t mean that we don’t see an importance in what you’re doing, we are simply very busy and your time is likely to be better spent engaging with other potential advisors.

    SAFE Authenticator & API

    Issues that were raised in Test 18 have been gathered and organised in JIRA. The new IPC for sharing MutableData is being integrated this week. Integrating the IPC functions in safe_app_nodejs and authenticator is almost completed. This feature has been the priority for us this week and @bochaco@shankar are getting this integrated and tested end-to-end with the applications.

    We have also fixed a few issues this week. The native modules were not being loaded by safe_browser on a few Windows machines which did not have the 2015 Visual C++ redistributable. When the user tries to log in, the authenticator kept spinning and it was misleading as if it was not connecting to the network. We are now handling this case and the proper error message is presented. safe_browser issue #99 is also resolved.

    When the browser is trying to load a page even if the requested page/resource is not available, the loader in the browser keeps on spinning. This issue is now resolved in the master branch of beaker-plugin-safe-app.

    Based on feedback from the dev community, the getHomeContainer API is being renamed to getOwnContainer.
    This API is used to fetch the application’s own/root container. The DOM
    APIs have also been updated with this change. Please do keep a note of
    this change in case you are trying to build the browser or your apps
    with the latest code in the master branch of safe_app_nodejs and
    beaker-plugin-safe-app. Also, @hunterlestersafe_browser issue #1003 soon.


    The Web Hosting Manager app updates the progress bar only after the file is uploaded to the network. If a big file is uploaded, the progress bar takes a long time to update, leaving the user guessing whether the application is hung or still working. This will need to use the NFS API to write as a stream instead of passing the entire content at once. safe_app_nodejs already exposes APIs for the same. The Web Hosting Manager app must be refactored to use the API to write as streams and update the progress bar as chunks of data are being uploaded. @hunterlester should be able to resolve this issue this week.

    @joshuefpull request for storing the history and bookmarks in the network. The feature looks
    stable after a couple of testing iterations and we’re expecting it to be
    merged soon. @joshuef
    is looking into the DOM APIs to enable returning the error code along
    with the error message. Right now, only the error message is returned as
    beaker browser does not allow the APIs to return complex objects. @joshuef is trying to implement this feature for returning errors.


    SAFE Client Libs

    The back-end team has been working hard on fixing bugs reported by
    the front-end team and the community, and improving the features that
    were released last week. We’ve started with refactoring the account
    packet structure and improving safe_core, the essential
    parts of the SAFE Client Libs. The account packet is the data structure
    that holds the user account details, keys, and some extra information,
    such as pointers to the root directories - and that is the part that we
    wanted to improve because it remained almost intact since the SAFE
    Launcher days, while now we have a much more complicated design, with
    apps and the Authenticator. So now we’ve got rid of unnecessary
    indirections (the pointer to the access container is now stored as a
    part of the account packet) and inefficiencies (the root directory has
    been removed and the containers info is now stored directly in the
    access container). Along the way, we’ve reduced the number of network
    requests and parallelised some operations (which previously introduced
    useless synchronisation delays), so overall these changes should make
    the UI more snappy. They’re mostly completed and likely to be merged
    before the end of this week. For more details, you can see this JIRA task

    In parallel, @canndrew@adam have been working on improving the new API for sharing Mutable Data. The basic implementation has been completed and merged and now we’re working on implementing useful comments and suggestions from @bochaco
    and the front-end team. First, we’ve decided to clearly define the key
    for the metadata entry of shared Mutable Data objects because allowing
    an app to provide its own metadata key could lead to security issues.
    For example, if a password manager app sets the metadata entry to say
    something like “this data must not be shared with other apps”, another
    malicious app requesting shared access could point to some other entry
    to be looked up for metadata, effectively bypassing the caution message
    and making a user confused about the intent of the sharing request.
    Second, the permissions part of the request has been simplified: now we
    assume that an app wants to request only Allow permissions, delegating more fine-grained permission settings (involving blacklists and Deny) to apps having the ManagePermissions privilege. All these changes go in this pull request and we’re currently reviewing them and perfecting the details.


    Next, we’ll be focusing on optimising apps revocation. We’ve started with this pull request,
    which fixes some flaws and edge cases, such as attempts to authorise an
    application during an ongoing app revocation. This is not allowed now,
    as authorisation might interfere with re-encryption of revoked
    containers. Another issue could happen if an app tried to update or
    insert new data into a container which failed to be re-encrypted - in
    some circumstances it used an incorrect set of keys and mangled the
    data. Tomorrow we’ll continue addressing similar minor (but crucial)
    problems.

    On top of that, there was a lot of smaller improvements. @marcinconfirming and fixing bugs
    found by the front-end team, such as a case when subsequent app
    re-authorisation didn’t result in the creation of app’s own container
    (if it wasn’t created on the first request). @marcinmore NFS tests and verified that a user can still log into his account and browse the network even if he’s exhausted his account balance. He’s also removed a legacy module, public_id, which remained from the SAFE Launcher and wasn’t actually used by the front-end. @canndrewupdated the Routing dependency
    to the latest version, removing the necessity of retrying requests if a
    request rate limit has been exceeded - now that this is the Routing’s
    responsibility, we’ve considerably simplified this part of the code in safe_core. Finally, @adamhas implemented
    an environment variable switch that disables the on-disk vault storage
    for tests. This change should speed up both front-end and back-end tests a bit.

    Routing & Vault

    As stated in the introduction, the rate-limiter for Test 18 is stricter compared to the previous test network. Message resend logic has also not been too efficient as Routing breaks the user messages from upper libraries into user message parts, each of which can be a maximum of 20 KiB. So if there was a user message which was 200 KiB, Routing would have broken it into 10 chunks of 20 KiB each. If a few of them were rejected, we’d currently be sending all parts again from the Client libs. The user library would then have to resend the entire message again after a pre-defined waiting period. To optimise this, we’ve modified Routing to handle the message resend at that layer directly. With the new changes, Routing will now selectively re-transmit the user message parts for which the error occurred. This encapsulates the message resend logic away from the upper libs. Routing also optimises route traffic by allowing the upper libs to indicate a maximum wait period after which message relay via further routes will not be attempted. This not only applies to rate limiter errors but also other parts such as the Ack-Manager.

    There have been a few patches that have been brought in to master to address certain bootstrap bugs from Test 18 and the Rate limiter has also been refined this last week to allow clients to scale their data traffic capacity based on concurrent client connections active at the proxy at a given time. The PR addressing the same is currently waiting to be reviewed and merged2. Rate limiter throughput calculations have also been updated to reflect the actual data throughput relayed by the proxy nodes to the clients.





  • MaidSafe Dev Update - SAFE Authenticator & API , Routing & Vault & More




    Meetups

    You may have noticed from the forum that the SAFE Network San Francisco meetup9@whiteoutmashups is helping this effort along with @hunterlester426, a tuition free university. @whiteoutmashupsthis topic5.

    Being at the epicentre of the software world and with a huge number of developers, San Francisco is one of many areas where we would like to see more engagement, and these events represent some early steps as we start a more focussed effort on spreading the word about the SAFE Network. We are now working to maximise the effectiveness of these events and have incorporated both internal feedback and feedback from members of the community. Over the next few events, we’ll be improving the way in which the network is presented, as well as improving the AV so that the content can be made available for those unable to make it to events.

    This week the team have and continue to work through a number of JIRA tasks that either fix issues raised by the community in previous tests, or that add features. This might potentially continue into the following week too. Lots of details about that below. Backend code is more or less at a frozen state in terms of required features for Alpha 2 (Authenticator) and frontend doesn’t look too far away from the same too.

    We have also spent more time planning development in recent days to spread some of the engineering responsibilities around the team as we have a couple of guys either out at the moment (Adam is on vacation and Bart is relocating to Hong Kong for a few months) or, as in @Krishna_Kumar’s case, preparing to get married.

    Congratulations from all the team here Krishna, we wish you and your soon to be wife (Rennee) a long and very happy future together, although she is potentially in for a tough time as she competes for attention with your laptop which may have to be surgically removed for the big day

    Community-driven content Continuing in the marketing vein, we would like to point out for those who have missed it, the effort being put in by a few long-standing members of the community including @polpolrene, @Krekc, @JPL and others who are starting a collaborative effort to pull together a new SAFE Network white paper/primer that brings together the most up to date content in one place. This comes on the back of a survey conducted by @JPL that gauges the SAFE communities attitudes toward the way the existing information is presented.

    Marketing

    David also took to his own personal blog a couple of times during this past week to write about The Impossible Network and to clarify the differences between the SAFE Network and alternative data/storage networks that incorporate blockchain technology. The fact that the SAFE Network completely removes intermediaries and humans from the management of our data through the network’s algorithms is a huge differentiator and the benefits of that is something we will be focussing more on in future marketing communications. We are also now starting to recruit 2 digital marketers to be based at our HQ in Scotland to help promote the network and drive engagement with the technology and the company.

    SAFE Authenticator & API

    The focus for this week has been to complete the tasks that were added to JIRA. The new IPC for requesting access to arbitrary MutableData objects has been integrated with the authenticator and also with both example applications (Web Hosting Manager and SAFE Mail Tutorial). We have tested the initial integration with the apps and authenticator. An application can set the Metadata for the MutableData in case it wants to share it with other applications as explained in this comment. We don’t force the devs to set the metadata. If the app is not setting the metadata and another application wants to access the same, then there is no useful information to be presented to the user for aiding the decision making on whether to grant access or not. Hence, we decided to provide an option to look up for the applications that have been granted access for that MutableData. With this feature, the user can see the list of applications that have been granted access before and then decide on whether or not to grant access to the requesting application. The API to get the list of apps that are granted permission for the MutableData is being actively developed by the core team and we will integrate the same with the authenticator.

    Another major improvement on the browser this week was to enable the error codes being passed back from the APIs on failure cases. We were not able to pass complex objects across the DOM APIs and thus we were only passing the error message previously. @joshuef has resolved this issue and now we can pass the error codes back to the DOM API layer.

    The API changes in safe_app_nodejs related to the new IPC for MutableData are also exposed from the DOM APIs. The DOM APIs are now up to date and in sync with the Node.js APIs.

    The upload experience of files in the Web Hosting Manager app is improved. The progress bar used to update only when the file upload was completed and when a large file was uploaded, the progress bar would stay at zero percentage until the file is completely uploaded. The user gets an impression that the app has hung, while it was still uploading the file behind the scenes. Now we have fixed it by using the NFS API to write in smaller chunks to the network and the progress bar reflects the status immediately.

    We have made good progress this week and the pending task list looks much smaller compared to where we were last week

    SAFE Client Libs

    We’ve been continuing to work on tasks that were mentioned in last week’s update particularly improvements on the authentication side in the safe_core part of the libraries. We have finished with the refactoring and optimisation of the account packet structure

    and the account registration flow, which is now only the Authenticator’s responsibility (safe_core
    is concerned only about filling and putting the account packet to the
    network). These changes helped us to simplify and decouple multiple
    modules in the libraries


    @marcin is continuing to work on improving the new ShareMData IPC request, basing on the changes by

    @adamhave been merged
    last week. After some discussions with the front-end team, we have
    concluded that the mutable data sharing flow needs to be changed a bit:
    previously, we didn’t support sharing of Mutable Data objects without
    metadata because it wasn’t clear what we should show in the UI in this
    case - a user couldn’t tell what the exact purpose of the requested
    Mutable Data is just by looking at its name and a type tag. Now, we
    decided to implement a new function in the Authenticator API to return a
    list of all apps that have access to a certain Mutable Data - this way a
    user can infer its purpose by looking at the list of apps that have
    permissions to access it. It’s outlined in more detail in the JIRA task.

    Routing & Vault

    The final PR for rate limiter6z which brings in the feature of soft capacity is now merged. We patched a bug in Routing which showed up in the soak tests after many iterations. It’s when two nodes want to connect to each other, prepare connection info request and send it to each other but are blocked from connecting to each other by the mock-crust test. The code in peer manager prepares connection info as a response to both connection info request and connection info response. Thus after the nodes realised that they could not direct connect and started to tunnel to each other which also failed for the first tunnel selected as this was also a part of the test’s simulation logic, one of the nodes got a connection info response from the other. This made its peer manager change state from searching-for-tunnel to preparing-connection-info and hand it over to node.rs. Unfortunately, this operation in node.rs was a no-op when called from handle_connection_info_response. Thus there was a disconnect between peer manager, which thought Routing was asking Crust to prepare connection info, and node.rs which ignored this and never contacted Crust. To fix this, peer manager is now patched to not change its state while searching for tunnel if it gets a connection info response. Eventually, other potential tunnel nodes would be tried and the connection would succeed. This fix is now merged. Soak tests with the latest changeset have been running for a few days now and are looking good.

    A Vault PR to integrate with the latest Routing is now up and waiting to be reviewed. It has the necessary refactor mandated by changes in Routing which no longer raises proxy rate limit exceeded errors (as it deals with them internally), the details of which were stated in the previous dev update.



  • Maidsafe - Safe Tube release

    safetube

    I just finished the last bit of code on Safe Tube, github To To access the website go to safe://safetube.jam 

    and paste the code from here
    into the browser developer’s console (right-click on website, click on
    inspect element and click on the console tab) or you can access it using
    a local webserver. The videos have to be loaded instead of streamed so
    it will take some time for the website to fully load. Feel free to give
    some spare maidsafecoins to this address:
    1Dksk7aA6PPpttznZi73d8xzsw4ERHSTLc

    Also big thanks @bochaco and @hunterlester for their help here

    If you have any issues or requested features please leave them here.

    This is part of Joseph's safe websites project. I will now release a seperate topic for each completed project as it will be easier to keep track of bugs and requested features.




  • Guys, I'm too old and lazy to figure it out. For example, there http://www.fintech.finance/01-... is a survey for investors - it's better to burn tokens after buyback or release them back. Which way is better?



  • MaidSafe Dev Update - SAFE Authenticator & API,Client Libs & More

    Today, we started testing Test 19 internally. As mentioned last week, we are continuing to work through JIRA tasks and fixing issues that need to be completed for Alpha 2. The network itself is looking good in internal tests and we don’t expect to make major changes to Routing & Vault before Alpha 2. However, there are still a few front-end issues we need to fix before releasing Test 19. Here are some of the issues we intend to address in the next few days:

    • MAID-2288: Uploading a directory with many files fails in Web Hosting Manager
    • MAID-2289: Permissions list in Authenticator always shows a full list of permissions
    • MAID-2270: Update Web API playground tool with changes in containers permissions API
    • MAID-2290: Show empty log page / log size
    • As well as other minor issues and UI changes

    We initially hoped to get this testnet out tonight, but we feel these pending issues might affect general UX quite a bit. We’re hoping to have these resolved quite soon and get the binaries out to you to test these new features. It is fantastic mind you, to not be waiting on backend, vaults and routing etc. as these bugs are annoying but not keeping us awake at night. We do feel the pain of delays, probably more than most and we are desperate for the energy test network releases give us all. While backend libs are stable and Alpha 3 work continuing from the guys there, Alpha 2 and these pending front-end tasks remain our highest priority to complete as soon as possible to get the new test network going to keep progressing with the roadmap.

    Recruitment Continues

    As discussed in previous updates we are growing the (local) team across areas including engineering and marketing. We are also now looking to recruit a Help Desk Manager and a Release Cycle Manager to aid with the ongoing rollout process.

    The Help Desk Manager will plan, set up and run a help desk (using JIRA) as the network advances through the up and coming test iterations toward beta and beyond. They will also record relevant information from test networks and compile update reports, as well as identify trends in support requests and perform root cause analysis.

    The Release Cycle Manager will be multifaceted and cover quite a lot of areas including a combination of: thoroughly testing all new releases, ensuring that all risks, impacts and dependencies are all clearly understood and communicated. They will also write, maintain and manage all the technical documentation, something that we all appreciate needs worked on. We also envision that the successful candidate would get involved in helping to showcase and demonstrate new feature releases to all stakeholders.

    What we are looking for with both roles is a very proactive approach to helping all users of SAFE software and this is another important step in positioning the company to be more outward facing and commercially minded, and to garner ever more feedback from users with a view to improving our future releases.

    We initially hoped to get this testnet out tonight, but we feel these pending issues might affect general UX quite a bit. We’re hoping to have these resolved quite soon and get the binaries out to you to test these new features. It is fantastic mind you, to not be waiting on backend, vaults and routing etc. as these bugs are annoying but not keeping us awake at night. We do feel the pain of delays, probably more than most and we are desperate for the energy test network releases give us all. While backend libs are stable and Alpha 3 work continuing from the guys there, Alpha 2 and these pending front-end tasks remain our highest priority to complete as soon as possible to get the new test network going to keep progressing with the roadmap.

    Recruitment Continues

    As discussed in previous updates we are growing the (local) team across areas including engineering and marketing. We are also now looking to recruit a Help Desk Manager and a Release Cycle Manager to aid with the ongoing rollout process.

    The Help Desk Manager will plan, set up and run a help desk (using JIRA) as the network advances through the up and coming test iterations toward beta and beyond. They will also record relevant information from test networks and compile update reports, as well as identify trends in support requests and perform root cause analysis.

    The Release Cycle Manager will be multifaceted and cover quite a lot of areas including a combination of: thoroughly testing all new releases, ensuring that all risks, impacts and dependencies are all clearly understood and communicated. They will also write, maintain and manage all the technical documentation, something that we all appreciate needs worked on. We also envision that the successful candidate would get involved in helping to showcase and demonstrate new feature releases to all stakeholders.

    What we are looking for with both roles is a very proactive approach to helping all users of SAFE software and this is another important step in positioning the company to be more outward facing and commercially minded, and to garner ever more feedback from users with a view to improving our future releases.

    SAFE Authenticator & API

    The main focus and effort during the last week on the front-end side was finalising the integration with some changes required in the safe_client_libs and safe_app_nodejs APIs to enable the sharing of MutableData which impacted several artifacts including the UIs and UX of the applications.

    As explained in the previous dev update, both the Web Hosting Manager and email app now support sharing the same public ID for creating/adding email and web services, regardless of which of them created the public ID. This implies an authorisation request sent for the user to allow/deny sharing the MutableData behind the services’ container that is associated with that public ID. Internal integration tests of this new flow in Test 19 are going as expected and no issues have been discovered so far. The authorisation pop-up in this scenario displays the MutableData’s metadata to the user, but since this information is not enforced to be set at creation time, it can be empty. Therefore, in order to help the user make a more conscious decision at the moment of authorising a MutableData to be shared, the Authenticator has been enhanced to not only display the MutableData’s metadata information, but also to show the list of applications that are already authorised to access it, which includes the application which originally created it. The tests so far are showing that this functionality is also working as expected.

    In parallel to the above, safe_app_nodejs and authenticator were adapted to accommodate to enhancements made in the way that the containers and MutableData permissions are retrieved through the APIs, making it more homogenous. One of this enhancements is to be able to retrieve not only the list of containers that the application has access to, but also to get the set of permissions the application was granted for each of the containers. This forced us to rename one of the APIs exposed by safe_app_nodejs and the DOM API, from getContainersNames to getContainersPermissions, to make it coherent with its semantic.

    One of the other goals for the last few days was to try to work on some minor issues reported by the community either on GitHub or on the forums, and several of them were fixed or verified to be already solved, while others are being actively reviewed at the moment, while we also try to provide as much of a help as possible to the developers asking questions.

    As mentioned in the introduction above, the main focus for the next few days is to solve a few issues that we prefer to close before sharing the new binaries with the community, as well as perform more tests to make sure that all the pieces are working fine together; in the front-end there are several integration points and covering all flows is not a trivial task.

    SAFE Client Libs

    (cargo-release) safe_core- version 0.26

    Downlaod:

    Routing, Vault & Crust

    (cargo-release)  version 0.17.0

    Download:



  • MaidSafe Dev Update - SAFE Browser, Web Hosting Manager, SAFE Authenticator & API & More

    Today, we are releasing updated binaries for SAFE Browser and Web Hosting Manager (to fix a few minor issues):

    Download SAFE Browser

    Download Web Hosting Manager

    These binaries will connect to Test 19  (the test network we released last week), so you shouldn’t need to create a new account. See the Test 19 topic for more information.


    As you can imagine there is a lot happening in the background with Alpha 2 and Alpha 3 release planning. We have multiple teams all working on the various components now to ensure we deliver these next two releases promptly and professionally. You will have seen recent recruitment drives to aid us in these next few steps.

    Alpha 2 is not far away as we all know, but a timely release is imperative now and must tie up with other parts of the project such as PR, marketing and business relationship building. The Alpha 3 meetings this week have been very productive and allowed us to find some really pleasing numbers regarding network or overhead cost of some network actions. All in all, this has been a very good week.

    SAFE Authenticator & API

    Since the release of the front-end applications with Test 19, no major issues have been reported, neither internally or from the community. This is a good sign that the applications are quite stable and it is encouraging us to keep working on the minor issues we have in the backlog. We really appreciate the feedback and also the issues that the community has been reporting, and it’s very important and very helpful to have all issues reported, even if they are minor, in order to enhance the applications and make them more stable and usable.

    The following issues/tasks were resolved during the last few days:


    • MAID-23272: minor refactor to safe_app_plugin to remove the queue for auth requests as the Authenticator already provides one.
    • MAID-2307: solved the issue that causes a crash in the browser when browsing a deleted service
    • MAID-2306: uploading empty directories is now correctly handled.

    The issue with saving the state of the browser on the network (MAID-2318) is fixed but still undergoing internal testing. It should be solved in the next version of the browser.

    As anticipated in last week’s dev update, @shankar resumed the effort to enhance the UI/UX of the Web Hosting Manager application; we hope to be able to start our internal testing within the next couple of days.

    @joshuef is now working on trying to automate our release/packaging process since we’ve been doing it manually so far, which is not only a time-consuming task but also very error prone. This will help us in the short term to be able to spend less time on this process and also allow us to be able to quickly respond if an urgent patch is required for any of the front-end applications.

    Additionally, @hunterlester is working on creating tools/mechanisms to automate our tests for the DOM API. This is also in line with our goal of being able to quickly provide patches/fixes without risking the quality of the software.

    SAFE Client Libs

    We improved the app authentication process: the response from the Authenticator now includes the full Access Container Entry (a structure that contains details about the containers the app has access to), saving the app a network request. We also simplified and optimized the API for working with MDataInfos (structures that contain the network identifier and encryption keys of a mutable data).

    MAID-23132 is nearing completion which will allow us to automatically generate C header files to interface with our FFI. As part of this task, we refactored the FFI modules of safe_core and safe_authenticator. We also caught several FFI functions that were either not marked #[no_mangle] or were missing an extern declaration.

    Routing & Vault

    We are continuing to focus our research efforts on message broadcasting strategies, or in other words - strategies for ensuring that every intended recipient of a message eventually receives it. In addition to the simulation6 we developed last week, a further investigation on what additional penalty cost our current approach incurs is being carried out. We hope this will clarify our current situation and could provide us with a clearer comparison to any future proposal. Some other metrics, such as the total amount of traffic or number of messages in various approaches, are also being calculated.

    Crust

    Work this week has focused on tracking down bugs in our uTP implementation. Currently, the SAFE Network uses TCP for all peer-to-peer communication, though there are many advantages to using a UDP-based transport protocol such as speed and easier hole-punching through home routers. Our aim is to have uTP in a state where we can deploy it alongside TCP sometime in the next couple of weeks.



  • MaidSafe Dev Update - SAFE Network goes mobile, Alpha 2 - The Authenticator & More

    Another very busy week on the development front and as you will see we
    have a few things to get through in this update, much of which will come
    as welcome news to anyone following our development progress.

    SAFE Network goes mobile

    As you will soon notice, this update comes with binaries, but
    unusually these are not only for desktop, these also include mobile
    binaries. The two mobile apps in this repository 

    a mobile Authenticator and SAFE Messages, a mobile email app, are tech previews.
    These are not meant as end user applications, this example is to show
    developers one way to integrate from these platforms. We will allocate
    time and resource to create a full developer experience on mobile via
    native SDKs, including an easy to use API and documentation. This
    preview merely showcases the network’s mobile compatibility. Currently,
    these applications are created with Xamarin

    as it allows for a simple unified codebase to test the compatibility
    concepts. We wanted to confirm the authenticator capabilities from
    mobile platforms and check out any unforeseen issues pre Alpha-2 and
    were pleasantly surprised that the native code was very close to plug
    and play for mobile platforms (a few changes were needed, we’ll probably
    cover the mobile integration and the journey of bootstrapping with the
    network from mobile platforms in a separate post to not turn this into
    an essay

    1-login3-home5-request-authorisation6-auth-request

    7-email-accounts9-single-account10-single-message11-reply

    Android binaries

    Safe Authenticator ( Andriod ) on github:

    Safe Massages ( Andriod ) github:

    Read Full Article https://safenetforum.org/t/mai...



  • Maidsafe (Maid) Release SAFE Browser v0.5.3

    Change log

    • Remove safe-app dependency
    • Check if webContents is not null after fetching current focused window - fixes #162
    • Authenticator fix for handling multiple Mutable data authorisation request

    SHA-256

    Linux
    FE4D5EE4F966095DFBE8E4E521B17B4967420309A4B86A43C4E3A0C66BF166A5
    OS X
    D01C01BF87D87700A486AADFB6F1CC4A22B6C5EB5588B431CF5E383A868D0FEB
    Win
    06AE230221AD1A38C4ABFA9C5532C770E2F12755E39747759DA0FED024CA90A4
    

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



  • MaidSafe Dev Update - Alpha 2, SAFE Browser v0.6.0 & More

    As you all most likely know this is no ordinary dev update. This update announces the formal launch of Alpha 2! This release is called ‘the Authenticator’ and focuses on the network access mechanism of the same name. The Authenticator makes a number of improvement over its predecessor (the Launcher) not least mobile support in the shape of Android, which we previewed last week, while iOS support is well underway and will be released in the not too distant future.

    The Authenticator, bundled with the SAFE Browser, provides account access control that is now enforced by the network as opposed to the Client. For developers, this release contains more fine-grained access control through the use of smart data types.

    We continue to support the 3 major desktop platforms and the tutorial apps for this release are the Web Hosting Manager and SAFE Mail. In addition, on Android we have the Authenticator and SAFE Messages. These are all available to install directly from our new MaidSafe.net site. As you will notice this is a release specific website and hats off to @shona who came through with the design and @shankar for the very speedy implementation. We hope you like it! As we tick of this next major milestone it would be remiss of us not to thank you all, the SAFE community, who have tested every release we have put out. Your continued feedback is hugely helpful to us. Without the insights this community provides, our releases would not be as usable or as fun to create. Our hats off to each of you from everyone at MaidSafe! This is a new network, so trying to access data from Test 19 won’t work (you will need to create a new account). We are planning to take Test 19 offline this weekend. The number of clients per account that can connect at a time has been increased to 8 clients instead of 4.

    SAFE Browser v0.6.0


    safe-browser

    Changelog

    • Storing history and bookmarks to network
    • UI improvements
    • uses authenticator plugin v0.3.0
    • uses safe-app plugin v0.3.0

    Known limitations

    • Localisation is not supported.
    • Unicode characters are not supported in public IDs, services names, or file names.
    • When there is a network latency the browser can freeze for a few moments while it’s trying to communicate with the network for different operations, like reading/saving bookmarks & history entries, loading a website, etc.

    Example applications

    Please note we are not supporting either localisation for the apps nor Unicode characters in the public IDs, service names, or file names for the web services, although they are supported in email IDs.


    Download SAFE Browser v0.6.0

    Web Hosting Manager v0.4.0

    web-hosting-manager

    Manage web hosted contents in the SAFE Network using the Web Hosting Manager. Create services/websites and upload web content that can be hosted in the network. The hosted services can be viewed using the SAFE Browser.

    When uploading files using Web Hosting Manager, the maximum file size is 20 MB per file.

    Note: To upload a website, you’ll need to upload the files and folders separately. This is because we added support for uploading subdirectories. Ideally, it would be possible to choose both files and folders at the same time, but it looks like Electron doesn’t provide the upload dialog option which will let users choose files and folders. Hence the current mashup of both options. So to upload your website, you might need to first upload the files from the root of the website by selecting all of them via the upload file feature and then choose the folders via the upload directory feature.


    Download Web Hosting Manager v0.4.0 on GitHub

    SAFE Mail Tutorial v0.4.0

    safe-mail-tutorial

    Send secure messages using Messaging/Email Example app between users. Create an ID and send the messages between users from desktop and mobile.


    Download

    SAFE Web API Playground

    The SAFE Web API Playground allows any developer to learn and experiment with the DOM API in a friendly and interactive way.

    It is meant to help people aiming at creating websites/webapps that need to access the SAFE Network DOM API, which is available on the global window object in the SAFE Browser.

    Instead of having to upload your site to the network every time you want to test some code, you can simply use this tool to experiment and get a deeper understanding of how each API works.

    In order to use it, follow the instructions found in its README, and either upload it as a web app using the Web Hosting Manager application or just run it locally and access it from the SAFE Browser using the now supported localhost protocol (see above for details).

    Repository

    Clone

    Mobile examples

    Demo mobile applications that showcase some of the initial key features of the Alpha 2 SAFE Network. For now, only Android is supported in devices. These apps can be used in conjunction with the Alpha 2 desktop apps; the SAFE Browser and the Email/Messaging App.

    SAFE Authenticator

    3-home
    3-home.png1440x2560 76.2 KB

    Download


    • Download 10-single-message
    • 10-single-message.png1440x2560 67.6 KB

      Download

      • Download #support category of this forum.

        For more technical questions (e.g. about the SAFE APIs), please use the #supportSAFE Dev Forum.

        Where should I report issues?

        If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.

        • Report issues with Report issues with Report issues with Report issues with Report issues with Report issues with Report issues with Report issues with

          SAFE Authenticator & API

          The biggest change this week comes to the Web Hosting Manager app, which has been updated and improved by @shankar@shona with a new UI and UX. We’ve included some fixes based on the feedback from the previous release, as well as on findings and feedback from our internal testings performed in the last few days to make sure the new version is as stable as the previous one. We believe this new version is not only nicer but also easier for people who never used the tool or the SAFE Network before, since it provides hints of usage in different parts of the tool.

          @hunterlesterstarter pack13 to help developers get started with building SAFE web apps :slightly_smiling_face:

          We’ve also set up the foundations of a test suite for the browser DOM APIs, which should help prevent problems as things evolve there. @joshuef has been trying to debug and improve the reliability of the authenticator test suite and npm package issues.

          Some minor internal changes which don’t affect the API were made to the safe_app_nodejs package in order to make use of the latest version of the safe_client_libs which includes some minor fixes and several internal enhancements as explained in the next section below.

          During the next few days, we will continue our efforts on automation of tests and artifacts packaging, and we will start reviewing and discussing tasks we have in our backlog to prioritise them and think of enhancements needed for next releases.

          SAFE Client Libs

          Yesterday, we released new versions of SAFE Client Libs: safe_app & safe_authenticator have been updated to 0.4.0, safe_core to 0.27.0, and ffi_utils to 0.3.0. These versions are published on crates.io now and they contain all recent changes in SAFE Client Libs.

          We wrote a couple of NFS tests this week for reading and writing to files in chunks for MAID-2352MAID-2357. We also documented FFI callback parameters throughout our API, making it clear what each variable is, in MAID-2322Issue 445701 to get resolved on the Rust side, but each callback parameter in safe_authenticator and safe_app has also been documented in doc comments. In addition, @marcinC header generation1 and writing missing test cases1) have been reviewed and merged.

          There were many improvements and refactorings that are not visible on the surface (i.e., the API hasn’t been changed). With the help of the front-end team, we also discovered and fixed a bug in the way we handle the Object Cache, the storage tied to the App object that maps object handles to the actual objects. Currently, the Object Cache is implemented as an LRU cache, meaning the stale objects get freed automatically, and it was implemented in the same way in the SAFE Launcher and REST API times. This approach simplified memory management a lot, but nowadays we have switched from the REST API to the FFI API, and memory management became more straightforward. But the Object Cache remains, and the fact that it is limited to 100 entries for each object type can result in some obscure bugs, e.g. when you try to create more than 100 Mutable Data objects at once. We fixed this by raising that limit to 1000 entries temporarily, and we’ll be looking into resolving this problem in a more general way by switching from the LRU cache to a plain HashMap, thus making it the front-end apps’ responsibility to free stale objects and prevent memory leaks (and the Node.js library already does that, so it should not affect it). Also, @adam found that some FFI functions miss the catch_unwind wrapper, which could have resulted in Rust panics not caught and propagated to FFI - or, in simple words, in crashing apps and the browser. This issue is fixed by this PR.

          We improved error reporting for account creation, to help the user better determine the actions to take to recover from the error. We also fixed a couple of minor bugs that manifested themselves only on the nightly compiler. This compiler is used by docs.rs1 to generate the API docs, so by fixing those bugs, the docs are now being generated again.

          Routing, Vault & Crust

          Work this week has again been focused primarily on the design of the message flow. Several ideas have been explored and a lot of effort has gone into finding flaws in these and looking for ones with the potential for later optimisations. A long-standing idea to use a form of Information Dispersal Algorithm to increase the efficiency of message-passing (and perhaps also data-storage) is being explored further. There are still some unresolved issues around this proposal, but we’re hopeful that these can be addressed since the apparent benefits of this approach would be fairly significant.

          Over the last couple of weeks, we’ve been improving our implementation of uTP (BitTorrent’s micro transport protocol). It’s now in a usable state and work has now begun on integrating it into Crust. At the moment, this means seeing how our existing code can be refactored as Tokio-style state machines, starting with our NAT traversal library.




  • [wanted] Developer for new SAFE project!

    https://safenetforum.org/t/wan...



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