SAFE Network Development Summary – May 2017

We’ve had quite few requests on social media and on email these past few days requesting updates on development progress. These messages serve to remind us that not everyone has the time or the inclination to read the weekly development updates which we post each Thursday onto the forum. So many projects, so little time! So the intention with this post is to provide a summary of the most recent events and our hopes and expectations moving forward.

Image: Richard Tilney Bassett

The best place to start is our development roadmap, which we updated and published late last week. This web page tries to encapsulate all the complexities of development over time on 1 page so it’s pretty high level, but it is this snapshot view that most people seem to appreciate. You will notice that the roadmap outlines the major aspects of development and a rough indication of the order in which we anticipate tackling them.

You will also notice that we haven’t included timescales. In the past we have provided timescales for ‘launch’ of the network. These have always been wrong despite our best efforts. We have found it difficult to estimate timescales since, we believe, so much of what we have been working on is brand new technology, sometimes completely bespoke, and other times building on the work of other projects. Testing is also interesting, it really helps us understand more about how the network fits together and how it is utilised by our community, but invariably leads to more tweaking and testing with previously unplanned and unknown rework and test durations.

We believe that publishing release dates that have a high degree of uncertainty attached is not helpful to anyone and can cause more frustration than not publishing them at all. Network related development is typically where the biggest black holes are and as we get into incremental development client-side, we anticipate time scales will become more predictable.

Stable decentralised network
In late March we released test 15, a network that incorporated both data centre resource as well as enabling user run vaults. Within this release, users were also able to run the SAFE Browser, Launcher and demo app, which continue to facilitate the storage of private and public data, as well as create public ID’s and publish SAFE websites.

After 3 days of running a stable network without any lost data we realised we had reached an important milestone. While we had done this extensively in private tests, it was fantastic to see it running publicly and see the community reaction to it. Of course, life has a sense of humour and shortly after it became apparent that a script had been written that created fake accounts and filled the relatively small network with data, stopping the creation of new accounts or the uploading of new data. This was really helpful to us as it enabled us to find out what happens to the network when it reaches capacity in a real world setting. The fact that it behaved as expected was reassuring, although we’d be lying if didn’t admit to finding the spam attack a little frustrating. This is of course something that the integration of safecoin would stop, as the requirement to ‘pay’ to store data will make the attack expensive, while the incentive of safecoin to farmers would lead to a significantly bigger network.

What now?
Looking forward we are currently focussed in 3 main areas:

  • Catering for mobile devices.
  • Enabling greater user participation.
  • Improving the resilience and robustness of the network.

The patience app developers have shown to this point is soon to be rewarded. The process of converting our APIs away from a REST paradigm to SDKs was essential to cater for mobile devices, as the requirement for REST APIs to maintain state would not have worked with mobile devices that disconnect and reconnect regularly. Users of the SAFE Network will gain access through the Authenticator, a secure gateway that protects user credentials from the application itself. The Authenticator is currently being bundled with the SAFE browser and will enable users to securely authenticate themselves onto the network, or enable them to browse publicly available data without logging in.

To implement Authenticator the team required to add a new data type, mutable data. The new data type improves the network efficiency, saves bandwidth, and provides the granular access control required by mobile platforms.

With mobile devices being so ubiquitous throughout the world, enabling mobile client access to the network, mutable data has been receiving significant focus. From a resource provision perspective, both alpha and beta versions of the network will require laptop and desktop and in time single board computers to earn safecoin when it is released. In time, we will look at enabling mobile devices being able to farm for safecoins when plugged into a power outlet and when in range of WiFi, however, as we will detail below this is not a priority for now.

More alphas
Some of the example applications that have been created are currently being ported to suit the new data type and to be compatible with the new APIs. The team are updating the documentation and are testing the applications using a mock network, and they seem to be far more stable than previous iterations which looks positive. We anticipate alpha 2 will encompass the new Mutable Data type and Authenticator, SAFE Browser DOM APIs and Node.js SDK, along with example apps, tutorials and documentation.

Image: Clint Adair

Alpha 3 will see our focus shift onto enabling a greater number of users to run Vaults from home by integrating uTP. Presently users must TCP port forward, or enable UPnP on their routers which requires a little set up in some cases. Adding uTP support will make for a more seamless process for many while making the network accessible to more users. uTP is used in some BitTorrent protocols and when implemented effectively helps to mitigate poor latency and facilitate the reliable and ordered delivery of data packets.

During this phase we will also integrate node ageing, a feature that make the network more resilient to consensus group attacks. The team will also implement the first part of data chains, a feature that has been planned for a while which it is anticipated will ultimately enable the secure republish of data should the network ever lose power, and to provide validation that data has been stored on the network.

Looking ahead
Beyond alpha 3 we will focus on:

  • Data Chains, part 2.
  • Data republish and network restarts.
  • A security audit of the network
  • Test safecoin
  • Real-time network upgrades
  • Network validated upgrades

As has been the case to this point we will continue to release multiple test nets regularly between each alpha network to prove the technology in a public setting, and to mitigate against the code regressing.

We continue to be grateful to the huge support of the people that take the time to run these networks and report back, you all know who you are!

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 To transfer MaidSafeCoin, users should use the Omni Web Wallet, which is available at

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.


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.


Figure 2 – Example screen of SAFE Messaging app
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.


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.


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!