Here are some of the main things to highlight this week:
- Following the release of the safenetwork.tech website last week we have been working through updates and suggestions posted by the community. This is an ongoing process so please continue to add any comments or issues into the GitHub repo.
- A new version of the
safe_app_nodejspackage will be released shortly in the next few days which incorporates all changes we’ve been working on during the last few months. We will also be updating our Electron app tutorial on the DevHub website so it can be used with this latest version of the safe_app_nodejs package. - We have been working hard at specifying the scope of an FFI version of the API in the PARSEC crate. We have defined the parameters of what we want the API to look like and are beginning the implementation soon. We plan to have support for C, C++, Java, and C# language bindings for the PARSEC API.
- The Routing team is very happy to welcome Jon Häggblad in our midst. Jon has a PhD in mathematics and experience with C++. He will be joining our team as one more remote worker from Sweden. Feel free to read his introduction blog post on Medium and to clap and share as always
Welcome to MaidSafe, Jon 
- Planning for Parsec’s second milestone has been at the forefront of the efforts this week. We’ve had several team meetings where we discussed various approaches to handling dynamic membership and malicious behaviour. This has allowed us to start getting some more meat on the bones of our high-level todo list before we can finally get the real low-level tasks specced out and entered into Jira. The current discussions are largely focused around resolving some of the natural tension that exists between Routing and Parsec, in terms of keeping an appropriate degree of separation between these two libraries.
- The majority of this week was spent on Crust and SAFE Crypto integration into Routing. We hit some bumps here and there but finally got the build and tests passing. Next step is to integrate this updated Routing version into Vaults and run our end-to-end tests on an internal test network.
Marketing
Decentralised Exchanges
This week the Marketing team has been working across a variety of projects. As you have probably seen we posted a new Medium article this week outlining how we plan to push forward our relationships with decentralised exchanges. Safecoin remains our ultimate goal but we are aware that the liquidity of our OMNI token MaidSafeCoin is important to current users. Currently, MaidSafeCoin is available on a number of centralised exchanges but we have recently become concerned at the level of control that these type of centralised authorities can exert over users and as such are exploring new opportunities on decentralised exchanges. Initially, we have chosen to provide liquidity on openledger.io as it ticks many of the boxes around users anonymity, security and an open source code base. This does not mean that we are moving away from centralised exchanges as we know many users value the user-friendly design and support tools.
SAFE Network Website
Following the release of the safenetwork.tech website last week we have been working through updates and suggestions posted by the community. This is an ongoing process so please continue to add any comments or issues into the GitHub repo.
Chicago Meetup
Special thanks to @sotros25 for the first Chicago Meetup that successfully took place last weekend. She was joined by an enthusiastic audience to learn more about the Network as well as a presentation Q&A with @nbaksalyar. We look forward to seeing many more meetups across the world very soon - if you would like to host a meetup this post will give you all the information you will need.
Decentralized Web Summit
MaidSafe is sponsoring this year’s Decentralized Web Summit and next week some of the team will travel to San Francisco to attend and present at the Summit. Our talk will take place at 2pm (PST) on Wednesday the 1st of August and will be livestreamed for anyone not able to join us and we will share these details as soon as possible.
User Experience & Website Design
So we’ve been and done it. The new SAFE Network website is packaged and delivered.
After a false start with an external agency, we made the call to design, write, and develop this entirely in-house. So it means we are best positioned to be able to walk you through the priorities, motivation, and rationale behind it, and where we go from here.
Big back-slappy thanks to everyone who has taken the time to offer feedback, critique, praise, or incorrect opinions (just kidding). We’re glad you did.
So what was the purpose of the project?
What even is this website for?
This site is first and foremost about the SAFE Network itself. It’s a marketing tool to pitch, explain, and promote the project, and its aims. It also aims to encourage people to get involved, help create, test, and become advocates, or heck, even evangelists.
It’ll be the primary entry point, or certainly a key step, into awareness and understanding of the Network and its implications.
Another clear aim is to separate out the project from MaidSafe the company.
The SAFE Network is, and always will be, owned by and for the benefit of the community, and humanity. Conflation of MaidSafe the company and the project itself has hampered us to some degree, so this is an opportunity to make clear the distinction and put the Network front and centre.
Who is the website for?
The SAFE Network is, by its very nature, aimed at changing the way we are all able to communicate and collaborate. If it fulfils its aims then its user-base will be broad and deep, covering all demographics and populations.
But there is a road we have to travel to get there—a line we have to tread—toward the tipping point of users necessary for us to be able to claim success.
That involves being measured and precise in our communication, having a target audience in mind, and talking to them directly. There are many ways to tell a story, how do we choose how to unpack and explain a complex, multifaceted endeavour? A target of ‘everyone’ is no target at all, so we’ve narrowed the focus down to three key groups:
- The privacy and freedom focused early adopters
- The crypto crowd
- Journalists and writers
This allowed us to move on through the research, discovery, and ideation phases with the end user in the forefront of our minds, and to build a common understanding of who we are communicating with.
These target groups were further analysed through some mild focus grouping (kudos to anyone who showed up in these groups: Cheque’s in the post, natch) and pen portraits constructed and disseminated.
The discovery phase meant performing analysis of other projects in the same and adjacent spaces, together with building a picture of the language and motivations of our audience. What drives them, what world do they inhabit?
Information Architecture
With these reference points, we began the other half of the dealio: what and how to communicate. So in parallel, we began getting into the nitty-gritty of the message we’re about to send.
Information Architecture work involves delving deep into what we say, how we structure and organise it, from what perspective and starting point so we unfold the story. It involves an unhealthy amount of post-it notes, and then moves on through higher fidelity maps and structures. It’s from this point we can put pen to paper with a plan.
It was through this whole process that we began to establish that not only do we need to adequately describe the uniqueness of technological heroics that underpins SAFE, but we need to serve up the benefits and broad implications of the Network. The scale of the thing. I hope we’ve made a leap forward in doing that.
Visual Language
Alongside this then began the process of constructing a visual language for the site. What are we communicating when we don’t use words? What do we want our audience to feel?
We went through a moodboarding process—that’s designer talk for a method of capturing stimulus and descriptive vignettes—a communication tool to have a common understanding of aesthetic direction and help steer design direction.
Themes and cues that were developed and explored were:
Nature, Vibrant, Understandable, Clean, Human, Ordered, Different.
This was with the understanding that “…differentiation must be both visual and in the messaging”
and that
“…the design of the Network has taken cues from organisational structures in nature. Especially related to the lack of centralised authority and yet highly organised world of ants.”
This direction together with the moodboard allowed us to set up a hybrid moodboard and style guide—a styleboard if you will—to act as a reference point for the detailed design phase to come.
I’ll share some of the output of that with you now:
Inspiration
As a starting point, we began looking at natural colour, textures, and form. There’s actually a richness like this all around you if you look closely. And that includes the MaidSafe office which has recently undergone a similar process of design transformation.
It’s a great starting point; and one which was documented with some photography above.
Colour
With the photography as a jumping-off point, we pulled out a versatile and vibrant palette that will be cohesive, usable and keep us distinct enough from the competition.
The main highlight colours work well with the core—chosen for clean and readable type.
We also provided for the use of complementary colours that work alongside imagery and the main palette, to add variety, flexibility, and impact.
It’s also worth noting we’ve taken a deliberate step away from the MaidSafe brand colours of old, in order to make the project more distinct from the company, and also to move away from what was quite a corporate and dare I say accountancy-blue.
We also did a detailed colour wheel analysis of other similar projects, together with familiar web brands, to find them dominated by these blues. Dreary, dreary blues.
Fonts
We looked for clear, distinct, and readable fonts that can match—and better—the professionalism of our competitors chums.
A strong sans-serif display for headlines is a natural choice, but we’ve chosen one with humanist elements, to take off the corporate edge some others suffer from.
We’ve also chosen a serif for body copy that is beautifully readable and yet with warm and natural elements. Again, differentiating ourselves from the competition, while still being clear and precise.
Finally, another sans-serif that is useful for longer titles than a display font like Halis Rounded might handle, which is also geometrically precise enough to be used for navigation and UI elements… still with humanist touches though.
Natural Textures
To support the vision, and inspiration for the SAFE Network, we’ve included natural elements and textures to the design.
Using direct allegories in the form of stock photography could feel hackneyed, so we explored the use of background looping videos to provide texture, and interest. A nod to nature, supporting the main content, rather than directly forming it.
Small slices of video, knocked out text, and other abstract elements.
In the end, due to the relentless march of time, we were only able to provide for still imagery in the first iteration of the site. We’d still like to include motion in the future, but we’ll be dialling it in with care, so as not to overwhelm.
Patterns
Describing some of the concepts of the network can be hard, and can be asking a lot of imagery and illustration, which can often end up being overly complex, or too clinical. The burden can also increase delivery times too, if they are relied on too much.
So we’ve explored the use of abstract geometric patterns as a way to support and enhance messaging.
Inspired by mono prints, they’ll have more human qualities and’ll have the advantage of exploring natural themes—like ant problem solving—without feeling creepy in the way photography would.
We’ll doubtless still have the need for direct illustration, but that is something we can explore and develop over time, with an aesthetic that will play well alongside these other elements.
Typographic Grid
To bring order, structure, consistency, and readability to our layouts we use a carefully tailored typographic grid.
But to add interest and vibrancy, and avoid aesthetically sterile designs, we’ve pursued ‘broken grid’ patterns. It’s also a cheeky nod to the chunked nature of data on SAFE, and their magic reassembly via naturally inspired structures.
Despite the name, these designs are underpinned by a regimented grid system, but clever element positioning and the use of colour and depth allow for more interesting layouts.
Bringing it all together
So it’s by combining all these elements from the IA, content, and visual language, that we arrived at the design and layouts that you now behold.
For some, it was an instant hit, for others quite jarring. We get that. And it’s something we went into with our eyes open, and not just because we could. We’re striking a balance here, we’re not aiming to alienate, or sacrifice usability simply, or to be different for difference’s sake.
The clearnet—the ‘platform-ed web’ as it has become—is increasingly homogenised. Vibrancy, vitality and originality is often lost for the sake of convenience, speed of development, or the desire to create familiar experiences.
You can see why brands and platforms would seek this, it’s comforting and understandable for the user. But when you are creating the new Internet, you don’t really want the new boss to be same as the old boss, right?
The new web should be different. And maybe it should feel different too. Much of the joy, excitement, and humanity has been sucked out of the Internet. And from a design perspective, perhaps some of blame lies with centralised design systems, or corporate culture. I sometimes pine for the days of individuals banging out Geocities sites, teenagers bending an HTML table to pimp-out their MySpace.
There’s an underground, vital, and organic, and non-homogenous nature to this project that needed to be told through the design.
We hope, and intend, that the new Internet will be usable, and understandable. But decentralisation by its nature will break a few things—and be uncomfortable. I for one don’t want the comfort blanket of the status quo… and when the wraps come off of the SAFE Network, I hope it is as challenging as it is creative as it is useful.
So where to from here?
Over the coming months, we’ll be putting together a new website for MaidSafe. A much stripped back version, focused on the company itself, now that the SAFE Network site is doing all the heavy lifting. We’ll be dropping in a stopgap solution in the coming days while we design and build the replacement.
On top of that, we’ll be continuing to roll out improvements to the main site. Many of the interaction elements for example—like micro-interactions and transitions—in the original design were a step too far for the initial launch. Being firm believers in not letting the perfect be the enemy of the good, we’re taking a continuous improvement approach to the site.
On top of that we’ll be building out the FAQ section into a fuller, more detailed, and deeper diving learning resource that will be a real asset.
SAFE API & Apps
We are working on SafeAuthenticator test suites (branch) to ensure the functionality of safe_auth native bindings in C#. These tests will be a part of CI setup.
We are adding XML comments in safe_app_csharp (branch). These comments will be used to generate the API documentation. We are looking forward to releasing the API docs soon.
The safe_app_java library’s freezing issue has been solved and we now have consistent results with the unit tests. An issue with the dynamic linking of the shared dependencies has been uncovered and is currently being investigated in detail. The Android platform is quite strict at the JNI layer and has also been keeping us on our toes.
A new version of the safe_app_nodejs package will be released shortly in the next few days which incorporates all changes we’ve been working on during the last few months. We will also be updating our Electron app tutorial on the DevHub website so it can be used with this latest version of the safe_app_nodejs package.
We’ll be sharing more on the work we’ve been doing with Peruse and WebIds soon. (We’re making a couple of minor tweaks for compatibility). As some have noted, a wild repo appeared! These will be filled up soon enough!
This is going to be something still in its early stage with some limitations and known issues, but we believe it’s important to get feedback from the community as well as help with testing it. They are proof of concepts which aim is to help us understand better the direction we should take for our data representation, and users identity management, and how we can aid developers to create applications aligned with this approach.
SAFE Client Libs
We have been working hard at specifying the scope of an FFI version of the API in the PARSEC crate. We have defined the parameters of what we want the API to look like and are beginning the implementation soon. The API will have some similarities to the SAFE App FFI such as similar naming schemes and error handling, which should make it familiar to some of our users. However, one major difference is that the PARSEC FFI will be synchronous and so will not have callbacks. We intend to make changes to our bindings generator to cater for this convention and generate C headers. With this, we plan to have support for C, C++, Java, and C# language bindings for the PARSEC API.
We’re also starting to plan improvements for another of our libraries soon: System URI currently lacks a convenient API for Rust app developers. Our intent here is to make it as simple to use as with Node.js apps, while maintaining the crate’s cross-platform compatibility.
Routing
The Routing team is very happy to welcome Jon Häggblad in our midst. Jon has a PhD in mathematics and experience with C++. He will be joining our team as one more remote worker from Sweden. Feel free to read his introduction blog post on Medium and to clap and share as always Welcome to MaidSafe, Jon
Planning for Parsec’s second milestone has been at the forefront of the efforts this week. We’ve had several team meetings where we discussed various approaches to handling dynamic membership and malicious behaviour. This has allowed us to start getting some more meat on the bones of our high-level todo list before we can finally get the real low-level tasks specced out and entered into Jira. The current discussions are largely focused around resolving some of the natural tension that exists between Routing and Parsec, in terms of keeping an appropriate degree of separation between these two libraries.
For example, two peers communicating between each other will send messages via the Routing layer. Routing will then see if an incoming message is a Parsec-level request or response, and will pass it down to Parsec to deal with. Routing doesn’t want or need to know the internals of those messages. If a new peer joins the section, its Routing that handles the bulk of that logic (e.g. does the new peer’s address fit? did it pass resource-proofing?), culminating in Routing voting to accept the new peer. This means Routing makes a vote for add_peer and gives this to Parsec to get on with gossiping it to our peers, and telling us once enough peers have cast the same vote to make the new peer actually accepted into our section. Parsec doesn’t need or want to know all the accompanying work Routing has done to check the new peer should be accepted - it just gets the vote from Routing and spreads it around.
Of course, adding a peer is just one example of what Routing can vote for. We had been aiming to keep Parsec totally unaware of any of the vote types, but it seems to make sense to have Parsec able to see the add_peer and remove_peer votes so that it can act upon these without having to be told to do so by Routing. This seems like it’s starting to couple Routing and Parsec together, and coupling code together is normally a bad thing, so we’re naturally spending quite a bit of time to make sure that we aren’t actually coupling needlessly here; that this is indeed the cleanest, simplest approach.
We’ve also been trialing out Proptest as a means to improve our test coverage of Parsec. It is a framework that enables property-based testing, that is, it is a way of checking that the code satisfies some properties. It runs given tests on a range of inputs, generated according to a “strategy”, and if it finds a failure, it attempts to find a minimal example.
@bart has made good progress here, starting with an excellent refactoring of our existing tests, and is fairly confident that this will be a most useful addition to the test suite. Until now, the tests were simply executing some random operations in a simulated network. After the changes, they generate a schedule of the operations, and only execute it afterwards. While seemingly an insignificant change, it will be important for leveraging Proptest’s automatic simplification of test cases: it will be possible to simplify the schedules by removing some operations, but the rest of them and their pattern will stay the same. A nice side-effect is that it makes the tests’ code simpler.
We were disappointed to learn that our submission of the Parsec whitepaper to the Crypto-Economics Security Conference was rejected 
. The good news is that the rejection report indicated that two expert reviewers voted to accept it, while the one who rejected it voted for a weak rejection based on the difficulty to actually evaluate the submission. As a team, we recognize that failure can be valuable when it is used as a tool to learn, so we’ve taken this opportunity to improve the paper: we have added a couple of tasks incorporating the negative feedback into the Milestone 2 target.
We have also submitted the PARSEC whitepaper to the Stanford Blockchain Conference 2019 that will take place January 30th to February 1st 2019. With the deadline for edits on the 16th of October 2018, we will have time to incorporate the feedback from the CESC review to present our innovation in a better light and hopefully have a higher chance of our submission being accepted.
Crust
The majority of this week was spent on Crust and SAFE Crypto integration into Routing. We hit some bumps here and there but finally got the build and tests passing. Next step is to integrate this updated Routing version into Vaults and run our end-to-end tests on an internal test network. Fingers crossed we won’t witness any regression 
. One caveat at this point though is that there is some work planned on the safe_crypto crate itself for exposing functionality for not just routing, crust and other backend libraries but also for frontend libraries and apps which will consume it indirectly via safe_client_libs FFI. This might alter the design of safe_crypto and create a little more work in the crust-routing integration once completed.
We also discovered several bugs in tokio-utp. One problem was that the connection shutdownFin packet was only acknowledged by State packets, which didn’t comply with the specs. Other data packets can also acknowledge Fin packets. The other problem was also related to connection shutdown: a connection would be immediately closed after a State packet, that meant to acknowledge a Fin packet, was sent. Sometimes, as any other, State packets can be lost. In such cases, the remote peer would just keep hanging until connection timed out. Instead, we made sure the State packet gets resent if needed. Both fixes are still being reviewed but overall it looks good 
It was netsim that helped us discover those bugs: we have several Crust tests with introduced packet loss. To have even more control over network packets we did some more changes in netsim. A new version was published that allows us to interact with simulated network devices using Stream/Sink traits from futures crate. Now it’s possible to modify, filter, etc. IPv4 packets as they travel inside the simulated network.
