Secure publishing platform
About everyBit
Right now, most individual publishing on the internet happens through a small number of gatekeepers. These institutions control what we can and can't publish, and how this content is filtered and displayed to others. These same gatekeepers maintain our identities and our networks, encouraging us to friend or follow others based on hidden algorithms which align with their own economic incentives.

There are ways to opt-out of this system, ways to manage our own content and identities directly. So far, though, these systems have been application specific, each tool addressing a specific need. And they are challenging to use, often needing to be configured and compiled from the command line.

The goal of everyBit is to create a secure, decentralized publishing platform. One that makes it easy to share content with exactly who you want, and no one else. The everyBit platform will provide an open system to let users manage their identities without the need for a trusted third party. It will let people encrypt private data for themselves and for others, just as easily as they post messages to a forum.

For more information about everyBit, read through our Q&A below:
What is a gatekeeper?
It's anyone who comes in-between the content you want to share, and people you want to share it with. Or, conversely, anyone who comes between content you want to view, and yourself. Gatekeepers insert themselves as middlemen between you and your contacts generally.
Who are the gatekeepers right now?
Facebook is a gatekeeper. Twitter is a gatekeeper. LinkedIn is a gatekeeper. These companies manage your content and connections on your behalf. They decide what you can and can't publish, who you can and can't connect with and under what conditions you can interact. They control the contents of your newsfeed and decide how it will be sorted.
What's so bad about the gatekeepers?
On the surface, it may not look like there's much of a problem. The gatekeepers appear to be generally tolerant of the things we want to share and who we connect with. This is an intentional strategy on their part. Look deeper, and you can see that the cracks and disconnects run deep. The dynamic between us and our social networks has begun to turn nasty: the more we use these networks, the more leverage they have over us, and they know it.

Maybe you heard about how Facebook ran (undisclosed) experiments on its users involving emotionally charged status updates. That's just one example of how social networks can abuse their power. The basic problem is that our interests as users, and the corporate interests of Facebook, Instagram (also owned by Facebook), Twitter, and LinkedIn, line up only in very general ways.

There's an old adage: if you aren't paying for the product, you are the product. In other words, if a service is free, then you're being "sold" to advertisers who want to reach you. In reality, the relationship between you and the existing social networks is much more complicated, and in some ways much worse.

Consider the following:
  • You want privacy settings that are simple and effective. Companies want to use your data, for example by selling it to their customers or by more effectively targeting the ads you see. So it's in their interest to make those settings complicated and hard to use.
  • Gatekeepers centralize the storage and flow of information, making them lovely targets for political repression and spying (Turkey doesn't hate Twitter, it hates the idea of a decentralized twitter with no secret keyhole they can look through.)
  • Websites want to foster a sense that your username, profile, and connections are yours to keep and use forever and without cost. That encourages you to invest time and energy into building these things, just like "tax free" zones attract entrepreneurs. However, you have no guarantee whatsoever that you can keep using your identity or their services for free, or even at all. If you want to leave, it may be extremely difficult or impossible to take your content and connections with you.
  • All of the major social networking sites have people who understand this dynamic. They know that the more time you invest adding content and friends, the more locked in you become to their system, and the more dependent you become on it. The more you do FOR them, the more they can do TO you. This is not just theoretical speculation! Facebook has already begun tweaking their newsfeed in a ways that makes it much harder for power users to have their posts seen, unless they "pay to promote."
As things stand right now, you are a digital sharecropper! And while it may make sense to plow someone else's land in exchange for the benefits you get right away, don't build your house there!

The goal of the everyBit platform is to make it easy for users to build on their own land. More precisely, we are creating tools for developers to build websites that serve a variety of publishing and networking needs, but which all share a common framework that gives users ultimate control and portability for their content and connections, and gives them universality and security in their usernames.

Right now, the websites built on top of the everyBit platform (like our demonstration website, I.CX, are much more limited in features than Facebook or LinkedIn (though we already offer some features no one else does, like fully encrypted messaging and multi-threaded conversations that make it easy to follow the signal and ignore the noise). The most important thing we offer, right now, is the opportunity to be a pioneer and homestead your own property, with an identity that's yours to keep forever, uncontrolled (and uncontrollable) by any third party. That's not for everybody, and there will be some rough parts to being out on the frontier.

As an open source project open to collaboration from everyone, we also offer the opportunity to actively participate in making this frontier, and the community that settles there, better for all homesteaders.
Don't we need gatekeepers?
It turns out we don't. At least, not anymore. The long arc of publishing history shows an unmistakable trend towards disintermediation. We've gone from small libraries of expensive manuscripts, written by a select handful of literate scribes and rationed out carefully to the unscrubbed masses, to free webhosts like Tumblr who offer a (mostly) unrestricted and easy to use service for anyone to publish their thoughts in a way that everybody can access.

Some of the problems that gatekeepers existed to solve were only problems from the perspective of people and organizations whose power depended on restricting access to information. Other gatekeepers, like the 20th century newspapers, solved the problem of curating content with broad interest and distributing it in the context of scarce and expensive tools for production, and giant economies of scale.

In the early days of the internet and right up until today, gatekeepers have helped us manage the signal to noise ratio. They make it easier to find relevant information, limit the amount of spam we receive, and present us with news customized to our liking.

However, once you divide up the legitimate problems that gatekeepers solve into small enough pieces, it's clear that what we need isn't gatekeepers, it's filters and tools for publishing. There's no reason why that should come with the side-effects of locking us in, or artificially restricting what we can see or publish.

The basic thesis behind everyBit is that the value of content can be inferred from how we interact and relate to it. In an open system, anyone will be able to read and interpret the relationships between (public) content. Google was the first organization to figure this out in a big way. Their innovative page rank system lets every page "vote" with links on how valuable it thinks other webpages are.

What Google does at the page level, everyBit could help others do at the level of individual pieces of content and at the level of identifiers (usernames) in general. Anyone who wants can layer a set of rules on top of puffs (the basic unit of shared content in the everyBit platform) and relationships between them, establishing the value of content in different contexts. These rules themselves could be proprietary, as part of a secret sauce that powers the next generation of search engines. Or they could be open and free to fork and improve upon, like a Wikipedia for filtering algorithms.

The key here is that we can, individually and collectively, in a decentralized way, solve the problems that justified the existence of monopolistic gatekeepers.
Why should we trust the developers of everyBit anymore than we trust Facebook or Twitter?
Don't trust us. Our code is open source. Go check it out. Our platform is based on an open standard. We can no more lock you in with everyBit, than Apple can lock you in with MP3 downloads (unlike their proprietary ACC music files, which lock you in to iTunes.)
What should I know if don't speak code?
You should know that we've aligned our business model with one and only one thing: adoption of the platform. If it grows, if people like using it, we win. We're building a system from the ground up to make users' content and their connections as portable as possible.

Imagine a future where your entire social network can be packed into a single url. Imagine this url contains a full list of the people you want to follow, along with detailed instructions as to what types of content you want to view from each one (images from Tom, MP3's from Karen), and the the order in which you want it sorted.

Now imagine you could generate ad hock social networks and groups at will, and bring those network with you to any one of dozens or hundreds of different websites, each one providing a different interface or set of tools for accessing your information.

This is what we are dedicated to building.
Fantastic! How can I get involved?
Help us develop the everyBit platform, or use it as the data source for your application.

If you don't have any programming skills, there are a variety of non-technical things you can do to help. Spread the word! Tell you friends. Copy over your username and content from one of the existing social networking sites.

Use everyBit for all of your communication. We may not have as many features as gMail or outlook, but you don't have to worry that anyone is spying on your communication, or mining your personal data to sell to advertisers.
How can I be sure that messages sent privately on the everyBit network are truly private?
Math. All private messages are encrypted right on your computer, before they are sent over the network. We are using the same highly trusted encryption used by crypto-currencies like bitcoin. There's a billion dollars available for any thief who can defeat this algorithm, and a longstanding million dollar bounty for any academic who proves it can (or can't) be done.
If everything is free and open source, how do the developers of everyBit intend to make money?
Currently you can bring over your usernames from Reddit or from Instagram (and you can now import your Instagram content!) as second level usernames (ie .reddit.myusername). Over the next couple months, we plan to add support for usernames from OpenID, Facebook, LinkedIn, Diaspora, Namecoin, Tumblr and others. However, the only way to get top level usernames will be through our upcoming fundraising campaign. We intend to sell these usernames in tiers which depending on their length. After the initial campaign, we will retain any unsold usernames of 3 characters or less, as well as some special ones (like .username) to be reserved forever or sold later. All other usernames will become available for free after that.

We are working to decentralize the username database as soon as we can. Our original roadmap called for this to happen by mid 2015, and so far we are still are on-target. In addition to providing a sense of security for users about their names, a robust, decentralized system for usernames is in our best financial interests. It means we are no longer responsible (liable!) for maintaining, updating and making available every single record, and it removes the final "single point of failure" from the everyBit system, encouraging wider adoption.
Why did you decide to monetize usernames?
We chose this revenue model because it's minimally intrusive for the vast majority of users of the system. We don't need to depend on ads, or selling user data, or offer paid subscriptions of any kind. Unless your username is very short or one of a tiny percentage of names we've already claimed, you should have no trouble getting it for free... unless someone else has already claimed it. See the section above about our revenue model for how names can be registered.
Will the usernames you've reserved be enough pay back investors?
Only if the platform becomes widely adopted. But of course if it doesn't, no revenue model could generate much income. A single large tract of land in the heart of a thriving city could be worth as much as a large corporation; a million acre claim on the moon isn't worth $10.
How often will I have to renew my username? Can it ever be taken away from me?
Never. It's yours for life, with zero fees, for so long as users are willing to collectively maintain the table of usernames, something that every user of the system has an incentive to do.

The only requirement is a technical one: to remain active, the record must be updated at least once per year. Since username records are updated every time you publish content, a single puff that says "I'm alive" is enough to make sure your username doesn't expire.

This requirement means that abandoned usernames, or ones with lost or unrecoverable private keys, will eventually be released back to the general public.

We want to be as clear as possible that usernames in the everyBit system are not company names, trademarks, or domain names, and there are no mechanisms to forcibly transfer them from one party to another. The only way to change ownership of an existing username is to update the record using a message signed by the current owner, using their private key. Any redress of grievances related to the use of a particular username would have to be done extrinsically to everyBit.

Installation instructions

Username lookup (whois)

Technical specification
The heart of the system
The core of the everyBit platform consists of a username table managed by private keys, individual chains of content for each user, and a couple special blocks of content for user preferences and profile information.

Every username has an entry in a Distributed Hash Table (DHT). Entries contains the following fields: Usernames are formed with a string of alphanumeric characters. Once a username is created, it is permanently owned by whoever controls the private keys, subject only to the requirement that the user publish at least one piece of content per year. The updated field stores the date of the most recent update to the username record. Anytime new content is created, the user updates the latest field to point to their most recent content.

The owner of a username controls their sub-user space as well. For example, user .foo can create sub-users and .foo.fighters. There are several layers of keys in the record. New content is signed using the private key related to the defaultKey. The signature of a puff is checked against this same key to make sure it's a valid signature for that user. In order to add or modify a sub-user, the owner creates an update request and signs it with the private key related to their adminKey. The only way to change the adminKey or rootKey is to sign a message with the private key related to the rootKey. This is like a master key, and should be stored with the highest level of security. Cold storage is recommended. The default everyBit client makes it easy to view QR codes for each of the private keys.

IMPORTANT: All signing of content and update messages happens on the client-side. Private keys should never be sent to a server.

For more about usernames, see the Username rollout section below.

The main unit of content in the everyBit platform is called a puff. It is structured as follows (required fields are indicated with an asterisk): The identity of the person who created this puff is stored in username. The zones field serves to identify the intended recipients (if any) or to indicate that a puff is related to another user. It works like the @ sign in twitter.

Every piece of content has a unique id stored in the sig field. To generate this id, a user combines all of the fields of a puff (except the sig itself!) into a string and signs it using their private key. This signature serves as proof that the content really was created by the username listed. This also prevents accidental duplicate posts: two puffs that have the same sig also have the same content, and are in fact the same puff.

The version field corresponds to the version of the specification used by the puff. Right now the current version is 0.4.X. Until version 1.0 is reached, there may be changes to the structure of a puff. However, by specifying a version with each puff, it should be easier to deal with backward and forward compatibility issues.

The payload section of a puff contains the actual content, and meta-data about that content. The only two required fields are type and content. The others fields may or may not exist, and are subject to conventions about what they contain, instead of being specified directly. The type field is the same as the MIME type sent in HTTP headers. A single puff can only have one content type. This is vital part of the everyBit platform -- it allows developers to treat each piece of content in the system as an atomic unit, and build a newer, much more powerful generation of RSS-like readers and search engines, ones which facilitate fine-grained aggregation (e.g. Show me the MP3's posted by .bach, any image from .ansel, and just the PGN's created by .fischer (but none of his annoying text posts!).

The payload section's content field contains the main content of the puff. This is always a string. For compound content types it is serialized in JSON format.

There are no rules about the other fields which can be included in payload, other than technical limitations to how they are specified (keys must be alphanumeric and less than 128 characters, values must be storable in JSON format).

In order to re-publish someone else's content, the entire puff is bundled up and put into the content field of the new puff, with type specified as "puff".

Note: The order of the top-level fields is important. For a puff to be verifiable the top-level fields (username, routes, previous, version, payload and sig) must conform to the order listed above. Field names within payload should conform to the order listed above, but that ordering is not currently required.

Profile and preferences
Every username has two special blocks of content associated with it. Both of them contain arbitrary key/value pairs related to that user. The profile block is for (generally public) information the user wishes to share about themselves. It could contain a field for their avatar or photo, information about where they work or how to contact them.

Design principles
The design of the everyBit platform is driven by the following core beliefs:
By convention, external dependencies should *not* be introduced into a puff. So if the type is HTML, then all JavaScript and CSS should be included directly in the content. Images can be included inline using the data:image/png specification.

How I learned to stop worrying and love immutability
Because of how puffs are constructed and chained, there is no way to edit a single puff without changing its id (signature), and disrupting the chain of content published thereafter. This is an intentional design decision. Here's why we do it this way:

When user replies to content, and embeds this parent puff's id in the new puff's parents array, they can be assured that so long as the puff they replied to still exists, it will not change (it's immutable). This creates an official, digitally signed conversation between the parties (that may be public or private). No party can claim to have written something they didn't, or change their words to make another user look bad. Because all discussion is contextual, we intentionally break all incoming connections to that users' more recent puffs as well.

This is an extreme thing to do, but we believe that the integrity of the system depends on it. We wish to encourage a culture where changing the content of a puff (especially one that has been around for a while and has generated a significant number of replies), is considered an extreme thing to do.

We wish to extend the cultural norms established by bloggers who pioneered the use of strikethrough to show that they edited a document for accuracy, usually based on feedback from others, and to fostering a culture of honesty and integrity in communication. Everyone makes mistakes, and we've found that there is a generally high level of tolerance to these. To encourage users to amend previous puffs instead of deleting and re-creating them, the default client shows all replies by the original author first. This way, the "OP" can post a reply amending their previous puff and know that this reply won't get buried by a torrent of angry replies that pick up on a mistake or omission.

Another way to mitigate the need to break your full content history just to correct a "bad" puff is to use different sub-usernames for different purposes. For example, if you create a everyBit-enabled toaster that sends out a new puff any time the toaster leavin's are ready for harvesting, you could setup .username.toaster, or even .username.toaster.leavins, to publish these notifications. That way, if your toaster goes rogue and begins broadcasting bad information, you can roll back its chain of content without affecting your other streams of content.

Once the everyBit platform is fully implemented, we imagine that developers will create tools to implement some kind of version control system with content merging (so that you could publish a "diff" puff to update a previous one). We encourage such development, so long as it's build upon an understanding of everyBit's core strengths.