Here are some of the main things to highlight this week:
- Yesterday, we released a new video that explains how the SAFE Network differs from blockchain-based solutions.
- The poll for choosing a proposal for the Safecoin Video Animation CEP is closing tomorrow. Forum users who are at trust level 1 and above can vote here.
- The Marketing team has created a new Medium publication (safenetwork – Medium) 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 2018, 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 yesterday. 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 (safenetwork – Medium) 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/safenetwork. 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/safenetwork.
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 Home - Documentation.
@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 branch.
SAFE Client Libs
A couple of obscure bugs have been reported by the community 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 chat working - no intermediate servers, obscure cloud services, APIs, etc. just real, old-school networking 
can’t wait for peruse! Hope it has ahem streaming support ahem 
cheers 
(It’s outrageous that there is no moth emoji)