Development

Community Engagement Program

We are happy to announce the Community Engagement Program (CEP). The purpose of this process is to match developers with immediate and fundamental SAFE Network requirements. This will take the form of a community funded ‘Kickstarter’ like process to encourage teams to bid for projects, accessing part of the 5 million available MAID fund for bounties, community projects…etc…put forward within the MaidSafeCoin announcement.

Each project will be identified up front as being in demand and then teams (or individuals) will propose a costed solution (in MaidSafeCoin) for each small proposal. It is anticipated that these will be mostly small (6 weeks or less) projects and will primarily cover end user applications, but may also include core components.

This proposed process is essentially an experiment to see if this way of working is both effective and scalable moving forward, only by running/cycling through this way of working will we truly understand its feasibility. The CEP will not replace the bounty program, which is more effective for smaller and specific pieces of work.

Applicants will be responding to a set of requirements established initially by MaidSafe and adapted to take into account community feedback. The community themselves will of course complement and expand on this process as it becomes more established, incorporating community based proposals. It is the intention that CEP projects will be 50% funded (in MaidSafeCoin) by MaidSafe and 50% by the community. If projects achieve less than 100% of the projected costs, it is up to them if they proceed. MaidSafe will assign a member of the company, whose skills and experience best suit the project, to oversee and act as the main point of contact. The following forum post explains the process in more detail.

The first project MaidSafe are seeking proposals for is a SAFE Network browser that is able to render standard web content and also enable web applications to invoke the APIs exposed by the Launcher. A mechanism to provide SAFE-only URLs as well as html…etc… is expected.  We would love to have your proposals, please submit them to the proposals category within the forum.

Good luck!

The SAFE Network Release Cycle

As you may have gathered from the even greater amount of activity on GitHub (I didn’t think it was possible either) the core of the SAFE Network has been getting tested both internally and externally as we get ever closer to a stable decentralised network.  While details about the team’s development progress continue to flow via the forum, the purpose of this post is to establish the main phases of the impending and iterative release process. There are:

  • Alpha – the core network and fundamental functionality is provided via an initial implementation, this is the first public testing phase.
  • Beta – alpha implementations are reiterated and improved, based on user feedback.
  • Release candidate – the fundamental feature set is stabilised to provide greater security, resilience and efficiency.
  • Release – privacy, security, freedom!

The speed at which MaidSafe will iterate through the alpha testing phase is unknown and will be dependent upon how well the network performs at this stage. However, it is anticipated that having the core network in place will make it significantly easier to test the addition of new features than ever before. Testing against mock networks is only useful up to a point!

There will be several alpha releases, which will commence in simple numerical order, each denoting an incremental improvement on the previous version. For example, as per the roadmap, alpha 1 will come with: public ID management, public and private data storage, vault configuration and desktop installers (64 bit Windows, Mac and Linux). The second alpha iteration will include additional features and will be called alpha 2, and so on.

SAFE Network Fundamentals

The fundamental features, beyond the alpha 1 release, have been defined as:

  • Contact management
  • Messaging
  • Test safecoin
  • Vaults running on ARM architectures
  • Launcher UI
  • Safecoin wallet

The alpha release will gradually implement this functionality in an iterative cycle and provide the features highlighted above. However, this will be the first iteration of these features and development on them will continue until the engineering team are satisfied that the implementation provides the desired functionality. At this point, the network will transition to beta. When in beta, these features will become more elegant, efficient and secure. The release candidate will see the features frozen and further stabilised prior to full release at which point safecoin will go live.

In tandem with this release cycle, both users and developers can expect the ongoing release of APIs that reflect access to ever increasing network functionality, as well as example applications that showcase features of the network to end users and also act as tutorials to developers.

Out of Beta and Moving Forward

Beyond release MaidSafe, either alone or working in partnership with other developers, will start to create some of features below that will offer both developers and end users access to some exciting new tools, such as:

  • Pay the producer
  • Smart contracts
  • Autonomous updates
  • Computation handling

We will provide you with more details on each release as it approaches and hopefully this post has been useful in providing more detail around our planned release cycle.

Glocalization of Internet Freedom

For the first week of March several hundred internet freedom activists from all around the world gathered for the Internet Freedom Festival in the Las Naves collaborative space in Valencia, Spain for a wide variety of sessions addressing tools, policies and perspectives within privacy and security on the Internet. Trainers, developers, journalists, technologists and those simply curious to learn from 76 countries traded perspectives and skills while forming bonds to continue collaboration post-festival and strengthen support for each others work. Previously named the “Circumvention Tech Festival”, the event organizers placed a strong emphasis on creating a safe space for open collaboration without compromising privacy and identity for those attending at the risk of local oppressive governments learning of certain individual’s attendance. A strict no photography rule was set in place in addition to the Chatham House rule (not referring to identities in referencing quotes or points individuals made) for note taking and general future discussion of the topics presented. Attention was also put on meeting other attendees through prioritizing sessions with discussion and collaborative activities. Session topics ranged from threat modeling through holistic risk analysis to community networks and the process of flashing routers to build a mesh. The entire festival offered a beating pulse of local perspectives on digital privacy and security while simultaneously highlighting the need for global collaboration in regards to building tools, advocating policy and strengthening communications within this community and beyond.

The concept of “glocalization” which permeated throughout the event was perfectly introduced to me in the first session that I attended at the festival; Glocalization for Noobs: How to Design Tools for a Global Audience where panelists discussed and advocated for integrating the process of translation more tightly into software development. They discussed the translation of software going beyond localizing text and taking into consideration the entire user experience from perspectives of various regions. While many products are marketed towards specific areas, most software is used globally, or at the least have potential for wider adoption and would benefit from the review of testers in various locales. Importance on focusing attention on region specific points of view continued throughout the event where a handful of meetups dedicated time to discussing the state of Internet security and surveillance in Latin America, Africa and the Middle East. Sessions also incorporated this focus recognizing and addressing the particular hurdles of regions. The session Network disconnections: Effects on Civil and Trade Rights included a short presentation on the regular disruptions in internet access people in Pakistan face and subsequent research followed by a general discussion about the broader topic of region-wide disruptions usually due to political pressure and what policy and economic arguments can be made in opposition. Other sessions focused on the general sense of considering global communities and allowing respective perspectives to be shared together. Privacy Across Cultures was dedicated to a discussion on what the impact of privacy and its absence has meant in various cultures beyond freedom of expression and focusing on more long term effects.

Beyond the diverse cultural representation at the event, there was also a wide array of representatives from tools, new and old. In one workshop session titled Deploy an emergency Libre-Mesh network with local services, we formed in small groups and flashed routers with libre-mesh to form a p2p network. It was one of the fastest and most simple efforts of flashing a router to build a mesh network that I’ve ever experienced – it took about 30 minutes total for all 7 groups (with a range of familiarity of flashing routers) to connect with each other. If mesh networks are something of interest to you or your community, I highly recommend checking out libre-mesh. Additionally, one of the evening’s featured a tool showcase of 15 technologies ranging from a service called Stingwatch for detecting and reporting locations of Stingrays (fake cellphone towers used by authorities for tracking individuals) to the more well known Freedombox (security and privacy focused software for personal servers). Unfortunately, I was not privy to this portion of the event beforehand and not aware of the status of the MVP launch, else I would have loved to participate and demo the SAFE network to the crowd. Alas, I was able to do so in a more intimate setting for a session of it’s own. Having attended the festival with the intention of presenting a more general session on improving communications on network topologies and ownership infrastructures (based on previous explorations of the topic), I was able to join several dozen others who created “self-organized” sessions which were added in the schedule as the week progressed. This session was much less interactive other than various questions from participants but because we have software to show now, I was able to finish the presentation with a successful demo of the SAFE Launcher and example app to a crowd for the first time!

Overall, the Internet Freedom Festival was a huge success from a personal perspective by highlighting a variety of topics from technology to communications and diversity. To achieve true internet freedom worldwide, we must consider localized efforts and understand that needs vary from region to region by listening rather than assuming. Digital security training has expanded throughout the world and understanding the array of obstacles that regions face will help us build better software. I feel confident that the SAFE network will be a strong example of building a diverse, global community (as we see it happening already) but also appreciate the strong reminder that this will happen much more efficiently if we put effort towards diversifying our perspective. While the MaidSafe core team has a regionally diverse team itself, community-based development and translation efforts will continue be essential if we want to make SAFE a truly global network. I really look forward to attending Internet Freedom Festival again next year with a proper SAFE network up and running while expanding my understanding even more to make the network accessible to more people (and hopefully capture a few other team members to attend as well).

MaidSafe Development Update

Hello, my name is Ross and I have been part of the MaidSafe team for over 2 years. Until recently, this was within QA; my job has now transitioned into a more customer support focused role and is still evolving as we grow as a company. SAFE forum regulars will know me best for collating and sharing the team’s weekly development updates. I am aware not everyone has the time or the inclination to regularly check the community forum, so I thought it would be useful to provide a less technical overview of our development progress during the last few months, here in the blog.

All of our energy and effort in the last few months has been focused upon delivering a Minimum Viable Product (MVP) as quickly as possible. What will the MVP look like and what will you be able to do with it? The MVP will enable users to install the software and connect to the network from their computer, store and retrieve files, browse sites hosted on the SAFE Network and message other users. Subsequent development sprints will see the addition of other extremely important features, such as Safecoin. We are very close to delivering the MVP and depending on which core developer you speak to, this can be measured in either days or weeks. We are aware that we have been ‘almost there’ for a while now, so allow me to update you specifically on our progress within our core libraries and hopefully this will allow you to come to an informed conclusion yourself.

A huge amount of effort and resource has gone into the core Routing and Crust libraries over the last couple of months. 75% of our engineering capacity has been focused on collating feedback from testing, peer programming to redress unanticipated observed behaviour and delivering a stable, functioning network that behaves as expected. At the same time both of these libraries have been heavily refactored; code refactoring means restructuring / reducing complexity within the code base, without changing the overall logic or behaviour of the code. Within Crust itself the library has been broken down into smaller modules called crates:

rust-utp – a crate that enables you to connect to the network from wherever you are.
service_discovery – discover other instances of your application on the local network.
config_file_handler – create, read and write configuration files.
crust (slimmed down and safer) – reliable peer to peer network connections. One of the most needed libraries for any server-less, decentralised project.

The guys have also been working on simplifying Crust’s API (application program interface) to make it more user-friendly and generally easier to integrate with. Routing was stabilised to allow the dependent crates (all the client modules) to utilise its functionality and interact with it more easily. Both libraries were also thoroughly documented during this period, which is essential for third party developers wanting to build upon the SAFE network.

Meanwhile, the Client guys have been working in parallel getting the upper layers prepared for the release of a stable base, focusing on the Launcher, creating solutions to allow users to bridge seamlessly between the old internet and the new SAFE network and beginning work on real end-user SAFE apps. Firstly, what is Launcher? Launcher is responsible for starting any SAFE Network compatible applications. Launcher acts as a server gateway between the application and the SAFE Network. The applications authorise and exchange data with the SAFE Network when the user allows them to, so in practice this means you only have to share your valuable credentials with Launcher and not every application you use, making this a far easier and massively more secure experience than we have on the current internet. It also means you need remember only one password in order to access all your Launcher enabled apps. This approach also lowers the barrier to entry for third party developers as well and will encourage further innovation on the SAFE platform.

mock

Figure 1 – Example screen of SAFE Launcher on Windows

The team have also hatched a solution that allows you to browse sites on the SAFE Network without needing a browser plugin, just using the SAFE Launcher and your normal internet browser. We believe this will help enormously in terms of encouraging people to first try the network; this has been a topic that has seen a lot of community discussion. The discussion via the forums or the Request For Comment (RFC) process is input we all value very much and something we hope to see much more of as the network gains traction.

A lot of work has gone into creating, finalising and documenting the Launcher API. This API is crucial to the success of the platform in that it is the gateway allowing developers to integrate their products and services to leverage the power of the SAFE Network.

An example of one of the SAFE apps on which the UX and Client Devs are working together is a Messaging app. Below are some mock-ups of what we expect the app to look like.

screen1

Figure 2 – Example screen of SAFE Messaging app
screen2
Figure 3 – Example screen of SAFE Messaging app

When you have been working with CLI (Command Line Interface) examples for so long, the knowledge that well thought out, aesthetically pleasing and functional applications are coming is extremely exciting. Another application currently under development is a Drive VFS (Virtual File System) app; this is essentially a file storage application which will allow users to visualise and manage their files stored across the SAFE Network.

In the next few weeks a Minimum Viable Product (MVP) should be released and publicly available to be tested. We should begin to to see our internally developed and third-party applications become tangible and planning begin for a sprint to implement Safecoin into the network. From a personal perspective I shall endeavour to make these less technical blog updates a regular occurrence and as always your feedback and comments are very welcome.

Until next time…