Today we are releasing a new/updated dev tutorial 
We now have enabled two comments plugins: one for permanent comments and the other for editable comments. Both plugins let people comment on content using their public name. They also enable the website owner to delete comments and block users.
The difference compared to the previous dev tutorial is that users now have the ability to update their own comments and to see the history of other comments when a website is using the Editable Comments Plugin.
The Editable Comments Plugin stores the comments using versioned structured data. This enables the plugin to fetch all the previous versions of a comment and display them in a modal window.
Since the Editable Comments Plugin shares a lot of code with the Permanent Comments Plugin, we decided to explain both using the same dev tutorial. Two new pages were added (Edit a comment and Fetch comment history) and some pages were updated to explain the differences between the two comments plugins (Fetch comments and Add a comment).
Also, the Permanent Comments Plugin was updated to use immutable data instead of structured data. Now, once a comment is posted, it can’t be edited (immutable data doesn’t have any owner). Previously, the comments were stored using structured data because the APIs for immutable data hadn’t been exposed in the SAFE Browser yet.
We are releasing this new tutorial as part of TEST 11. This test network supports the new deletion paradigm for Structured Data. See this Dev Forum topic for more details. Also, size checks are now enforced by the vaults (100 KiB for Structured Data and 1 MB for Immutable Data). To connect to TEST 11, you need to use SAFE Launcher v0.9.2.
We are planning to bring TEST 10 down tomorrow.
SAFE Launcher v0.9.2
Each client account is limited to 500 PUTs. A PUT is a request to store a single chunk on the network (a file may contain many chunks). The maximum chunk size is 1 MB.
Please be aware that this test network will be reset periodically, wiping all data that is stored on it. We will announce this in a Dev Update (when possible) prior to taking it down.
Download
Documentation
Changelog
- Requires safe_core 0.22.0
- Versioned StructuredData API exposed to read a specific version
- StructuredData Delete APIs exposed
- API to validate size of StructuredData and ImmutableData added
- Minor bug fixes
Known limitations
- Only Rust logs are created. UI logs are currently disabled.
- The dashboard UI update is not consistent and the graphs are not reliable.
- Account storage section in dashboard has a typo and displays invalid date label.
SAFE Comment Tutorial samples
Enable comments on your SAFE website!
The new API functionalities of SAFE Launcher enable developers to build apps with dynamic content. To showcase these features we are providing a tutorial that enables users to comment on content using their public name. This tutorial uses Public Appendable Data. Website owners can delete comments and block/unblock users. The ability to block users is enabled by the filter field of Appendable Data. For this tutorial, we use a blacklist (as opposed to a whitelist). Everyone except the keys (people) listed in the filter will be allowed to comment (append data).
Download
Tutorial
SAFE Demo App v0.6.1
You can continue to use the same binaries as TEST 10, the demo app hasn’t been updated. You need to use SAFE Demo App in order to upload the SAFE Comment Tutorial samples.
When uploading files using SAFE Demo App, the maximum file size is 25 MB per file.
Download
Documentation
SAFE Browser v0.3.5
You need to use the new version of SAFE Browser (v0.3.5) in order to interact with the SAFE Comment Tutorial samples.
Download
Documentation
SAFE Mail Tutorial v0.1.2
We had to fix a minor bug, so you need to use the new version (v0.1.2).
An example of an email app skeleton to allow developers to pick it up and add some basic functionality for a fully working email MVP. Then add further functionality using the APIs described in this tutorial, to make amazing communication tools in SAFE. We have tried very hard to not make a user-facing app as we want developers to see this as a tutorial and know they have everything they need for communications apps in SAFE and a bit more.
Download
Tutorial
Changelog
- Unversioned Tag Type Corrected
- Compatible with launcher version 0.9.2
Support
If you need help with anything related to SAFE Launcher or SAFE Demo App, please use the #support category on the forum.
If you need help with anything related to SAFE Comment Tutorial or SAFE Mail Tutorial, please use the #support category of the SAFE 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 SAFE Launcher
- Report issues with SAFE Demo App, SAFE Comment Tutorial or SAFE Mail Tutorial
- Report issues with SAFE Browser
If you’re not sure where to open an issue, you can simply create a new topic on this forum and add the #bug tag. @lightyear and I are subscribed to the #bug tag, so we will automatically receive a notification whenever someone adds the #bug tag to any topic. We’ll take care of opening an issue on GitHub if necessary.
If an issue is specifically related to the SAFE API, then it makes sense to use the SAFE Dev Forum. But for issues related to end-user applications (e.g. SAFE Launcher, SAFE Demo App, SAFE Browser, etc.), it’s fine to use this forum (safenetforum.org). Most users already have an account here 
SAFE Launcher
We will continue the discussion about the future of SAFE Launcher this week.
The approaches we have narrowed down for app authentication favor support of mobile clients. We want to ensure that Launcher / Authenticator or whatever it’s called can work on mobile, desktop…etc… We also found an approach that will help us speed up the deployment to mobile, however, there are still a few missing things that we need to figure out in terms of app permissions and app management. We want to choose a solution that provides a good user experience and won’t annoy users with lots of authorization prompts (also know as “auth fatigue” 
)
Once that part is done, we will present a summary of the discussion to the Dev Forum. The ideas presented will still be open to debate by the community and we’d love to hear your thoughts and feedback once we post that topic 
We will then write an RFC that explains the changes.
SAFE Core
Many changes to support the new delete paradigm (including making a StructuredData unclaimable) have been put and tested in safe_core. Some new scenarios have come up due to the way users delete SD, such as sending a POST request to a deleted data or re-deleting a deleted data…etc… These required appropriate errors and test cases which have now been incorporated into the code.
New APIs are now exposed for claiming a deleted data and making an SD unclaimable.
The work for async safe core is progressing in parallel and will take some time to complete.
Routing & Vault
Last week, we had two full days of discussions about measures to make the network more resilient and stable enough to let users run vaults from home again, and how to securely send group messages across the network with the new group definition without causing a performance regression.
The core part of the Disjoint Groups implementation (but not yet the new message routing - see below) is nearing completion, and we have started adapting the network tests to it. This week, we will start debugging it and make the basic network functionality work based on the new paradigm.
After that, we will implement the new group message routing mechanism. It will be slightly different from the one specified in the RFC, however, delivering the same level of security but without the huge increase in the number of hops or hop messages.
We also agreed to move forward with the Node Ageing RFC. Before we start with its implementation, however, we will create a simple simulation to get a better estimate for the parameters (quorum size, group size, etc.) that will be needed to secure the network against certain attacks.
Dev Outreach
Work on dev outreach continues, and in addition to MaidSafe speaking at Bitcoin Wednesday on the 7th of December, @lightyear is also working on getting dev meetups started in 2 of Europe’s most influential tech cities, Amsterdam and Ben’s home town Berlin.
The event in Amsterdam will be around the 7th of December so your help and ideas to promote this event would be appreciated. Maybe you are aware of other like minded groups in the area that we can partner with, or maybe you are from the area and are tapped into a local group of developers. If you are a developer and are from, or can get to either of these areas please sign up via meetup.com for more information.
Recruitment
With further funding now in place and the 4 developers hired during September/October settling in well, MaidSafe are once again screening CVs and preparing for another round of code challenges and interviews. The current focus is for Rust Engineers and Full Stack Developers. Scaling the team with the right individuals will obviously enable the velocity of development to increase and as the company grows during the remainder of this year and into 2017, expect additional roles to become available.
. Most of them will bite through, but still…
