SAFE network

Developer Case Study – Dsensor

Decentralized Mapping Protocol Project – Dsensor

Continuing our series of case studies highlighting early stage application development on the SAFE (Secure Access For Everyone) Network, Dsensor is being developed by James Littlejohn. James explored various platforms to store and protect the data he would be collecting and decided to use the SAFE Network, because it reflected his belief that the network should not be driven by economics, but be focused first and foremost on the data.

MaidSafe’s fully secure, decentralised approach supported James’ view that knowledge or data should be in the complete control of user. While it is early days, Dsensor’s use of the SAFE Network APIs in its proof of concept form shows its potential as a viable platform for the management of data. James was also attracted to the SAFE Network, because of its strong encryption, and its ability to break data into chunks before scattering it around the decentralised network of nodes. This ensures the highest possible security and privacy for users when combined with the decentralised architecture, which avoids offering hackers central points of attack on a network, as we experience in today’s centralised, server-based model.

Being open source and supported by a strong community in the SAFE Network forum also means James has ready access to experts and potential partners, who can help to build out the application and trouble-shoot any technical questions. In the future James may also explore using safecoin to incentivise participation on Dsensor.

The Problem with Science

James Littlejohn has been involved in entrepreneurial projects since the dot com boom and while investigating opportunities around text mining identified an opportunity for lifestyle linking analytics, particularly in the area of wearable tech. In the course of his evaluation he recognised a broader application to data mining and analysis in the field of scientific and academic research. James assessed a number of drivers, including emerging technologies and changing economic conditions, which were beginning to have an effect on the way research was conducted.

Firstly, walled garden applications such as Facebook and wearable technologies were becoming more prevalent, and while they were a rich source of data on human activity, access to that information was restricted. At a time when the internet is supposed to be democratising many aspects of work and social life this is endangering an important source of information on lifestyle and health patterns, which could benefit societies around the world.

Secondly, the sustained economic impact of the financial crisis was creating significant pressure on public funding for research at a time when it was needed more than ever. Technology and the availability of large amounts of data is leading to opportunities for breakthroughs in a wide variety of academic and research fields. If the funding is not available via traditional public sources then there is an urgent to find new forms of investment. The rise of alternative cryptocurrencies could potentially address this point, offering a new, fairer way to incentivise and reward individuals for participating in research projects. For example, James envisages a scenario where the grant funder might ‘tokenise’ a percentage of their funding money and issue it via a science blockchain (like Dsensor). This would help to ensure the funding could be traced directly ensuring good governance of scientific research projects and fairer access to resources.

The final driver for a new model reflects an on-going debate about the model of peer-reviewed scientific research. For a number of years there has been a recognition of some fundamental weaknesses in the model in areas such as the replicability of research. In a poll conducted by Nature in May 2016 more than 70% of researchers admitted they had tried and failed to reproduce the experiments of other scientists and more than 50% failed to reproduce their own experiments. Of course this is in part due to the nature of frontier scientific research, which is reliant on trial and error, but there are clearly inefficiencies in the process.

Furthermore, there are questions about efficiency of current research models – in 2009 Chalmers and Glaziou identified some key sources of avoidable waste in biomedical research. They estimated that the cumulative effect was that about 85% of research investment – equating to about $200 billion of the investment in 2010 – is wasted. A blockchain provides a potential solution to this reproducibility crisis as Dr. Sönke Bartling and Benedikt Fecher outline in their paper, “Blockchain for science and knowledge creation.” Although scientific research should be delivered at arm’s length from the individual contributors it is ultimately reliant on individual scientists to gather and interpret data without bias. It is also often reliant on finite data sets, controlled samples or clinical trials, thus limiting the ability to cross reference the findings against other data sources.

Given the availability of data via the internet and the rise of automation technologies, such as machine learning, James believes that if individuals have control of their information they can decide to contribute their information to research projects without the interference of third parties such as academics or technology providers. Using automation scientists, academics – and more importantly citizen scientists – can draw data from anywhere in the world beyond the confines of a specific controlled sample and review independently to provide a data driven outcome.

Building A Blockchain for Science Research – A Truth Engine for Mankind

James’ investigation of text mining approaches led him to peer to peer models, which were enabling the owners of data to take control of how and with whom their information was shared.  

It led to the development of Dsensor.org (Decentralized Mapping Protocol), a peer to peer network for science knowledge to be investigated, discovered and shared. It has been based on the principle of science “SenseMaking” and it is designed to evolve peer review to a computational consensus model.  Using Dsensor if a scientist creates a thesis and wants to test it the scientist enters the hypothesis in computational form (called a Dmap in Dsensor speak) . The Mapping protocol then automates the testing of the science, starting by trawling the Dsensor network for relevant data from other peers. That data is then sampled and ‘scored’ based on its prediction power to verify or challenge the thesis until a computation consensus is established.  Science attaining this status then becomes ‘computationally active’ in the network meaning any peer has the ability to tap into the collective knowledge and feed in their own unique sensor data get the insights from the science working for them.

James has the ambitious goal to become a “truth engine for mankind” ensuring science is based on openness, transparency and reproducible results, essentially checking the accuracy of peer review.  Dsensor intends to deliver this outcome by building a network of trustless peers, which has inherit vast complexity making it economically and technically very costly and difficult to corrupt.  Dsensor, currently at proof of concept stage utilises  the Ethereum blockchain, using its cryptography and a variant of the proof of work process to create a technological and mathematical state where even with colluding computers it is impossible to game the system.   Rather than creating complexity using a proof of work Dsensor creates uncertainty using random sampling, in particular the selection of peers from the network and data sampling techniques.  The data sampling techniques are selected by each autonomous peer and the network sampling is a property of the Protocol for selecting peers from a Distributed Hash Table. In theory once the network gains a certain size the economic cost of gaming the network with false sensor data to support a fraudulent scientific computation will become extremely costly.

Additional safeguards include the role of reproducibility in science.  This creates an immutable audit trail or “mapping accounting” entries that support the most truthful science available to the network.  These networks are called GaiaBlocks and are open to be challenged by any peer on the network.  Scoring of the science also provides a rating model for scientific research and individual peers on the network.  Peers with poor outcomes will be demoted in favour of more highly rated scientific computations.

 

Developer Case Study: Project Decorum

During the course of 2016, MaidSafe have been privy to a number of projects that are building on top of the SAFE Network. One such project is Decorum.

What is it?

Project Decorum is currently a research-led project, run by Harmen Klink, a computer science undergraduate at the HU University of Applied Sciences Utrecht in the Netherlands.  He wants to build a social media platform, which gives the user greater control of his or her data and therefore enhanced privacy – rather than today’s model which is centralised around a few service providers.

Project Decorum is currently a proof-of-concept, which Harmen has designed in order to drive a successful crowdsale, which raised over €400,000.  He is aiming to use this investment to further develop the application, aspiring to create a hybrid of the best features of existing major applications, such as Facebook, Reddit and Twitter.  

How does it work?

The core protocol of Project Decorum is a substitute for the missing central coordinator, because the SAFE Network has been designed on the principle of a “serverless” architecture.  It consists of a set of rules that describe where and how conversational data should be uploaded to the SAFE Network. These rules predict where the replies to a particular message on the SAFE Network might end up, no matter where the original is located. This means that all applications and SAFE websites that use this protocol will be compatible with each other, making communication simpler.

On the data level all information is visible and the protocol will organise conversations in a tree structure, where every node of the tree represents a message from a user. Replies to earlier messages will create new branches. This tree structure lends itself well to be represented in a “threaded” format, which is done by many well-known forums and comment plugins. Users will build a user interface to decide what data they see and can create a new root to start a new tree for a new conversation. This can be used to create a forum, a comment section on a blog, a group chatbox, and so on.

In Project Decorum users will own their data and everyone is their own moderator through the use of personal ignore lists. In principle, particular posts or users can be put on such an ignore list. It is also possible to subscribe to one or more ignore lists run by other people. This allows for dedicated and widely accepted moderators to naturally rise up in their respective communities. Active people with sound judgement will be subscribed to as moderators by groups. These people can also collaborate to form a moderator team, and possibly accept donations or even charge for their moderation services. Multiple teams with different rules can be active in the same community if there is demand.

Why is Project Decorum working with MaidSafe?

Harmen chose the SAFE Network for his project for several reasons.  He believes the privacy and security of the platform should be the pre-requisite for any Internet application.  Furthermore the decentralised model offers great scalability and he has found it hard to overload the system.  Additionally, SAFEcoin is a great feature, because of the way it is integrated into the network and offers instant rewards.  This will help to sustain engagement with the platform, as social payments are an important feature increasingly expected by users.  It also offers developers the flexibility to expand tokenisation of other assets to create a crypto-currency to represent all kinds of assets.  

What’s next for Project Decorum?

The next steps for Project Decorum include working on designs to make them more tangible and figuring out the business model.  As APIs for the SAFE Network become available and more stable Harmen will continue development on the protocol.  MaidSafe hope that features such as the automatic reward mechanism for participants will enable Harmen to further develop the usage model for Project Decorum.

Harmen Klink, Founder, Project Decorum

“I believe having access to multiple identities is an important benefit of the SAFE Network, because it reflects the varied identities and roles we play in our personal and work lives. The network of identities forms a web of trust that can be used to distinguish legitimate users from abusive bots. When a real name is coupled to an identity, the strength of the web of trust is also used to show others the likelihood that those two truly belong together. This protects users from becoming victims from impersonification and identity theft.”

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.

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…

MaidSafe Development Update

It has been an exceedingly busy summer at MaidSafe and it seems like a good point to recap on what we have working on and how we see things rolling out as we move forward. Since our last major update, when we announced the network running end-to-end, we have been adding some pretty significant features and making several enhancements.

Amongst the highlights, we implemented Unified Structured Data, a change that enables the network to only recognise two primary data types; immutable and structured data. The repercussions for what this enhancement brings to the network is significant. Not only do they allow the reduction of network traffic (reducing load and making it more efficient), it also removes much complexity and enhances the security of the network. It is anticipated that Unified Structured Data will lay the groundwork for features such as smart contracts and global computation. For those looking for more technical detail you can visit the proposal as it was implemented here.

We also recently completed work on the Decentralised Naming System (DNS), essentially the SAFE Network’s version of Internet domains. Keen to avoid many of the issues that we experience with the existing system, such as being centrally controlled by an entity, the SAFE Network provides a way to look up data related to any name. So, no more ‘http’ and a lot more ‘safe:’. At the end of August we released an example application showing this functionality and the example itself can be downloaded here.

Screenshot from 2015-09-02 22-16-30

This was a really exciting development as it enabled us to get more (in addition to the Crust, Self Encryption and Routing examples released early summer) software into the hands of users. In essence, the DNS example enabled users to set up a local network, add files to it (even a website) and then view them using a Firefox extension across multiple platforms. MaidSafe focus a lot on usability and it is therefore great to see comments like this (from Justin Chellis):

“I am not great at things like this, but it worked very easy for me..”

Receiving positive feedback is a real motivator for all at MaidSafe, it’s proof that we are making very clear progress toward our goal of providing the average man, woman and child, access to technology that keeps their digital information safe.

In addition to adding features, we have also had to spend some time going back and tidying up sections of code that were inevitably less than perfect given the pace at which we are working. A technical debt sprint has just finished and we are pleased to see much increased stability in the network. This effort is all being helped by our recently launched bounty program which enables MaidSafe to benefit from the work of several community developers, who between them submitted 12 pull requests over a 2 week period. It’s great to be able to harness the passion of external developers in a way that is mutually beneficial and we are really looking forward to seeing the bounty program flourish.

In the immediate future we are planning the next round of development and there are some big ticket features being planned, these include:

uTP Hole Punching – This will enable the nodes (clients and vaults) to talk to each other beyond NAT boundaries and facilitate users to join and become part of the network by contributing their computing resources. Crowd sourced infrastructure has arrived!

Messaging Infrastructure – This will be a really fun deliverable, but is also a big one. The messaging APIs for inter-node communication would be put in place and potentially the addition of the MaidSafe Public Identity in this iteration. It would allow chat engines and clients to work on SAFE-Network.

Messaging Infrastructure and Launcher implementation – It is anticipated that Launcher would be the only application that users gives their credentials (PIN, Keyword and Password) to. Launcher would then authorise apps on behalf of the user, giving each one of them a sandbox environment to work with. This not only prevents Apps from knowing the user credentials, but also removes the ability for them to tinker with folders/data of other Apps or user’s files and folders.

So, we think that 2 more development sprints will see us reach Dev Bundle 2, a network that anyone can join remotely, store and retrieve data and farm for test safecoin. At this point, it will also be possible for third party developers to start building apps for the network. As we continue the roll out of the network, we will be replacing the existing MaidSafe website with two new sites, one that is focussed toward end users and farmers, and the other to provide developers with a clear channel into using the network.

All in all, very exciting times ahead and we’re very grateful to have you on this journey with us.

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.

Net Neutrality and the SAFE Network

Per Wikipedia, “Network Neutrality” is the principle that all Internet traffic should be treated equally. Essentially, the concept calls for a level playing field for all users, whether they be individuals or providers of high-bandwidth services like Netflix, HBO, etc., or whoever.

From an egalitarian perspective, the answer as to whether net neutrality is a good idea or not is easy: of course, it is good.

From the perspectives of companies which wish to provide high-bandwidth services, as well as the customers who are willing to pay extra to receive those services in the best possible quality, the answer is not so clear. Why, for instance, can’t such services as Netflix, and thus the customers who use them, pay more so that high-access-streaming channels can be built up, taking traffic off of the other lines, thus being better for everyone? Whether this is a legitimate characterization of the argument or whether that’s how it would work out in the real world, one can see that the subject is a little more complicated than the simple idea of equal treatment. And it’s a lot more complex than that, even on a technical level.

Throw in the power (and corruptibility) of government agents, the obligation of service providers to make a profit for their shareholders and thus purchase government agents to gain advantage, the carelessness of the general population to pay attention and judge a complex issue, and all the other factors in the mix, and we’re left with a frustrating mess that seems to have no solution. I, myself, can and have argued the matter from both sides with equal passion.

But what if we take a few steps back and look at the assumptions which might be making all this truly unresolvable based on the current debate? Let’s try.

Let’s start by going all the way back, to consider what the nature of a truly neutral medium would have to be.

Put in somewhat simpler terms, let’s look at net neutrality as the effort to arrive at a truly neutral medium, in which no one is discriminated against BY THE MEDIUM ITSELF based on the quality or quantity of the communication they wish to engage in.

To get an idea of what I mean by this, let’s draw a comparison to another vital medium through which much communication travels, with which we all have vast experience, and which is a truly neutral medium: air.

You and I can stand across from each other and say whatever we like, be it loving or vile, and the air does not care. The air dutifully does it’s job of passing the sounds along from place to place. I can shout to a vast audience, or equally from a lonely mountaintop in a vain (or not) attempt to be heard by the gods: it’s all the same to the air. I can throw flowers or paper airplanes or bullets and the air can have no moral judgement as to which should pass and which should be stopped. There are only the physical dynamics of the different objects, velocities, temperatures, etc., which determine the flight of each. The air does not have the ability to say, “The flowers are good, so they should have easy passage, but the bullets will only be passed on slowly and reluctantly, if at all.”

Now, if you insult me deeply using the air as a medium, I may decide to retaliate with a blow to discourage you from doing so again. The air will discriminate towards my response only based upon whether my hand is open or closed, the slap coming slightly more slowly because of the difference in air resistance. If you insult me from cover, disguising your voice, I’ll have a harder time discouraging you, but the air doesn’t know or care.

The air does not discriminate as to who breaths it. Saints and sinners, people of peace and war, good intentions and bad, all breath it with equal ease, depending upon their capacity.

Perhaps you get my point by now. In our current society what we commonly refer to as “the Media” is not such a neutral scene. It is common knowledge that news organizations have had a stranglehold on the dissemination of “news” and have used it for decades, in conjunction with government and corporate interests, to color the view of the world for populations at large—i.e., propaganda. This is basically because the means of communication have been very centralized and subject to control. Radio waves are neutral media, but access to them by the general population has been limited by both technology and (more profoundly) centralized political and economic force.

The Internet, as it has come into use, has served as a much more neutral medium. Currently, legacy news and propaganda channels are dying the slow death, as upstart bloggers and videographers apply “death of a million cuts,” exposing their biases and agendas, and delivering information that users find more relevant to themselves and more truthful. Politicians and others in positions of power are losing ground as the power has shifted toward individuals, who can more easily determine when they are being lied to.

But the current structure of the Internet, while better in many ways than anything which has existed before, does not make for a truly neutral medium. Actually, while it makes the shift toward individual freedom of expression much more accessible, it also exposes the individual to liabilities which have never been faced before in all of human history. Exercise of the apparent freedoms comes at the expense of privacy and security of the individual, which ultimately undermines the very freedoms which are apparently being gained. Predictive technologies based upon all the data gathered on individuals and groups make the possibilities of social manipulation and control ever more possible by fewer and fewer individuals.

One doesn’t have to look further than the vast revelations which have been made in the last two years by way of Edward Snowden’s disclosures (whether you gauge them heroic or sinister) to appreciate the velvet glove and iron fist with which the surveillance corporation/state is enclosing the broad population.

There is an apparency of great freedom. But at what cost and how true is that freedom?

(I’m reminded of the great cultural revolution in China, in which Mao said “Let a thousand flowers bloom.” Dissidence and counter-revolution were, for a time, encouraged. Then, once the the trouble spots were identified, millions lost their lives. I’m not suggesting that this is necessarily the course of western civilization, but there is a very large history lesson here to be considered.)

So, let’s look back now on the concept of net neutrality. Is net neutrality even remotely possible with the current structure of the Internet? Are we dealing with any sort of neutral medium? I’d have to say no. Therefore, all the social uproar and political action to get agencies and companies to play nice is of little if any use.

Bitcoin and a number of other decentralizing technologies show some hope, but I’d have to say that they are well behind the curve and are likely to be of only marginal utility in securing greater actual freedom for individuals.

Enter the SAFE Network.

Now, I could easily, and justly, be accused of being fanciful on this score, since the SAFE Network is yet to go live and prove itself. But I can’t help myself. The promise is too great and the vision too clear to let these things sit. The more people who see the vision and help bring it to fruition, the better. Even if we fail.

So, before we examine the SAFE Network, let’s look back at the concept of a neutral medium and examine what the elements of a neutral data storage and communication network would have to be.

1. Secure by default. Anyone who accessed it would be able to do so without compromising their financial or data security. This means that individuals would also have complete personal responsibility for their personal and financial data. Sharing it would be an explicit choice.

2. Privacy by default. Anyone accessing the network would be able to have confidence that whatever they did on the network would be completely private, by default. Any choice to share any private data, even their identity, would be an explicit choice. The exposure of private data shared with another person or group would be limited to the worthiness of the trust placed in those receiving that data. Ideally, there would be capabilities of proving valid identifiers cryptographically without having to share actual identity details, unless necessary or desired.

3. Broad access. It could be freely accessed by individuals with very little technical barrier, and no one could deny use of the network if the individual could pass those technical barriers (i.e., a computing device and internet access).

4. Morally neutral. The network could not be subject to central control as to who uses it or the content of the communications, or data stored or retrieved. (Parallel to the air analogy.) The network would handle all of its standard functions of passing and storing data particles with no means of distinguishing amongst them, except to know what to do with them. This would require that the network be composed of nodes provided by users on the assumption that to have the sort of network desired, it is necessary to supply resources to the network to accomplish its purpose, rather than trying to control it.

5. Resistant to compromise. If compromised, no node in the network would be able to adversely affect the operation of the network at large. If it were compromised, it could reveal no useful information about the network itself or its users.

6. Scalable. Heavy demand for particular services or items would not require the building of separate centralized infrastructure, or use of methods which could discriminate for or against certain traffic. In other words, for a website or video or service which is in high demand, the network would simply deliver it up faster, the more demand there was, and then return to more usual handling when demand slacked.

I’m sure there are other attributes which could fit in this picture of a factually neutral Internet structure, but that’s probably enough to make the point.

These characteristics, and many more, actually ARE characteristics of the SAFE Network as it has been designed and proven-out over the last nine years by the folks at Maidsafe.

Will it work as the design and tests so far promise it will?

Will it fulfill the promise perceived by supporters like me?

Will it, in fact, be a truly neutral medium, where “net neutrality” can actually exist?

We will soon see.

This article was reposted with the permission of author John Ferguson. The original can be found on his site The Crossroad of Project SAFE.