maidsafe

Glasgow University Students To Use The SAFE Network

Since its inception in 1451, Glasgow University has built a worldwide reputation as a centre for innovations which have had a profound effect on the world. Its famous alumni have included John Logie Baird, Lord Kelvin and Adam Smith, whose global impact has left a lasting impression on the world we live in today. Continuing the trend, Glasgow University Computing Science Students will be exposed to the latest in decentralised networking technology as MaidSafe’s SAFE (Secure Access For Everyone) Network puts them at the forefront of research and development into next generation Internet applications.

Students within the computer science department, under the guidance of Dr Inah Omoronyia, Lecturer in Software Engineering and Information Security, will work with the MaidSafe team, led by Scottish Engineer David Irvine. They will provide students guidance in building apps on top of the company’s platform, a secure and decentralised data and communications network that replaces the world’s data centres and servers with the spare computing capacity of the networks users. This comes at a time of great debate about the future of the Internet with leading academics, including the founder of the worldwide web Sir Tim Berners-Lee, seeking to improve the security and privacy offered to users.

The SAFE Network provides a zero cost infrastructure for students and the current APIs enable the creation of storage and email applications. This functionality is laid out to developers in tutorials created by the company, and this will be expanded over the next few months as MaidSafe release tutorials every 2 weeks, providing increasingly more complex functionality to application developers.

MaidSafe CEO, David Irvine, commented on the partnership; “We are delighted to be working with a university with such a rich heritage and we very much look forward to using the applications created by their students. Where better to push the envelope of evolutionary thinking than the country that Voltaire opined “We look to Scotland for all our ideas of civilisation”. Glasgow University has an excellent opportunity to be at the forefront of research and development in the field of Internet technologies, alongside the likes of MIT, which will further enhance its reputation – and that of Scotland – as a source of cutting edge innovation.”

Glasgow University has one of the leading computing science departments in the UK and is ranked amongst the top 100 in the world. Lecturer in Software Engineering and Information Security, Dr Inah Omoronyia confirmed “It’s a great opportunity for our students at Glasgow University to get hands-on experience with building apps for the SAFE network. Security and privacy functions is now core to modern day software systems; our students are really excited to learn new ways of building such systems using cutting-edge technology.”

MaidSafe Announces Equity Funding Round on BnktotheFuture

We wanted to share some next steps for MaidSafe and the future of the SAFE Network. On September 12th we will be launching an equity fund-raising round with BnkToTheFuture, a leading global online investment platform for qualifying investors. MaidSafe is looking to raise between £1.75m and £2m during the 30 day campaign.

Next steps

This is an important step for the company and the future of the platform coming on the back of the recent release of the SAFE alpha. We are delighted with the positive feedback we have had to date and the strong support of our community has been hugely important to us. We see this funding round as critical as we move to the next stage of development so we wanted to explain why we think this is the best way forward.

As you know launching the alpha is only one of many steps on our journey. There is a lot of work to do to build out functionality and create a robust platform that will attract users and application developers. That means we need to continue to recruit the best developer talent from around the world and build out a developer programme to support the growing interest in building on the SAFE Network. We will also be looking to develop our own applications, because we do see commercial potential for us as well as for the broader community.

Why BnkToTheFuture?

We have chosen BnktotheFuture for a number of reasons. They have a large online community of qualified investors, interested in the decentralised technology sector. There is a strong relationship with the crypto-communities, which is important to us, and investors will be able to invest in both traditional currency, bitcoin and even some of the more liquid altcoins like Ether. Above all it also means we will remain in control of our strategy and roadmap, which is really important to us as we want the SAFE Network to be available for everyone to use and develop on. This is why the core code-base is open-sourced, to encourage the establishment of a strong community around the technology. Furthermore, we have transferred the core intellectual property (IP) to a Scottish charity (The MaidSafe Foundation) to help ensure that MaidSafe is not seen to benefit unfairly from ownership of the network (although we hold a license in perpetuity to allow us to utilise and license the technology to partner companies).

We appreciate all your support so far and hope you will see this news as further evidence that the SAFE Network is on the fast track to becoming a viable alternative to today’s insecure, unreliable worldwide web. With this investment round we are seeking to accelerate progress further by adding functionality and working towards the beta version and beyond. I hope you will continue to contribute to this exciting journey, because we believe a secure, decentralised approach to the internet will present huge opportunities for users and developers alike.

MaidSafe and Yuanbao Forge Asset Trading Partnership

It is our pleasure to announce that one of China’s largest asset exchanges, Yuanbao, will soon support the trading of MaidSafeCoin in China. This agreement follows on from MaidSafe developer, Qi Ma, recently introducing MaidSafeCoin and the SAFE Network to Yuanbao’s customers at a recent roadshow in Bejing.

Founded in 2013 and with 250,000 users, Yuanbao is one of China’s largest digital asset exchanges. With a peak trading volume of $100 million USD in a 24 hour period, the exchange facilitates the trading of 27 different currencies on the Yuanbao platform. Yuanbao is MaidSafe’s recommended partner for the Chinese market.

MaidSafe’s CEO, David Irvine, confirmed: “We are delighted to be partnering with a secure and reliable exchange, such as Yuanbao. The Chinese market is one that MaidSafe are particularly interested in supporting and this partnership is a great way to introduce MaidSafeCoin and the SAFE Network to a new and very important audience”.

Jelena Strelnikova, Foreign Cooperation Officer at Yuanbao added: “By opening trading on the Yuanbao Exchange MaidSafeCoin is introduced to the broad Chinese market and to the welcoming Chinese community. It is our pleasure to be part of MaidSafeCoin’s success, and we are looking forward for further strategic and fruitful cooperation with the MaidSafe team.”

MaidSafeCoin deposits and trading will be available from the 24th of June on https://www.yuanbao.com/. To transfer MaidSafeCoin, users should use the Omni Web Wallet, which is available at https://www.omniwallet.org.

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…

Evolving Terminology Pt. 2: Topology vs Ownership

In the previous post in this series, I highlighted some standards that I think could help communicate the variances in networks. I had some great feedback from several individuals which pushed me to explore the roles of network administration and effect on control a bit deeper. Networks like Skype (before switching to client-server in 2014) and Spotify have structures that are peer-to-peer (p2p) topographically but also include a central entity for system critical components like registration and peer discovery. Since this sort of set-up is widely considered p2p and technically falls under our definition of distributed (passes messages directly between clients) but does not hold up to the requirements of decentralized due to the centralized administration points, how can we fit this network type into our terminology standards? What effect does this administration role in an otherwise p2p network have?

The Hidden Hand That Feeds

Hybrid or Pure

To better communicate the difference between p2p networks with central registration and closed access (Skype, Spotify) and those with decentralized registration or no registration and open access (SAFE Network, Bitcoin, BitTorrent), a great resource to consider is A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications (pdf) by Rüdiger Schollmeier published in 2002. And while I made an indication in the last write-up that frequent revisiting of terms is necessary for such evolving technology, this is a case where the standards defined have stayed consistent with modern use cases and incorporating them into our language adds value. In this paper, Schollmeier defines p2p networks with administration roles or where “a central entity is necessary to provide parts of the offered network services” as hybrid peer-to-peer networks. Contrarily, he defines pure peer-to-peer networks as those where any “…entity can be removed from the network without having the network suffering any loss of network service.” I quite like this wording as the hybrid and pure descriptors make the distinctions easily understood. It’s valid here to point out the terms closed and open as analogous to hybrid and pure but in some contexts might be more useful especially when distinguishing central registration processes from those with decentralized or no registration. So while peer-to-peer is used to describe network structure, it does not paint the whole picture and using these new terms to talk more specifically about networks takes us a step beyond network topology to make clear whether hidden entities exist.

Required or Facilitating

In the Skype example, the central coordinating entity was required for registration and finding connections between peers which categorizes it as hybrid. It’s important here to note that this administration point is a requirement for proper network function and that it’s possible for pure p2p networks to use administration points for simply facilitating discovery. While not discussed in the Schollmeier paper, we can still relate to the definitions he laid out. BitTorrent trackers are central entities for finding peers faster but not “…necessary to provide parts of the offered network services”. To avoid a central discovery requirement, peer-to-peer networks often employ gossip protocols for decentralized node discovery where nodes relay information about already connected peers to facilitate new connections. In another example, the mesh networking application for sharing internet access by Open Garden should be considered a pure p2p network even with a server to facilitate finding other devices because it is not required. Here, the entity acts to provide a more seamless user experience, but in situations where a device is without Internet access or ISP networks are congested, a user can do manual pairing and bypass the admin. For the record their other app, FireChat, should be considered a hybrid and closed p2p network because of its central entity requirement for initial user registration and login even though there is a similar manual connection process if the server isn’t accessible post-registration. To avoid centrally controlled registration in a p2p network, employing blockchains is becoming a more popular solution but comes with privacy concerns if users aren’t proactive. MaidSafe has built an alternate approach removing third-parties and preserving anonymity called self-authentication for the SAFE Network. So while there are many kinds of networks which make use of p2p topology, some fall short when it comes to registration or peer discovery requirements as opposed to being independent of administration and accepting an optional, facilitating hand.

networksV3

Decentralizing Administration with Multiple Hands

A final consideration of networks with p2p topologies are those with multiple administrative points rather than a single entity. While not as common, we can look at the Tor network’s use of directory authorities as an example. I should take this time to quickly mention that in the last post, I classified Tor a decentralized (but not p2p) network because it maintains a client-server infrastructure (which implies a hierarchy rather than flat structure) but nevertheless, the concept of dependence on administrative roles is carried over. Directory authorities are servers in the Tor network which create consensus around a public list of network nodes to route traffic through. This allows for properties like blacklisting IP addresses showing suspicious behavior and maintaining a complete list of Tor nodes without storing this data on each of them. If clients are blocked from accessing these authorities (ie. via the Great Firewall), they may connect through private servers called bridge relays but Tor routing nodes still need this list to access other connections to further forward the traffic. While Tor functionality depends on this directory, it is maintained by a consensus process made up of several independently run servers and thus alleviating a central administrator. Similarly, in the beginning days of the BitTorrent network (before implementing a dht-based discovery process), it required the tracker servers for discovering other peers. Categorizing these situations as pure or hybrid is therefore mostly dependent on the number and ownership of administration points: the more directory authorities owned by a diverse group of people, for example, the less the network depends on a single authority and teetering classification towards pure.

The Hand That Feeds is the Hand That Owns

The Range of De/centralization

By dissecting the role of administrative points in decentralized and p2p networks it is now clear that network topology is only one aspect that is important to consider in how we communicate networks. Requirements for entities outside of the topology illustrate how even p2p networks can have hidden ownership structures. While the collection of nodes is still a vital component in the functionality of a p2p system, the required administrative points carry more importance for network functionality and therefore, the people operating these points have proportionately more ownership than those operating network nodes. While central network ownership through an admin is not inherently bad, the consequences of this model can be detrimental and prone to censorship, surveillance or attack. This ownership model brings back vulnerabilities of centralized network topologies where all messages must go through a central point. Likewise, networks with multiple admin points show similar ownership properties as decentralized networks where there are a smaller number of backbone nodes enabling greater capabilities like longer distance connections in mesh networks or increased computing and hosting power like servers in the traditional Internet. Whether part of the topology or not, central points of dependence hold more importance in functionality of the overall network and as a result correlates to power and ownership. If there are enough of these points, it is not necessarily a problem but it is not enough to have multiple points: they must also be maintained by different people as to reduce chances of centralization or collusion.

The Range of De/centralization

The term “decentralized” in this sense should be seen as a range where the more spread out the ownership of the network is, the more decentralized the network itself is. Even when considering pure p2p networks, distribution of node ownership is critical. Networks like Tor, MaidSafe and Bitcoin lose a lot of their security properties the more a single entity owns network nodes. A common vulnerability in p2p networks happens when an entity can flood the system with nodes under their control or through the reverse where individual users discontinue operation of nodes, shrinking the spread of power. Outreach programs for Tor aim to onboard new node operators as there are fears that organizations like the NSA operate many Tor nodes in an attempt to undermine the security and monitor network traffic. This is also a strong point in the current Bitcoin blocksize debate where those against large blocksizes argue that the larger the bitcoin blockchain is, the more resources a node requires thus removing ability for some people to run them and effectively pushing it towards a less decentralized network and a greater potential for centralizing ownership. In the SAFE Network, we have implemented a more dynamic resource usage algorithm based off a sigmoid curve in hopes to diversify the ownership of the network as much as possible and greater resistance to attacks from actors owning many nodes by requiring a chain of consensus for each action.

networksV4

Communicating Commonly Owned Networks

By zeroing in on some finer points of networks beyond topology such as administration roles and ownership considerations, we can continue to clarify distinctions between networks in order to understand them better. While closed networks operated and maintained by a company might gain some benefit from central administrative and ownership capabilities of hybrid p2p networks, open networks that are for the benefit of a general population should prioritise wider ownership to remove central dependences. Attacks on decentralized networks become harder and general network health increases with the more individuals that participate and take partial ownership. Unfortunately for the current Internet, corporations have taken ownership of much of the network and are in critical positions of power. By re-aligning incentive structures to spread out ownership, p2p networks like SAFE will give Internet users a second chance to rally around an alternative that offers an commonly maintained and owned infrastructure.

MaidSafe Code Bounty Program

We have mentioned the introduction of a code bounty programme a few times recently and, in the true spirit of Open Source software, we want the community to be able to take an active role in helping MaidSafe roll out the SAFE Network. This will not only decentralise and spread knowledge of how the network functions, it will also enable SAFE to be released more quickly.  The following post will provide a bit more detail on how we see MaidSafe’s code bounty programme working initially.

MaidSafe will publish tasks at the start (and potentially during) a development sprint. These tasks will be listed in Jira where anyone with a Jira ID will be able to claim and start a task. The tasks will be fully specced out by the maintainer of that library whose e-mail address is published in that library’s GitHub readme. If you feel the task description is not clear then you should contact the library maintainer prior to accepting the task in Jira. The fact that it is not clear could be a sign that it isn’t well suited to your skill set. Here is a rundown of the terms:

The terms

  • Participation will be on a first come first serve basis
  • The bounty only applies to open Jira tasks identified by the MaidSafe team
  • The developer that claims the task will be given a sufficient amount of time to complete it. For example, a task that is scheduled for 8 points (around 8 hours work) should be completed in one day. However, if a GitHub pull request is not received at the end of this period, or the task is not correct (doesn’t pass tests/ other task requirements as specified in the task description), it will be made available to the rest of the community. We will need to be strict about timescales and work quality to avoid delays
  • All submissions should take the form of a GitHub pull request
  • If the task is complete (meets the spec and passes all tests ((including coverage)), MaidSafe will pay the bounty (in bitcoin) to the successful developer
  • Each contributor agrees to the terms of the MaidSafe Contributor Agreement
  • MaidSafe’s core development team and employees are not eligible for rewards

The rewards

  • $20 per story point (paid in bitcoin only). Story points are used by MaidSafe to estimate task timescales
  • 1 story point is typically calculated to be around 1 hours work
  • The reward will be paid on the merge of a contributors pull request to a btc account of their choosing. We would also donate the bounty to the preferred charity (one that accepts bitcoin) of the developer should they prefer. Contributors should enter the bitcoin address they would like the bounty paid to into the pull request description field
  • An exclusive and limited SAFE Network core dev t-shirt (this is a one off reward and is limited to one shirt per developer)
  • The developers name added to the main SAFE Network repositories

This is a process that is likely to change over time as the bounty programme develops and grows. We plan on starting the programme slowly and in about 2 weeks time we will identify the tasks from the current sprint (RUST-3) that are eligible. Over time, we anticipate opening up all Jira tasks to the community, but we would like to trial the process first. In future, we may start to pick much bigger pieces of work, such as the addition of specific network features, and ask community members to compete for them. These types of projects would obviously carry many more story points and be much more lucrative, but we should learn to walk before we can run!

So, hopefully this provides some more detail about the bounty scheme as a whole and we will start to announce applicable tasks in the next couple of weeks. We can’t wait to start working with you all more closely!

The Ants Are Coming!

It is fair to say that MaidSafe have been fairly quiet in our communication of late, not a complete radio blackout, but certainly low key. This has been intentional on our part. Communication can lose its meaning and impact if you shout about every little thing. We like to keep our powder dry, as they say.

But, now we have something meaningful to convey!

I want to bring everyone who is interested up to speed with what we have been doing during 2015, specifically the past three months, which have been some of the most transformational in MaidSafe’s nine-year history. We do make weekly dev updates on the community-run forum, but these can be pretty technical, and not everyone can get a full picture that way. So I will try and condense these points into as limited an amount of technical language as I can muster.

Rather than starting in early 2015, however, we will start this post at the present day. (I’m a sucker for Quentin Tarantino films and it will hopefully make for a less laborious post!)

Early(ish) on Friday (26th June) morning, the tireless MaidSafe dev team managed to get the SAFE Network functioning from end to end. This means that a User is able to self-authenticate (create their own username and password, and access the network without the permission of a third party) using the Authentication API via the SAFE Client. During the process, the network’s transport/connection layer (Crust) connects the peer nodes, allowing Routing (the layer that verifies the identity of each node cryptographically) to establish and maintain connections to other network nodes (for more information on how all the components fit together, please visit our wiki). The clients were also able to PUT (store) and GET (retrieve) data.

This is a phenomenal and long-sought achievement for everyone at MaidSafe, and is truly a major milestone ticked off. Yes, we have had an operational network before, but never one so stable, efficient or lacking in complexity. This lack of complexity is a very good thing and something of a personal mission for David. A significant reduction in the lines of code (from hundreds of thousands to a few tens of thousands!) not only enables new network features to be added much more quickly, it also makes it easier for bugs to be spotted and for other projects to utilise our code, much in the same way that we have employed the code of others. Open source collaboration is truly a wonderful thing to be a part of!

This new chapter in our development progress all started back in early February when David, again desperate to reduce complexity, spotted a pattern in the code, a repeatable and describable pattern that kickstarted the simplification of the decision-making logic within the Vaults (the series of processes that help look after all data on the network) and also improved network security. You can read David’s detailed blog post about it here.

Soon after, heavily frustrated by the speed at which we were developing in C++, we started looking into ways to speed up development without a reduction in code quality, surely the holy grail of software development. After much research, David became increasingly convinced that a new systems-level language, Rust, had something to offer. In his spare time (between about 2 a.m. and 5 a.m.) he started transposing one of our most complex libraries, Self-Encryption (the component that seamlessly splits data into smaller chunks and encrypts them), over to Rust, which at that time wasn’t even in Beta yet. This was very successful and fast! David followed a similar process with MaidSafe’s Routing library. With another successful test complete our development team was split for a few weeks while the core team remained in C++ and another team started transposing the rest of the code.

This was a risky and scary time. To split the dev team at a period when we were under significant pressure to produce a stable network seemed counterintuitive. But thankfully, going backwards to move forward paid off, and without this change there is no doubt in our minds that we would not be where we are today. It is not the intention to go into detail here about how and whether Rust is better than C++. For debates on that subject you can check out some of the threads on the forum and elsewhere. I think that is a debate as contentious as GPL vs MIT, or even Borg vs MacEnroe, fun to debate but don’t expect consensus any time soon. All I can say is that it’s working for us and allows us to iterate quickly, be more defined with our tasks and be more definitive with our timescales.

During this time we also realised that we needed to be more third-party-developer focussed. And that doesn’t mean being more open with our development process; we’re pretty open already. Rather, it means organising our libraries in such as way that they can be picked up and used by any third-party developer without being heavily coupled to other libraries. In addition to whatever assistance this gives to other projects in the open-source community, this helps Project SAFE in two specific ways: first, allowing external use of these discrete libraries helps validate their functionality in a variety of different projects; and, second, it allows us to demonstrate, at a library level, that each component of the network carries out its desired function.

So, beginning in late April we started to release each of the component libraries as console apps, essentially providing the libraries functionality with a text-only interface (such as terminal in mac and linux, or the command line on Windows) rather than a Graphical User Interface. The first console app was Self-Encryption, and since that time we have also released Crust and Routing. All MaidSafe libraries are published on crates.io, where a stable release of each library can be used by other projects, and dependencies known (dependencies are the other programs that the library relies on to run). This process is not only useful for third-party developers, it also gets the MaidSafe team into a habit of delivering working code regularly and in a routine way.

We have found that this more modular and more approachable way of working has led to many more developers committing code to the repositories, and it is valuable code. Such is the desire for this network, and also the desire of people to try Rust. We will accommodate these desires and pay anyone who contributes to our code sprints, starting from this upcoming sprint (we will update everyone on the bounty scheme next week on this blog). We anticipate this will give us better code faster and with a more engaged and willing community, the impact of this cannot be underestimated. This is an area we will work hard on, to ensure the community is well-rewarded and recognised for contributions, as we feel they should be.

So, now that we have a running and more stable network than we have ever had before, what next? What does the future hold? Well, we can look to our roadmap for the answers. In the very near future (in the next couple of weeks), we will be releasing installers to enable users to download and run a SAFE Network locally on their individual computers. Beyond that our next development sprint will start week commencing July 6th (probably lasting for around three weeks) and though we are still mapping out specific objectives, this sprint is likely to consist of some or all of the following:

  • Further implementation of safecoin (some work here has already started)
  • Implementation of messaging infrastructure
  • Remove Transaction Managers (reduce complexity, code and increase security on the network)
  • Implement App Launcher infrastructure (enables secure login to third-party apps without the App Developer getting visibility of a User’s credentials)
  • Implement cross-platform/cross-network/multi-protocol network connections (everyone can run farming Vaults at home or in any network)
  • Implement POSIX disk interface (any app can treat the network as a local hard disk)
  • Implement public names and shares ( SAFE version of www, email, DNS and more)

From there we should quickly (hopefully within 2 sprints) see the delivery of Dev Bundle 2. This iteration will provide a network where Farmers can start to contribute resource and have this measured, where developers will be able to access and utilise stable APIs and start to build applications that everyone can use. These apps might be simple at first, such as encrypted messaging and data storage apps, but in a short space of time will have the potential to develop into anything that can be done on the existing web and beyond. We will possibly split out Dev Bundle 2 on the roadmap so that some of what is currently listed will become Dev Bundle 3. This way the deliverable of each feature focussed sprint will be an updated bundle.

So, this recent development milestone is hugely significant and we are very close to delivering the SAFE Network, something that the world would seem to need even more than it did when David started this journey nine years ago. We will continue to keep you all updated via the forum and this blog.

Thanks all, for your continued participation and support.