In this post, we analyze Wikipedia — a site that has achieved tremendous success and scale through crowd-sourcing human input to create one of the Internet’s greatest public goods. Wikipedia’s success is particularly impressive considering that the site is owned and operated by a non-profit organization, and that almost all of its content is contributed by unpaid volunteers.

The non-commercial, volunteer-driven nature of Wikipedia may cause developers from the “decentralized web” to question the site’s relevance. However, these differences may be merely cosmetic: IPFS, for example, has no inherent commercial model, and most of the open source projects that underlie the decentralized web are built, at least in part, by volunteers.

We believe that a site that has managed to coordinate so many people to produce such remarkable content is well worth a look as we search for solutions to similar problems in the emerging decentralized web.

To better understand Wikipedia’s success, we first survey some key features of Wikipedia’s battle-tested (to the tune of 120,000 active volunteer editors) coordination mechanisms. Next, we present some valuable high-level lessons that blockchain projects interested in human input might learn from Wikipedia’s approach. Finally, we explore vulnerabilities inherent to Wikipedia’s suite of mechanisms, as well as the defenses it has developed to such attacks.

Wikipedia: key elements

While we cannot hope to cover all of Wikipedia’s functionality in this short post, we start by outlining a number of Wikipedia’s foundational coordination mechanisms as background for our analysis.

User and article Talk Pages

While anyone can edit an article anonymously on Wikipedia, most regular editors choose to register with the organization and gain additional privileges. As such, most editors, and all articles, have a public metadata page known as a talk page, for public conversations about the relevant user or article. Talk pages are root-level collaborative infrastructure: they allow conversations and disputes to happen frequently and publicly.

Since talk pages capture a history of each editor’s interaction — both in terms of encyclopedia content and conversational exchanges with other editors — they also provide the basis for Wikipedia’s reputation system.

Clear and accessible rules

If we think of the collection of mechanisms Wikipedia uses to coordinate its editors as a kind of “social protocol”, the heart of that protocol would surely be its List of Guidelines and List of Policies, developed and enforced by the community itself. According to the Wikipedia page on Policies and Guidelines:

“Wikipedia policies and guidelines are developed by the community… Policies are standards that all users should normally follow, and guidelines are generally meant to be best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense.”

For many coming from a blockchain background, such policies and guidelines will likely seem far too informal to be of much use, especially without monetary or legal enforcement. And yet, the practical reality is that these mechanisms have been remarkably effective at coordinating Wikipedia’s tens of thousands of volunteer editors over almost two decades, without having to resort to legal threats or economic incentives for enforcement.

Enforcement: Peer consensus and volunteer authority

Upon hearing that anyone can edit a Wikipedia page, no money is staked, no contracts are signed, and neither paid police nor smart contracts are available to enforce the guidelines, an obvious question is: why are the rules actually followed?

Wikipedia’s primary enforcement strategy is peer-based consensus. Editors know that when peer consensus fails, final authority rests with certain, privileged, volunteer authorities with long-standing reputations at stake.

Peer consensus

As an example, let’s consider three of the site’s most fundamental content policies, often referred to together. “Neutral Point of View” (NPOV), “No Original Research” (NOR), and “Verifiability” (V) evolved to guide editors towards Wikipedia’s mission of an unbiased encyclopedia.

If I modify the Wikipedia page for Mahatma Gandhi, changing his birthdate to the year 1472, or offering an ungrounded opinion about his life or work, there is no economic loss or legal challenge. Instead, because there is a large community of editors who do respect the policies (even though I do not), my edit will almost certainly be swiftly reverted until I can credibly argue that my changes meet Wikipedia’s policies and guidelines (“Neutral Point of View” and “Verifiability”, in this case).

Such discussions typically take place on talk pages, either the editor’s or the article’s, until consensus amongst editors is achieved. If I insist on maintaining my edits without convincing my disputants, I risk violating other policies, such as 3RR (explained below), and attracting the attention of an administrator.

Volunteer authority: Administrators and Bureaucrats

When peer consensus fails, and explicit authority is needed to resolve a dispute, action is taken by an experienced volunteer editor with a long and positive track record: an Administrator.

Administrators have a high degree of control over content, include blocking and unblocking users, editing protected pages, and deleting and undeleting pages. Because there are relatively few of them (~500 active administrators for English Wikipedia), being an administrator is quite an honor. Once nominated, adminship is determined through discussion on the user’s nomination page, not voting, with a volunteer bureaucrat gauging the positivity of comments at the end of the discussion. In practice, those candidates having more than 75% positive comments tend to pass.

Bureaucrats are the highest level of volunteer authority in Wikipedia, and are also typically administrators as well. While administrators have the final say for content decisions, bureaucrats hold the ultimate responsibility for adding and removing all kinds of user privileges, including adminship. Like administrators, bureaucrats are determined through community discussion and consensus. However, they are even rarer: there are currently only 18 for the entire English Wikipedia.

Since there is no hard limit to the number of administrators and bureaucrats, promotion is truly meritocratic.

Evolving governance

Another notable aspect of Wikipedia’s policies and guidelines is that they can change over time. And in principle, changing a Wikipedia policy or guideline page is no different than changing any other page on the site.

The fluidity of the policies and guidelines plays an important role in maintaining editors’ confidence in enforcing the rules. After all, people are much more likely to believe in rules that they helped create.

If we continue to think of the policies and guidelines for Wikipedia as a kind of protocol, we would say that the protocol can be amended over time and that the governance for its evolution takes place in-protocol — that is, as a part of the protocol itself.

Lessons for the decentralized web

Now that we have a little bit of background on Wikipedia’s core mechanisms, we will delve into the ways that Wikipedia’s approach to coordination differs from similar solutions in public blockchain protocols. There are three areas where we believe the decentralized web may have lessons to learn from Wikipedia’s success: cooperative games, reputation, and an iterative approach to “success”.

We also hope that these lessons may apply to our problem of generating trusted seed sets for Osrank.

Blockchain should consider cooperative games

Examining Wikipedia with our blockchain hats on, one thing that jumps out right away is that pretty much all of Wikipedia’s coordination games are cooperative rather than adversarial. For contrast, consider Proof of Work as it is used by the Bitcoin network. Because running mining hardware costs money in the form of electricity and because only one node can get the reward in each block, the game is inherently zero-sum: when I win, I earn a block reward; every other miner loses money. It is the adversarial nature of such games that leaves us unsurprised when concerns like selfish mining start to crop up.

As an even better example, consider Token Curated Registries (TCRs). We won’t spend time describing the mechanics of TCRs here, because we plan to cover the topic in more detail in a later post. But for now, the important thing to know is that TCRs allow people to place bets, with real money, on whether or not a given item will be included in a list. The idea is that, like an efficient market, the result of the betting will converge to produce the correct answer.

One problem with mechanisms like TCRs is that many people have a strong preference against playing any game in which they have a significant chance of losing — even if they can expect their gains to make up for their losses over time. In behavioral psychology, this result is known as loss aversion and has been confirmed in many real-world experiments.

In short, Proof of Work and TCRs are both adversarial mechanisms for resolving conflicts and coming to consensus. To see how Wikipedia resolves similar conflicts using cooperative solutions, let’s dive deeper into what dispute resolution looks like on the site.

Dispute resolution

So how does a dubious change to Mahatma Gandhi’s page actually get reverted? In other words, what is the process by which that work gets done?

When a dispute first arises, Wikipedia instructs the editors to avoid their instinct to revert or overwrite each other’s edits, and to take the conflict to the article’s talk page instead. Some quotes from Wikipedia’s page on Dispute Resolution point to the importance of the Talk pages:

“Talking to other parties is not a mere formality, but an integral part of writing the encyclopedia”

“Sustained discussion between the parties, even if not immediately successful, demonstrates your good faith and shows you are trying to reach a consensus.”

Editors who insist on “edit warring”, or simply reverting another editor’s changes without discussion, risk violating Wikipedia’s 3RR policy, which prohibits editors from reverting 3 changes on a given page in 24 hours. Editors who violate 3RR risk a temporary suspension of their accounts.

If initial efforts by the editors to communicate on the Talk Page fail, Wikipedia offers many additional solutions for cooperative coordination, including:

• Editor Assistance provides one-on-one advice on how to conduct a civil, content-focused discussion from an experienced editor.
• Moderated Discussion offers the facilitation help of an experienced moderator, and is only available after lengthy discussion on the article’s Talk page.
• 3rd Opinion, matches the disputants with a third, neutral opinion, and is only available for disputes involving only people.
• Community Input allows the disputants to get input from a (potentially) large number of content experts.

Binding arbitration from the Arbitration Committee is considered the option of last resort, and is the only option in which the editors are not required to come to a consensus on their own. According to Wikipedia’s index of arbitration cases, this mechanism has been invoked only 513 times since 2004 — a strong vote of confidence for its first-pass dispute resolution mechanisms.

A notable theme of all of these dispute resolution mechanisms is how uniformly cooperative they are. In particular, it is worth observing that in no case can any editor lose something of significant economic value, as they might, for instance, if a TCR was used to resolve the dispute.

What the editor does lose, if their edit does not make it into the encyclopedia, is whatever time and work she put into the edit. This risk likely incentivises editors to make small, frequent contributions rather than large ones and to discuss major changes with other editors before starting work on them.

“Losing” may not even be the right word. As long as the author of the unincluded edit believes in Wikipedia’s process as a whole, she may still view her dispute as another form of contribution to the article. In fact, reputation-wise, evidence of a well-conducted dispute only adds credibility to the user accounts of the disputants.

Reputation without real-world identity can work

Another lesson from Wikipedia relates to what volunteer editors have at stake and how the site’s policies use that stake to ensure their good behavior on the system.

Many blockchain systems require that potential participants stake something of real-world value, typically either a bond or an off-chain record of good “reputation”. For example, in some protocols, proof-of-stake validators risk losing large amount of tokens if they don’t follow the network’s consensus rules. In other networks, governors or trustees might be KYC’d with the threat of legal challenge, or public disapproval, if they misbehave.

Wikipedia appears to have found a way to incentivize participants’ attachment to their pseudonyms without requiring evidence of real-world identity. We believe this is because reputation in Wikipedia’s community is based on a long-running history of small contributions that is difficult and time-consuming to fake, outsource, or automate.

Once an editor has traded anonymity for pseudonymity and created a user account, the first type of reputation that is typically considered is their “edit count”. Edit count is the total number of page changes that the editor has made during his or her history of contributing to Wikipedia. In a sense, edit count is a human version of proof-of-work, because it provides a difficult-to-fake reference for the amount of work the editor has contributed to the site.

If edit count is the simplest quantitative measure of a user’s total reputation on the site, its qualitative analog is the user talk pages. Talk pages provide a complete record of the user’s individual edits, as well as a record of administrative actions that have been taken against the user, and notes and comments by other users. The Wikipedia community also offers many kinds of subjective awards which contribute to editor reputation.

Reputable editors enjoy privileges on Wikipedia that cannot be earned in any other way — in particular, a community-wide “benefit of the doubt”. Wikipedia: The Missing Manual’s page on vandalism and spam provides a good high-level overview, instructing editors who encounter a potentially problematic edit to first visit the author’s talk page. Talk pages with lots of edits over time indicate the author should be assumed to be acting in good faith, and notified before their questionable edit is reverted: “In the rare case that you think there’s a problem with an edit from this kind of editor, chances are you’ve misunderstood something.”

On the other hand, the same source’s recommendations for questionable edits by anonymous editors, or editors with empty talk pages, are quite different: “If you see a questionable edit from this kind of user account, you can be virtually certain it was vandalism.”

Blockchains which adopt similar reputation mechanisms might expect to see two major changes: slower evolution of governance and sticky users. And while no public blockchains that we’re aware of have made significant use of pseudonymous reputation, it’s worth noting that such mechanisms have played a significant role in the increasing adoption of the Dark Web.

Assigning power based on a long history of user edits means that the composition of the governing class necessarily changes slowly and predictably, and is therefore less subject to the “hostile takeovers” that are a fundamental risk for many token-voting-based schemes.

Sticky users are a consequence of the slow accretion of power: experienced users tend to stick to their original pseudonym precisely because it would be time-consuming to recreate a similar level of privilege (both implicit and explicit) under a new identity.

All in all, Wikipedia’s reputation system may represent an excellent compromise between designs offering total anonymity on one hand and identity models built on personally identifying information on the other. In particular, such a system has the benefit of allowing users to accrue reputation over time and resisting Sybil attacks by punishing users if and when they misbehave. At the same time, it also allows users to preserve the privacy of their real-world identities if they wish.

Iteration over finality

Wikipedia’s encyclopedic mission, by its very nature, can never be fully completed. As such, the site’s mechanisms do not attempt to resolve conflicts quickly or ensure the next version of a given page arrives at the ultimate truth, but rather, just nudge the encyclopedia one step closer to its goal. This “iterative attitude” is particularly well-suited to assembling human input. Humans often take a long time to make decisions, change their minds frequently, and are susceptible to persuasion by their peers.

What can Radicle, and other p2p & blockchain projects, learn from Wikipedia in this regard? Up to this point, many protocol designers in blockchain have had a preference for mechanisms that achieve “finality” — that is, resolve to a final state, with no further changes allowed — as quickly as possible. There are often very good reasons for this, particularly in the area of consensus mechanisms and yet, taking inspiration from Wikipedia, we might just as easily consider designs that favor slow incremental changes over fast decisive ones.

For instance, imagine a protocol in which (as with Wikipedia) it is relatively easy for any user to change the system state (e.g. propose a new trusted seed), but such a change might be equally easily reverted by another user, or a group of users with superior reputation.

Or consider a protocol in which any state change is rolled out over a long period of time. In Osrank, for instance, this might mean that trusted seeds would start out as only 10% trusted, then 20% trusted one month later, and so on. While such a design would be quite different from how Wikipedia works today, it would hew to the same spirit of slow, considered change over instant finality.

Attacks and defenses

While the previous section covered a number of ways in which Wikipedia’s mechanisms have found success up to this point, the true test of a decentralized system is how vulnerable it is to attacks and manipulation. In this section, we introduce Wikipedia’s perspective on security. We then examine some of Wikipedia’s vulnerabilities, the attacks that play upon them and the defenses the Wikipedia community has evolved.

How Wikipedia Works: Chapter 12 discusses the fact that nearly all of the security utilized by Wikipedia is “soft security”:

“One of the paradoxes of Wikipedia is that this system seems like it could never work. In a completely open system run by volunteers, why aren’t more limits required? One answer is that Wikipedia uses the principle of soft security in the broadest way. Security is guided by the community, rather than by restricting community actions ahead of time. Everyone active on the site is responsible for security and quality. You, your watchlist, and your alertness to strange actions and odd defects in articles are part of the security system.”

What does “soft security” mean? It means that security is largely reactionary, rather than preventative or broadly restrictive on user actions in advance. With a few exceptions, any anonymous editor can change any page on the site at any time. The dangers of such a policy are obvious, but the advantages are perhaps less so: Wikipedia’s security offers a level of adaptability and flexibility that is not possible with traditional security policies and tools.

Below, we discuss three kinds of attacks that Wikipedia has faced through the years: Bad Edits (vandalism and spam), Sybil Attacks, and Editing for Pay. For each attack we note the strategies and solutions Wikipedia has responded with and offer a rough evaluation of their efficacy.

Bad edits: Vandalism and spam

The fact that anyone with an internet connection can edit almost any page on Wikipedia is one of the site’s greatest strengths, but perhaps may also be its greatest vulnerability. Edits not in service of Wikipedia’s mission fall into two general categories: malicious edits (vandalism) and promotional edits (spam).

While Wikipedia reader/editors are ultimately responsible for the clarity and accuracy of the encylopedia’s content, a number of tools have been developed to combat vandalism and spam. Wikipedia: The Missing Manual gives a high-level overview:

• Bots. Much vandalism follows simple patterns that computer programs can recognize. Wikipedia allows bots to revert vandalism: in the cases where they make a mistake, the mistake is easy to revert.
• Recent changes patrol. The RCP is a semi-organized group of editors who monitor changes to all the articles in Wikipedia, as the changes happen, to spot and revert vandalism immediately. Most RC patrollers use tools to handle the routine steps in vandal fighting.
• Watchlists. Although the primary focus of monitoring is often content (and thus potential content disputes, as described in Chapter 10: Resolving content disputes), watchlists are an excellent way for concerned editors to spot vandalism.

Given the incredible popularity, and perceived respectability, of Wikipedia, it’s safe to say that the community’s defenses against basic vandalism and spam are holding up quite well overall.

Sybil attacks

Sybil attacks, endemic to the blockchain ecosystem, are known as “Sockpuppets” in Wikipedia, and are used to designate multiple handles controlled by the same person. They are usually employed when one person wants to seem like multiple editors, or wants to continue editing after being blocked.

While Sockpuppets are harder to detect in an automated fashion than vandalism and spam, there is a process for opening Sockpuppet investigations and a noticeboard for ongoing investigations. Well-thought-out sockpuppetry attacks are both time-consuming to mount and defend against. While dedicated investigators (known as clerks) are well-suited to the task, it is impossible to know how much successful Sockpuppetry has yet to be discovered.

Hired guns — Editing for pay

Hired guns — editors who make changes to in exchange for pay — are becoming an increasingly serious concern for Wikipedia, at least according to a 2018 Medium post, “Wikipedia’s Top-Secret ‘Hired Guns’ Will Make You Matter (For a Price)”, in which Author Stephen Harrison writes,

“A market of pay-to-play services has emerged, where customers with the right background can drop serious money to hire editors to create pages about them; a serious ethical breach that could get worse with the rise of—wait for it—cryptocurrency payments.”

In the post, Harrison draws on a number of interviews he conducted with entrepreneurs running businesses in this controversial space. According to Harrison, businesses like What About Wiki, operate in secret, utilizing large numbers of sockpuppet accounts and do not disclose the fact that that their edits are being done in exchange for pay.

In the past, Wikipedia has prohibited all such activities and in fact, businesses like What About Wiki violate Wikipedia’s Terms of Use — a legally binding agreement. However that seems to be changing. According to Harrison,

“A 2012 investigation discovered that the public relations firm Wiki-PR was editing the encyclopedia using multiple deceptive sock-puppet accounts for clients like Priceline and Viacom. In the wake of the Wiki-PR incident, the Wikimedia Foundation changed its terms of use in 2014 to require anyone compensated for their contributions to openly disclose their affiliation.”

The upshot is that since 2014, paid editing is now allowed on the site so long as the relationship is disclosed.

And yet, major questions remain. For one thing, at least according to Harrison’s analysis, companies acting in compliance with Wikipedia’s disclosure policy represent just a small fraction of the paid editors working (illegitimately) on the site. For another, he argues that complying with Wikipedia’s policies leads to paid editors making less money, because there’s a lower chance their edits will be accepted and therefore less chance the clients will be willing to foot the bill.

This leads to a final question, which is whether paid edits can ever really be aligned with the deep values that Wikipedia holds. For instance, one of Wikipedia’s main behavior guidelines is a prohibition against editors who have a conflict of interest in working on a given page. It’s hard to imagine a clearler conflict of interest than a paid financial relationship between the editor and the subject of a page.

DAOs

Wikipedia’s success is inspirational in terms of what can be accomplished through decentralized coordination of a large group of people. While we believe that the decentralized web still has many lessons to learn from the success of Wikipedia — and we’ve tried to touch a few in this post — a great deal of work and thinking has already been done around how a large organization like Wikipedia could eventually be coordinated on-chain.

Such organizations are known as Decentralized Autonomous Organizations (DAOs), and that will be the topic of a future post.

Photo by designwebjae (Pixabay)

The post What the decentralized web can learn from Wikipedia appeared first on P2P Foundation.

The Internet didn’t quite deliver on its original promise and today we’re talking with people who are fixing it.”

We’re very glad that Andrey Salomatin, creator of Code podcast (see original post here), got in touch to let us know about this recent podcast on what’s happening lately in P2P decentralized web development. If you’re interested in the history Scuttlebutt (a decent(ralised) secure gossip platform) and how it works; or you want an introduction to the Dat project (a nonprofit-backed data sharing protocol for applications of the future); and a “vision for the decentralized future”, Andrey and his five guests share their experiences and reflections. This is certainly more technical than most of the material we share on the P2PF blog, but there is plenty of food for thought here for anyone interested in the future of the decentralized web.

Andrey Salomatin: Slack servers are down and work stops. Facebook sells users’ personal data to third-parties with no negative consequences to the company. Turkey successfully blocks citizens’ access to Wikipedia. Those are all results of peoples’ decisions of course, but there’s also something else at play. Our mainstream technology stack makes execution on all of those decisions ridiculously easy.

The Internet didn’t quite deliver on its original promise and today we’re talking with people who are fixing it.

Guests

• Jon-Kyle Mohr
• Zenna Fiscella
• Mathias Buus
• Christian Couder
• Mikey

Outline

• 00:07 Introducing the topic
• 01:57 Limitations of centralized systems
• 04:57 Introducing Jon-Kyle
• 05:57 Introducing Zenna
• 08:23 Introducing Mathias
• 11:20 BitTorrent and scale
• 14:19 Multiple versions of the truth, version control systems (Jon-Kyle)
• 19:16 Introducing Christian
• 20:08 Git internal structure
• 22:03 Benefits of Git architecture
• 27:03 Why is Git not decentralized
• 32:23 How Dat started, tech description of the protocol (back to Mathias)
• 45:28 Dat usecases (Mathias and Jon-Kyle)
• 51:42 Future of Dat (Mathias)
• 53:54 Introducing Mikey
• 55:07 History of Scuttlebutt
• 56:22 How Scuttlebutt works
• 65:30 Usecases for Scuttlebutt
• 69:29 Vision for the decentralized future (Zenna)
• 71:39 Final thoughts on the topic, summary, thanks

Find us in P2P networks

• This episode in Dat:
  dat://084e8ceae2fd1012e5368a70908acdb7aa92c3f5de0c62d14ef5beacbf19295d
• This episode in IPFS:
  QmVVjxxitJrhNoRkTe3nJ2SztWMx9tYnpURuAVAY3Dx75y
  cheat through a https gateway
• Andrey in Scuttlebutt:
  @RP01FOdcs/QABLmMxTGe1U9myUfSLN/5ItlXQcp7oWQ=.ed25519
• Zenna in Scuttlebutt:
  @3ZeNUiYQZisGC6PLf3R+u2s5avtxLsXC66xuK41e6Zk=.ed25519
• Mikey in Scuttlebutt:
  @6ilZq3kN0F+dXFHAPjAwMm87JEb/VdB+LC9eIMW3sa0=.ed25519

Links

• All things Decentralization / Open Source / Fabrication from Zenna
• Website peer-to-peer-web.com
• Article Achieving Scale in the Decentralized Web by Paul Frazee from Beaker Browser
• IPFS

Links: Git

• Git
• Git LFS
• Video of the talk “Git From the Bits Up” by Tim Berglund

Links: Dat & Beaker

• Dat Project
• Beaker Browser
• Enoki
• peer-to-peer-web.com

Links: Scuttlebutt

• Scuttlebutt.nz
• Scuttlebutt grants process
• Collection of articles Scuttlebutt stories

Episode was produced by Andrey Salomatin.

Music by Mid-Air!

Code Podcast is about ideas that shape the way we build software. It’s like Planet Money for developers.

Each episode we interview people with different views on a single topic. We break down complex ideas to present why and how they are used to build modern software.

Photo by duiceburger

The post Code Podcast: P2P, People to People appeared first on P2P Foundation.

This year I found myself more “available” than previous years and decided to commit to being a “Space Wrangler” for this year’s Mozilla Festival. I was warned that it was a fairly heavy commitment, however so far it’s been great. Commitments don’t seem to be so heavy when you’re shouldering them with other like-minded people.

This year the Festival is divided into spaces that represent the core values of Mozilla, laid out in their manifesto.

• Decentralization
• Digital Inclusion
• Open Innovation
• Privacy and Security
• Web Literacy
• Youth Zone

All of this to be infused with OpenNews sessions and artistic installations in keeping with the various themes.

More detail on the various spaces can be found on the Mozilla Festival website

Scratching the Surface

I’m helping to wrangle the Decentralization Space. Decentralised, Distributed or Peer-to-Peer systems can range from the perhaps more obvious technical applications to include finance, energy, journalism, healthcare, governance and a whole host of other things.

I’ve been interested in decentralised systems for a while, check my last post for more about that but I was wholly unprepared for how much things have moved on over the years.

By scratching under the web’s surface and actively trying to improve my own knowledge of the subject I realised that there was so much more going on than I had imagined. I’d heard of BitTorrent, Tor, Bitcoin and the Blockchain but I had no idea that many other distributed and decentralised systems existed. Here’s a what I discovered:

Dat – which I’d heard of as a tool for data sharing in the journalistic world, can in fact be used as a general purpose distributed data protocol. Currently Dat is the protocol of choice for a certain peer-to-peer browser! WAIT – THERE’S A PEER-TO-PEER BROWSER!? How does that even work? Well, I dug deeper … there’s a great video explainer on the BeakerBrowser website. You don’t have to use Dat for distributed data storage and transfer, you could use IPFS – there are long discussions about that.

The further I dug, the more I found. There was a project called Web2Web which “takes centralized servers out of internet equation”. There was BlockStack and a whole BlockStack Summit! There’s ZeroNet. There are subreddits dedicated to decentralisation! There are foundations and other groups all dedicated to P2P.

Technology is an Enabler

And then of course there is Blockchain, SO MUCH BLOCKCHAIN. Blockchain for Healthcare, Blockchain for Mainstream Finance, even Goldman Sachs is actively looking at Blockchain! I’m not sure how to feel about this any more! But wait, I do know how to feel. I feel passionate about this because decentralisation is so much more than the technology that enables it. Decentralisation has the potential to affect us and society in so many positive, significant and diverse ways.

I’ve spent my entire adult life pondering about how systems work. Seventeen years ago I came to live in Italy. We settled in an area, where I saw first hand how decentralised systems actually worked; ranging from community driven hubs such as the ARCInetwork of Casa Del Popolos (literally People’s Houses) to fully functional cooperatives running public libraries or providing schooling for children.

At the same time I’ve witnessed the increasing centralisation of power and control both online and off. An insidious consolidation that I’m willing to bet will benefit very few of us.

Decentralisation crosses over into sustainability. I remember when incentives were provided for Italian homes to add solar-panels and how excited I was that we’d would be allowed to sell electricity back to the national grid. What a beautiful concept! Such a pity it was scrapped!

However, the belief in decentralised systems is a philosophy, the implementation of them is a very real discipline. Slowly but surely it feels like things are changing – the technology is becoming viable and people are switching on to the concept.

Opportunity

There is an opportunity now at the 2017 Mozilla Festival to raise awareness around decentralisation, to come together (and then disperse again) with the idea that we can push back against centralisation, to cooperate and support each other in our endeavours to distribute control in a number of crucial areas. The Internet, as ever, plays a key part in allowing decentralisation to flourish.

Above, I touched on a few examples of decentralisation, there are so many more. So far we’ve had around 50 proposals for sessions in the Decentralization Space, today is the last day for submissions (August 1, midnight Pacific Time), but it’s fine just to get a place holder in there and flesh out on the Mozilla Festival Github Pages

If you haven’t already, please consider proposing a session and do make space in your calendar for the Mozilla Festival on the 27th to 29th of October in London.

Lead photo and sculpture “New Rising Sun” courtesy of Paolo Benvenuti

The post Decentralise Everything appeared first on P2P Foundation.

It’s funny how things turn out. Six years ago when I decided to blog about my thoughts about a ‘radically new’ and decentralised web; snappily titled “P2P Web Apps — Brace yourselves, everything is about to change”, I thought decentralisation was imminent. It wasn’t.

And when I say ‘radically new’ I actually mean ‘radically old’ because as mentioned in my original post on this topic — the original internet or ARPANET as it was known was supposedly built to withstand a all sorts of catastrophes.

Decentralised networks have many advantages, one of which is resilience.

That was Then

Back in 2011 I was convinced that the way things were going, a new decentralised web was just around the corner.

But hey, naivety is underrated! If I had been a bit more cynical I probably wouldn’t have written that blog post with quite so much gusto — I may not have written it at all. And that would have been a shame, not because the world needed to know, but because nobody can comment on blog posts that don’t exist.

The comments on that old blogpost were what really made it for me, I did my best to reply to most of them but I’m by no means an expert. That said, the commenters were extremely nice about calling out my naivety.

Naivety — that word again. Although I don’t think I underestimated the vested interests that the big internet players held by keeping the web centralised, I assumed that there was a strong appetite to change this and that crucially the technology existed to make a secure, robust, scalable, decentralised web a reality. The second assumption was soon tackled in the comments. Decentralisation is no mean feat it appears.

Why are we Centralised?

Centralised services can be convenient for both supplier and consumer and while we can hypothesise about why it’s often in the supplier’s interest to keep the web centralised, it’s difficult to convince the average consumer as to why they should care.

We touched on the various advantages of decentralisation, summarised:

1. Resilience — fewer Single Points of Failure
2. Scalability — when clients become servers, things just scale better
3. Privacy/Security — your data isn’t stored at a central point

It’s clear why suppliers would care about robustness, but what about consumers and the general population?

Right now it’s too easy for people to shut down parts of the internet, whether we’re talking about “cyber-terrorists” or frightened governments — they can both legally or illegally shut down core web services. One premise of decentralised systems is that they would be more resilient to those attacks.

The ability to scale automatically — and at little extra cost per user — must also be attractive to suppliers of services, especially to startups. Implemented properly, hosting costs pretty much disappear.

Our Privacy, Our Security, Our Data

Finally we come to the nub of the matter — privacy and security. Many of us want this for sure, however it’s telling that despite the significant advantages of point 1 (resilience) and 2 (scalability), few of the established service suppliers are embracing decentralisation. Note that when you use services like Google or Facebook they are not actually free — you are paying for them with your valuable data — for one, data is often used to create more efficient advertising models. To give up that source of income makes no sense at all to many of this new establishment.

It should be clear that we cannot let market forces ride roughshod over our privacy and security — and note that keeping data in a central repository is not a prudent security or privacy measure.

This is Now

So it’s warming to hear that organisations such as Mozilla hold decentralisation as one of their key values and as such have made decentralisation a ‘space’ at the 2017 Mozilla Festival.

The only way we can do any difference is by limiting the powers of these companies — by governments stepping in — but unfortunately the EU or the US don’t seem to have any interest in doing this. — Peter Sunde

If you read “We’ve lost the internet, it’s all about damage control now” (the article that the quote is taken from) it feels like it’s very much time to act!

It’s also a very exciting time to explore technologies like the blockchain and crypto-currencies, P2P (Peer to Peer) browsers and blogs, but decentralisation is not limited to The Internet — many organisations are seeking a decentralised way of working and crowdsourcing is, in it’s own way, a successful form of decentralisation.

Again it’s the people taking part and the discussion that’s important. Sure, we’re planning to get some of the world’s leading thinkers and builders of decentralised systems in the same space — but our plan is to raise awareness and facilitate participation, so crucially we hope to attract people who are not experts — we want as many people to be involved as possible in what will be concerted effort to put decentralisation on ‘the agenda’.

We owe it to ourselves and coming generations to be less naive about our future web.

So if you feel like finding out more and contributing to the debate, I’d highly recommend you come to the Mozilla Festival this year and if you have ideas for a session you’d like to run, now’s the time to submit them.

Also if you have ideas around the type of activities we could run in the Decentralization Space, please let us know.

If you’re interested in reading more about the Decentralization Space at the Mozilla Festival, fellow ‘space wrangler’ Ian Forrester from BBC R&D has written about his perspective in “Decentralization, the people, power, money and the future of the internet”.

Image used by permission from the artist, Paolo Benvenuti.

The post Decentralise Now appeared first on P2P Foundation.