EveryBit is a software project aimed at enabling decentralized, secure publishing, allowing analogs to be built for blogs, Facebook, Twitter, and any other content sharing system. I heard about it from High Scalability or Hacker News around the same time I was hearing about various other distributed computing ideas. While EveryBit has many similar goals and broad technological decisions as IPFS, it is worth digging into some of the specifics.

For this analysis, I'll be working mostly off the the current whitepaper, so I may miss future changes as that is a live document.

User and key management

One of the first building blocks of the EveryBit framework is the key and account management system. An account consists of a username, some public keys, and some extra convenience data. A user proves they own an account by signing it (proving they have the private key paired with the public one bound to the account).

This is all supposed to be managed in a distributed hash table according to the whitepaper. This sounds great, until you follow their link on the DHT, and it says that it is currently centralized through one of their own servers (i.cx). They say they plan to decentralize it but there are no details, so it's hard to assess the design.

They add on an extra requirement that if a username has not published anything for 12 months, it becomes deprecated and can be claimed by a new person. This arbitrary requirement seems especially difficult in a decentralized setting given that they explicitly say they don't want to use consensus to determine account ownership. This leaves only straight up math to prove that someone is the owner of an account, which works fine since you can sign something with the account's public key. How does one prove they are the "new" owner of an account if they need to prove the non-existence of a year's worth of activity for that account?

Message history

The atomic units in EveryBit are javascript objects called "puffs". They are signed by their author, and link to the previous puff. This brings to mind Git and the bitcoin blockchain. Just like in both examples, forking is a very real possibility that must be addressed, but EveryBit does not talk about it. What happens if I create two messages (B and C) both of which say they come directly after A? If B and C are both signed by me, then how could one be "more valid" than the other, and how does someone show the real number of messages I posted? This problem reinforces the difficulty of proving 12 months of inactivity to take over an account (see above).

JSON encoding

The "puffs" that hold messages in EveryBit are signed by their author. To do the signing, the objects must be serialized to json in a 100% repeatable method. The whitepaper specifies that the json keys must be in canonical order but then that link goes to a section that does not specify an order. Instead it just says that all browsers seem to use the same ordering. If in the future this stops being true, they won't be able to make the code manually force the order of keys, since they have no spec which defines the desired order. Also, they admit that any numeric keys will break even this thin protection, and their system allows numeric keys since the inner payload is totally free-form.

Seeing as how JOSE has been working on this exact problem and establishing standards, why did I hear about it in an IPFS discussion (even though IPFS does not intrinsically use json) but it is not mentioned anywhere in EveryBit's whitepaper?

This is obviously a gap in the spec, and in a system where every post links to a previous post to establish history (see above), a critical flaw in the signature validation system early on would not be correctable without invalidating all data in the existing system.

Scale your cloud on top of your users

One broad goal of EveryBit is for an app to create a private cloud of its users. These users would store their data on their own computer. This has benefit of the app company not having to pay for that storage, and the effect (good for users, potentially bad for companies) of keeping the data with the user and avoiding lock-in.

The actual implementation of EveryBit is in javascript running in a browser, so I'm unsure if it is suited for a long-term data store in this manner. I also don't know if this feature has been implemented in the codebase. Neither of these issues mean the goal is any less valid, however, and I'd be interested in seeing this feature implemented in a production system.

Proof of presence instead of proof of work

One rather interesting idea that EveryBit puts forward is use a proof of presence system for distributed consensus and membership. Bitcoin uses a proof of work system for roughly the same purpose, and it results in a huge amount of wasted computer effort (resulting in lots of power burned up in cpus for no benefit). This system hasn't been implemented in EveryBit and seems to just be presented in the whitepaper as an interesting (but incomplete) idea. I'll probably explore it in a later post, as the idea seems so close to presenting a solution that I've been nerd sniped.

Incomplete plan

Overall, EveryBit seems to have some interesting ideas but most of them are either not implemented, or have some critical flaws. Many of the ideas (user-management, message history) are valid goals in their own right, but could be layered on top of IPFS to achieve the same goal without having to redevelop a competing distributed content distribution system. While EveryBit may make for an interesting whitepaper and the ideas that have been implemented are useful for the commercial side of the organization, as a lofty goal of making the internet more robust (the "join or die" moment they talk about) I think it belongs as a series of additional functions on IPFS rather than a stand-alone framework.