How Qbix Platform can change the world.

On the 30th anniversary of the launch of the Web, we remember how it disrupted the centralized social networks of the day: America Online, MSN and Compuserve. However, Web 2.0 has made social media dominate our daily lives, and our data, identity and relationships are now stored “the cloud” hosted by one or another huge corporation. With great power comes great responsibility, and it’s time for Web 2.0 to be decentralized.

More and more, the world is beginning to feel the need for an Open Source platform to help put power back into the hands of the people.

  • Trust. Just in the last year there were several scandals around privacy settings. Cambridge Analytica being the major one.
  • Reliability. Google Plus is simply shutting down, for instance, just like Google Reader taking everything with them. And no matter how large you get, you can always be deplatformed or your API keys revoked.
  • Gatekeepers. Could Google, Amazon and Facebook have emerged on top of AOL/MSN/Compuserve? They were built on top of the Web, originally accessible through Web Browsers, because the Web was permissionless and completely took over.
  • Rentseeking. Brands are not always happy to have to pay the platforms.
  • Encryption #1. The other day Zuckerberg said he wants to build privacy and encryption into Facebook, but people don’t buy it.. When the large companies say WhatsApp or Telegram is secure on the back end, we just have to trust them. The only way to be sure is to install open source products on our own servers and devices, with client software that uses end-to-end encryption.
  • Encryption #2. Just this week we heard that Russia’s passing laws that can land you in jail for criticizing the government (it was already doing this), and thousands turned out to protest Russia’s bill curtailing internet freedom. Given how many people live in Russia, China, a question arises whether free speech is important at least for small, local networks.
  • Monopolies. Again just this past week, Elizabeth Warren has support on the left and right when it comes to calling for breaking up these monolithic networks which got there via network effects.

Government action is a heavy hammer that can be wielded as a last resort. The industry has been repeatedly disrupted in the past, where open source projects disrupted closed, centralized networks:

  • The Web disrupted America Online, MSN and Compuserve
  • Wikipedia disrupted Britannica and Encarta
  • Craigslist disrupted classifieds in Newspapers
  • Blogs powered by WordPress comprise 30% of websites in the world

There needs to be an open source software platform that any community anywhere in the world can run on local intranets, whether it’s a university in Bulgaria or a village in Africa. Collaborating on a document shouldn’t need the signal to go to google docs servers. Making plans with friends, or booking a reservation locally shouldn’t need Facebook.

This is the future of social networking.

PS: This video is the first in a two-part series that puts our work in a larger societal context. It was taken with our new blackboard setup, but a bit before we improved the lighting. There’s something about appearing in front of a black background (no shadows) and suddenly being able to draw on it, that seemed like a good format for educational videos.

Posted in Uncategorized | Leave a comment

Vision for a new, truly decentralized Web

This post is about truly decentralizing the Web. We will write another post about making the Web more social, especially on mobile devices. To achieve both of these objectives, Qbix is working on a new Social Web Browser.

We are coming up on the 30th anniversary of the invention of the Web. It has been one of the biggest drivers of economic and technological innovation on the Internet. It has lowered the barrier to publishing and accessing information for people around the world. It has enabled commerce and online payments to go mainstream. And it has done all this in a radically open-source way: the HTML source code for every web page can be easily accessed via the browser. As a result, the Web has led to an explosion of wealth and innovation, removing the old gatekeepers.

However, the Web’s client-server design has also led to new gatekeepers and centralization. People have come to rely on giant, monolithic websites to connect them, and trust them with their data, identity and brand. Sometimes that results in epic security breaches by hackers, bulk collection of data by spy agencies, betrayals of trust, revocation of access, With Google, Facebook, Apple, Microsoft and Amazon, the Web has become, in many ways a Feudal society. With a few Root Certificate Authorities, we also centralize our trust in a few companies. Finally, the Domain Name System uses a centralized, although federated, database, so domains have to be bought through a registrar, and maintained.

But what if we challenge some of these assumptions? For example, what if a regular user didn’t need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain? What if identities and domains were as cheap to create and maintain as files?

Until around 2010, it was even harder. To have a website, most users would have to have their own server in a data center, or rely some limited shared hosting service. Most people opted to use let companies like Facebook host their whole identity online instead. Amazon figured out that letting people share managed virtual machine instances was good savings. Today, that’s called “the cloud”, but it’s still under the control of some landlord – Amazon, Google, DigitalOcean, etc.

It’s 2018, and still the easiest thing we have today is using some web based control panel running on some shared host that charges $5/month or something.

Here is what we should have instead:

  1. End to end encryption
  2. One giant, actually decentralized cloud composed of all nodes running the software
  3. Storing chunks of encrypted data using Kademlia Distributed Hash Table, a technology that’s available since 2002 and used in BitTorrent and MaidSAFE
  4. All underlying URLs would be non-human-readable and clients would display (possibly outdated) metadata like an icon and title (this metadata may change on the Web anyway). Storing and sharing could occur using QR codes, NFC bluetooth, Javascript variables, or anything else. For static files, the links could be content-addressable.
  5. All apps and data would be stored encrypted in the cloud and only decrypted at the edges. They would run on the clients only. Apps could also be distributed outside the cloud, but usually just via a link to a cloud URL.
  6. Communities would likewise be just regular users, rather than private enterprises running on privileged servers running some software like github is now. No more server side SaaS selling your data or epic hacks and breaches.
  7. Users would have private/public key pairs to auth with each community or friend. They would verify those relationships on side channels for extra security if needed (eg meet in person or deliver a code over SMS or phone). Identity and friend discovery across domains would be totally up to the user.
  8. Private keys would never leave devices and encryption keys would be rotated if a device is reported stolen by M of N of other devices.
  9. Push notifications would be done by shifting nodes at the edges, rather than by a centralized service like Apple or Google. In exchange for convenience, they can expose a user to surveillance and timing attacks.
  10. Validation of transactions can be done by random participants in the network, such as the 40,000 people around the world running our Calendar App, but unlike Proof of Work Mining in a way that puts next to no strain on their computers.

No more waiting endlessly to be “online” in order to work in a SaaS document. The default for most apps is to work offline and sync with others later.

Instead of central authorities, everything is peer to peer, with a data stored encrypted in a truly decentralized cloud. The only “downside” is the inability to type in a URL. Instead, you can use one or more indexes (read: search engines) some of which will let you type existing URLs, or something far more user friendly than that, to get to resources.

Domains and encryption key generation would be so cheap that anyone can have a domain for a community of any kind, or even just for collaborating on a document. There won’t any longer be a need for coupling domains to specific hardware somewhere, and third party private ownership/stewardship of user-submitted content would be far less of a foregone conclusion, fixing the power imbalance we have with the feudal lords on the Internet today.

Once built, this can easily support any applications from cryptocurrency to any group activities, media, resources etc.

If you are intrigued by this architecture, and want to learn more or possibly get involved, email us.

Posted in Uncategorized | Leave a comment

Qbix Platform Roadmap

Qbix Platform was originally borne out of a vision to decentralize social networking. The recent release of version 1.0 lays the groundwork for the coming revolution. It is the “WordPress” of social networks. Here is what it achieves already:

  • Communities can run their own social network and release their own apps in app stores, which can gain access to contacts, notifications, etc. on user devices.
  • People can manage their accounts across communities, and selectively share their identities with people in their private address book, without revealing them to others.
  • Our apps in the store help people communicate, discover new communities, apps, venues and interests that their friends have shared.
  • They also let websites give an instantly social experience to members and visitors, by anonymously showing what people they know have already posted
  • Communities can host group activities for their members and guests to engage in, like planning events, driving each other, making group reservations, dating, pitching in for gifts, and much more.
  • Developers and startups around the world can build apps and sell them to communities, without a central gatekeeper.

Groups App

The Groups app has been downloaded by over 5 million people in over 110 countries, and enjoys a 4.5 / 5 star average over thousands of reviews. It currently helps people message each other, but we are working to soon turn it into something much bigger.

The Groups App will be able to host a Browser, like Chrome for iOS and Android, but with new, social features.

  • It will allow the user to maintain secure accounts with websites and services, without needing passwords.
  • By integrating with a user’s address book, it will let people discover websites, communities, interests and venues that their friends have shared with them, and the content they contributed to there.
  • It will let websites present an anonymous, yet instantly personalized social experience upon entering, showing what friends from their address book have been up to.
  • It will allow people message each other securely and privately, and collaborate on group activities across different websites.
  • Websites will be able to have their visitors share their activities with friends, and invite them to the website to join the activities, driving more people to the community.
  • Developers will be able to build new kinds of apps and activity types (e.g. a chess game, chat, trip planning, music mix, etc.) and websites would host the data on the back end.

Groups Browser will make the web more social and secure by default. It empowers private user control of their own identity and connections –– their own address book –– rather than relying on third party servers like Facebook’s to store and own their friend list. It emphasizes group collaboration towards a goal (making a reservation, planning a trip, contributing to a gift or music mix, researching a subject) over endless sharing and commenting on online content.

Qbix Platform 2.0

Note that the Platform 1.0 allows community servers to know and control everything on their own network, similarly to how Facebook is able to do it now. This is what many community organizations want: they can set roles and permissions, moderate content, and so on. In short, whoever has access to the database can have a lot of control and access to what goes on in the community.

The next version of of the Qbix Platform will start giving even more people to the people. People will have the option to encrypt their communications end-to-end, so that no one without the correct cryptographic keys – including the servers hosting the data – will be able to know what is being said. It will implement (n+1)sec for off-the-record multiparty encryption (think WhatsApp, Telegram or Signal apps, but for group activities of various kinds). It will implement encrypted push notifications, so that no one will see the contents except the user themselves, and the apps they installed and authorized on their device.

However, just like with other social apps today, it will not be totally anonymous. Each community will still have user ids for users, and will know who is publishing what on their own domain. They may not know the content, but they will know how many resources each user consumes, whether they’ve recently been posting, and so on.

Projects like the SAFE network aim to have one, global, completely anonymous, autonomous network where no one is able to track or stop anything from happening. To make something like that work, there needs to be a currency to pay for resources, which can be anonymously transferred between people. Qbix plans to eventually support the SAFE network as one huge “domain” though the Groups browser, and let people access “safenet websites” but its main focus will be to unite communities and let them moderate themselves. Things like the SESTA bill require communities to be close-knit enough to able to police themselves and allow people to interact in a social manner.

Thus, Qbix Platform is focused on building software at the community level (including buildings, villages and even mesh networks) and for its apps to enable actual social interaction.


A similar kind of thinking underlies a new project that intersects with Qbix greatly: Intercoin. Where Qbix is focused on helping communities host and manage social apps for their members, Intercoin is focused on helping communities issue and manage their own currency for their members. The project is working to produce tools of democratic governance (such as provably random polling), monetary policy (such as loans or universal basic income), and promote understanding (local consumer price index and reports on how the money moves around the community). Unlike most crypto-currencies, which run on monolithic global networks, and focus almost entirely on the peer-to-peer sending dynamics, Intercoin recognizes that money is a social phenomenon, and focuses all its energy on making it easier for communities to handle the technology, onboarding, regulations and tax implications of issuing their own currency. It aims to allow things like “airdropping” money directly to people affected by a disaster, or students in a university, or people in a poor village.

With Qbix Platform, people in a village will be able to make dinner plans with one another without needing access to the global internet. With Intercoin, they’ll be able to pay each other without needing a federal currency.

Payment platforms are best launched as a layer on top of existing social networks. WeChat, for example, was a social app which added payments, and subsequently replaced much of cash in China. Payments were recently added in Facebook Messenger, GMail, iMessage, and more. Kik and Telegram just had giant ICOs.

In the same way, Qbix Inc. will work together with Intercoin Inc. to help pave the way for communities to become more resilient and take care of their own members, and achieve our vision of Empowering People, Uniting Communities.

Posted in Uncategorized | Leave a comment

Onward to Qbix Platform 2.0: Serverless

We just launched the open source Qbix Platform 1.0. And we worked hard to make it among the most secure open source web platforms out there. However, we are not about to rest on our laurels. We’ve already begun developing Qbix Platform 2.0!

While we were building Qbix Platform 1.0 as a Web based platform, we saw the revolution taking place in crypto-currencies and distributed systems, and we’ve had extensive conversations with teams and architects from the solid project, SAFE network, Ripple, researchers at MIT and NYU and more. We’ve also noticed that web crypto is now available in all major browsers, including mobile ones.

This presents an opportunity to reinvent everything, again. But in a backwards-compatible way. All sites and apps built with Qbix Platform 1.0 will work on 2.0, but will be far more secure and resilient. Yes, more secure than Equifax, or even Yahoo. All open source, available for everyone to use, out of the box. The trick? Going “serverless”.

What is needed

Until now, the Web had one major weakness: you had to trust the server. Trust it to store your data and not modify it without your permission. Trust it to respect privacy settings on your photos and content. Trust it to serve you the right data and executable scripts every time. And as we can see from the epic breaches at Yahoo, Equifax, etc. or Facebook’s privacy scandals, the trust doesn’t always pay off. While a few issues have been addressed, trusting a bunch of random servers on the internet with your data, identity and brand is dangerous, even if they are “in the cloud”. The more web services you use, the more it becomes an issue. This is even truer if you are a developer.

So we are in the process of architecting an entire end-to-end solution for Qbix Platform 2.0 which will give greater confidence to people that their information is secure and they are in full control. It will also form the basis for the Intercoin Distributed Ledger Technology.

How Qbix Platform 2.0 will work

The next version of Qbix Platform is architected around several core principles:

  1. Client-Side Crypto: All decryption happens on the client side. Private session keys should never leave the device, and any keys that are stored on servers are themselves encrypted.
  2. Chunking: Break up large files or revision histories into smaller chunks connected by a Merkle Tree. This way, encryption and decryption can be vastly sped up via parallelization, and encryption may even be strengthened using some techniques.
  3. Distributed Systems: Take advantage of the latest innovations in byzantine consensus to make the system less about the servers and more about the data.
  4. Seamless Social: People should be able to main accounts across communities, discover their friends and interact with their posts, in one seamless and secure experience.
  5. Backward Compatibility: Make sure that all the apps and plugins developed and hosted by communities can be seamlessly transitioned to the new architecture.

Here are the actual details on how it will work. First, a few concepts:

  • Domain: A domain is a set of servers that is accessible on the Internet (or a local network). Unlike the Web, domains can use DNS but can also use other routing systems.
  • Access: Session tokens and other resource tokens are given out by a domain and signed by its secret key. This allows domains to reject requests with improperly signed access tokens quickly, and without doing any hard-disk access or lookups.
  • Identity: This is defined as a set of (domain, userKey) pairs. Someone’s FULL identity is the union of all the pairs under their control. Each domain may know only a subset of your full identity. Domains can host one or more users, who can be person or an entire community or app.
  • External Users:Each domain can also have external user ids to refer to other users who make guest accounts. For example, unlike oAuth, an App which wants access to your personal information would need to make a guest account on the domain where you store that information. In accordance with the Client-Side Crypto principle, you’d see a dialog similar to oAuth which says “such-and-such app (user) wants XYZ access to your streams ABC”.
  • Streams: Streams are essentially blockchains published by users. They contain data and have rules for accessing and modifying it. They can be used for chats, chess games, collaborative editing, blogs, anything really.
  • Pull vs Push: From time to time, someone may want to load an entire stream or resource. But often, they just want to be notified of updates and changes. The latter is referred to as “push”, and is implemented using webhooks, while routing can use DNS or even be peer-to-peer.
  • Rules: Rules are functions written in deterministic javascript and executed in a VM. That includes reading, writing, inviting people, rules of the game, or whatever else. Each change done by a user must be validated against the rules that are in effect at the time.
  • Validators refers to servers which validate the entire history of a stream, and sign claims that they found a violation, or that everything is fine.
  • Governance: Rules provide an expressive and powerful way to implement governance, whether of a simple document or an entire organization. Everyone who can see the stream can see and execute the rules, and everyone who can see its history can see when rules were added and removed; each operation subject, of course, to the previous rules. They can then verify that no violations of the rules were committed in the entire history of the stream, which is very useful for crypto-currencies.
  • Replication: A stream can be replicated on other servers and domains. It can be done either via pull or incrementally push. This should be done in a way that’s similar to (and compatible with) the Scuttlebutt protocol. Such replication can happen peer-to-peer and resist censorship, even on the level of an entire network.
  • Uniqueness:
  • A replicated stream may not be replicated exactly the same way across all computers, because its publishers may generate multiple valid histories and send different versions to different servers. The servers would have to all gossip with one another to discover the “forks” and enforce uniqueness.

  • Watchers:
  • A watcher is a server participating in gossip with other watchers to make sure that a stream only has one “head”. This forms the basis for Intercoin’s crypto-currency implementation, as watchers from various communities can keep an eye on various servers (or groups of servers running consensus) storing and reporting a particular transaction. For each transaction, the group of watchers can be found on a Kademlia tree by information derived from the transaction’s contents. This includes nonces supplied by the various parties to the transaction – so the set of watchers is essentially unpredictable in advance (making it harder to induce them to collude). Each watcher for a transaction needs to know all the other watchers and exactly how large of the quorum will be, because after a certain point, forks can no longer invalidate a transaction.

Now, the crypto architecture for identity:

  • Keys: Cryptographic keys are used for encrypting, decrypting and signing information. They are either symmetric (all parties using the key know it) or asymmetric (public-private key pair). The latter is susceptible to Quantum computers but NIST is currently in the process of standardizing several Quantum-resistant implementations.
  • Session Keys: A device may host several users, each of which has their own session keys for each domain. Session keys are always stored encrypted on the device. Cryptographic keys are derived from passcodes and used to decrypt the session keys. The decrypted version may be stored and used while the user is actively using the device, and deleted after activity ceases for some timeout period.
  • Passcodes: Users never store any passwords on the server. Instead, they use passcodes to decrypt local “Session Keys” stored on their device. The passcodes don’t have to be especially strong (e.g. they can be 4 digits) because the physical device is needed, and device can apply rate-limiting after a few failed attempts. Neither they nor their derived keys should be stored by the device.
  • Biometrics: Today, solutions like TouchID and FaceID allow unlocking passcodes with biometrics, making access even easier. With something like VoiceID or GaitID, people would be able to seamlessly approach a door or screen and interact with it. The more biometrics together, the better; but this is up to the makers of operating systems.
  • Native Sync: Users may choose to sync their session keys using the operating system’s keychain services, such as those provided by iCloud (Apple). That way, the operating system would restore all their accounts on a new device. However, while convenient, it is far more secure to choose not to do this.
  • Keychain: A user’s keychain is a list consisting of all the session keys on all their devices, as well as “helper keys” to revoke or restore a device. All the domains the user has an account with will store this list, and subscribe to Push notifications about its changes. It is essentially a Replicated Stream, but it doesn’t need Uniqueness because when it comes to identity, “double-spending” is not a threat that needs to be eliminated.
  • Revocations: When a device is compromised and needs to be revoked, this happens via a push update to all the domains. The update is signed by M of N keys in the keychain. Similarly, the keychain stream can add new devices. If you lose all your devices, you can still restore your identity – some keys could be “helper keys” held by friends helping you restore an identity after losing your phone. Together with a key derived from a passphrase you remember (or store with biometrics) you can bootstrap you control of your keychain and update your identity on all domains.

And finally, the crypto architecture for interacting with the servers:

  • User Key: Each user on domain has a User Key, which (as usual) is only used for decrypting things on a client. Multiple copies of this key are stored, each encrypted by a different Session Key, in a User KeyFile. A client device obtains the User Key by sending a signed Request with the Session Key’s Public Key, leading the domain’s servers locate the User Key encrypted with the corresponding Private Key and send it to the client. Every time a user’s Keychain changes, its devices get the list of domains and reports to each domain the new User KeyFile for that domain.
  • Database: Information at rest is stored on the server in files and databases. The path of a file, or primary key of a row, may consist of encrypted information. But sometimes, the information is structured (i.e.
    items are related to each other by their content), in which case the file path or primary key may not be encrypted.
    However, the contents should still be encrypted.
  • Access Keys: Information transmitted to the server is already encrypted on the client with Access Keys. In according to the “Chunking” principle, it is often split into smaller chunks and each chunk is encrypted/decrypted in parallel. Access Keys represent access of one or more domain users to a resource on the domain’s servers. Sometimes, multiple Access keys are used in a particular order to encrypt (chunks of) a resource, and in the reverse order to decrypt it.
  • Obtaining Access Keys: Clients can obtain Access Keys with User Keys similar to how they obtain User Keys with Session Keys. An Access KeyFile is stored for each user, with all the Access Keys for various resources (or groups of resources) on the server that the user can load to their client. These can include files, streams, and so on. Whenever a User Key changes for a user on a particular domain, a new Access KeyFile must be generated by the client and sent to all the domains. In particular, this means that updates Keychain may result in lots of updates to various domains the user is a part of. These happen infrequently, but the devices must therefore store the previous keys in order to obtain the current KeyFiles from the servers, and re-encrypt them.

Although we have just begun to follow our roadmap towards realizing this vision, we have already spent many months on finalizing the architecture. The resulting software will be open source, which anyone can build on top of. But even so, we plan to develop a comprehensive set of specs and standards to let other web-based platforms upgrade their software to realize this vision in a compatible way.

Posted in Uncategorized | Leave a comment

Qbix Platform 1.0 has launched.

Releasing version 1.0 of the Qbix Platform has been a major milestone that took us over 7 years to accomplish. Over those years, we built, refined and integrated our experience building social apps into a re-usable platform that lets any community to essentially deploy its own Facebook. This is an idea whose time has come: an open source alternative to centralized platforms, which lets us control our own data, identity and brand.

Now any organization or community can launch their own social network without relying on Facebook, Twitter, etc. App developers can build apps for communities to install, and plugins for each other’s apps, as easily as they build WordPress plugins. People can meet each other over common interests, plan activities, make payments, get notifications, make group reservations at events and venues, or even drive each other to them. This video explains everything:

Strong Security

Qbix Platform promises to decentralize social networking, and with it, empower people and unite communities. If you’re thinking of building an app or website that manages your users’ data, it is probably more secure than whatever solution you had in mind. It protects against a wide range of common attacks, from SQL injection to session fixation to CSRF. It has just passed a code audit by a third party security firm with flying colors. You can read about our latest security practices here.

Posted in Uncategorized | Leave a comment

Modern Security Practices for Web Developers

When you’re building a web application, your servers become responsible for managing other people’s data. Thus it falls on you, the app developer, to implement security measures to prevent data breaches. This is especially true if your application gets popular. The more people, the more valuable the data, the more costly the data breaches can be.

Just recently, we had the Equifax breach on 143 million americans, the Alteryx breach of Experian data on 235 million consumers, the Yahoo breach compromising 3 billion accounts, and so on. It seems this has become a routine occurrence. That’s what’s motivated this article.

Web Security in 2018

In 2018, there are plenty of good guides and resources on web security. This guide is different. It describes new techniques that have become possible on the Web, which eliminate large swaths of attacks. It lists principles that you can apply in your own apps to make them progressively more secure.

As developers of a large, open-source platform for running social networks and payment systems, we have had to confront security issues head-on. We know that popular open-source projects can be especially vulnerable since anyone can see and analyze the back-end code. This motivated us even more to follow Kerchkoff’s principle, that the security of a system should rest on its design, and not its obscurity. So let’s dive in.

The Principles

  1. Do not store sensitive data unencrypted at rest
  2. Do not store keys to encrypted data in the same place
  3. Require cryptographic signatures for assertions
  4. More proof is better than less proof
  5. Use blockchains for data consistency

Do not store sensitive data unencrypted at rest

The easiest way to prevent sensitive data from being stolen from the server is not storing it there. Often, it can be stored on the user’s client. At the very least, this limits the data breaches to only the compromised clients. These days, the makers of operating systems (especially mobile operating systems) have caused user data to be encrypted by default, and the user unlocks their phone or laptop using a biometric id or passcode. Thus, to get the data, the attacker would have to access the user’s unlocked device.

Of course, sometimes you need this data on the server side. People may want to access and use their own information when logged in. External APIs may want to use an oauth token or even a username and password. If you’re going to store sensitive data – whether on the client or the server – consider encrypting it.

It used to be that data stored on the client could not be reliably encrypted. But in the last few years, the Web Crypto API has been finalized and is now supported by all major browsers including iOS Safari and Android Chrome. It gives you access to all the cryptographic tools you need to secure your data on the client, including random number generation, deriving and handling private keys, and the browser can now make sure the keys aren’t exported out of the client side website context.

Do not store keys to encrypted data in the same place

For really sensitive data on the server, encrypt it when storing it in the database. Many database vendors actually have transparent solutions for this. To decrypt the data, you will need:

  1. The app’s private key
  2. The private key of the user who encrypted the data

(See the “more proof is better than less” principle, below.)

None of these keys should be stored in the same place as the database, so the hacker would have to compromise more places in order to get the decrypted data. You can even split the keys up and store parts in different places. In any case, once you obtain the keys, do not save them or export them anywhere, but store them only in transient operating memory.

The private key of the user who encrypted the data can itself be encrypted and unlocked by using a valid user client device. For each device, another copy of the key would have be stored, encrypted with that device’s private key. Each device is identified to the domain by its corresponding public key.

It’s a little-known fact that most modern browsers allow you to save Web Crypto keys on the client using the new IndexedDB API. However, once again, you don’t want to store these keys without encrypting them first. Otherwise, anyone with access to the browser’s database will be able to see the keys and steal them, allowing them to take actions on the user’s behalf.

The typical approach is to have a master key which is used to encrypt various things on behalf of the owner. This master key is then stored encrypted by one or more access keys, which are derived from a user’s passcode or biometrics (such as like their fingerprint or Face ID). A user can have one access key for each of their fingers, for instance. This way, if the user adds another password or finger, they don’t have to re-encrypt all the things with it as well.

The access keys should not be stored on the device! They are derived every time from the user’s password or biometrics, and used to decrypt the master key every time it’s needed. The Web Crypto API can prevent the export of these keys using Javascript, and if your code is running inside a trusted browser or mobile authentication session then other apps can’t get at it.

If other Javascript is running in the website, it might misuse the keys, so it’s nice to only expose a few functions like MyApp.sign(data) . Load the script defining these functions via the first script tag in the HTML document and use the new Object.freeze() method (from ECMAScript 5 which is supported in all modern browsers) to prevent other Javascript code from replacing the functions.

Ideally, the user’s passcode and biometrics should be entered in a trusted sandbox mode that other code running on the computer (such as other Javascript, or screencasting software) can’t access. Sadly, there is still no standard way to isolate such a sandbox on the Web. Fingerprints aren’t going to be intercepted by keyloggers and screencasting, but passwords can be. In the future, such a mode may be developed by Operating System vendors, and users would recognize it because it would display some photo or phrase that only the user would know (because they entered it when setting up their device). This is the weakest link with the Web (and most operating systems) in 2018: anyone can spoof a password prompt on iOS, MacOS, Windows, and the Web. Biometrics are better. For now, you can just simulate it with an iframe running on a domain of the user’s choice, which the user trusts. When the user puts their keyboard focus in the password area, they would see their secret phrase in the iframe. (There used to be a standard called xAuth that would have allowed the enclosing site to find out this domain, but it has fallen by the wayside.)

Long story short, it looks like this:

  1. user inputs passcode or biometrics (in a trusted sandbox)
  2. derive access keys from that (in the same trusted sandbox)
  3. use them to decrypt master key for that domain stored by the user agent on the user’s device
  4. use master key to decrypt information sent to the user, and sign information sent by the user

Require cryptographic signatures for assertions

This is all well and good, but what if the server doesn’t send the right Javascript? On the Web, we constantly have to trust the server to send the resources. Content Delivery Networks that serve the same files for thousands and millions of sites are juicy targets for hackers to modify files across many sites if they can.

It would be nice if there was a cryptographic HMAC of the file we could obtain in a side-channel, like from someone (like ourselves) who downloaded the resource from that URL and reviewed it. Luckily, the Web now allows any site to easily add Subresource Integrity checks to do just that.

However, the top-level resource that you request via a URL can still be changed, even if you load it via https. Perhaps the server was compromised and hacked. Perhaps a certificate authority was compromised and now someone used DNS rebinding to serve you a fake site. Having browsers be able to verify top-level resources against an HMAC would be really useful, but the current breed of browsers doesn’t support it. This is the second weakest link on the Web. Perhaps one day it will be fixed with IPFS and content-addressable URLs. For now, at Qbix we plan to release a browser extension that parses the top-level location URL for some appended hash via special characters (##hmac=...) and, if present, verifies it or rejects loading the document.

Responding to a request with a file is an example of an assertion: “this is the resource at this URL.” The HMAC acts as a cryptographic signature of this assertion. But there are many other assertions you can sign, and the general principle is to require signatures of an assertion.

If the entity checking the signatures of the assertion is the same entity issuing the assertion, then it can just keep a private key around. For example, it’s useful to sign session ids that your servers generates (use an HMAC, and include that signature as part of the session id). This way, your network can right away reject bogus session ids (such as “blabla”) without hitting the database or doing any I/O at all. Even the computers acting as gateways into your network can keep the private key and reject all requests that don’t contain a properly signed session key.

This enables another aspect of security: uptime. Your network can handle many more requests if unauthorized requests are stopped early on without putting a strain on expensive resources. Users without a session may be able to request static assets from a CDN, but your app servers won’t be weighed down. And within authorized sessions, you can implement quotas for using resources, throttling users and preventing them from abusing the network, or even charging them for their usage. All of this is possible simply from requiring signatures for assertions.

If the entity checking the assertion is a not necessarily going to be the same one that issued the assertion, then you can use public key cryptography: the assertions should be signed by the entity’s private key, and anyone with the public key can verify it. For more efficiency, or for off-the-record messaging, you may want to use a hybrid cryptosystemwhere you bootstrap with private keys but generate symmetric keys that can be shared per-session or per-message.

More proof is better than less proof

It’s a simple principle: you don’t become less secure by requiring more proof (of identity, permissions, etc.) before granting a request.

Since the early days of the web, cookies were used to transmit session ids. Until the advent of localStorage, that’s as far as people could really go. If you sent a request with the correct session id, your request was executed in the context of the user who authenticated with that session. Thus, lots of attacks were developed, including session fixation attacks where the attacker would gain access to the user’s session, and be able to impersonate them. The cookie became sort of a “bearer token” – anyone who had it could access the protected resources, even if they had stolen the bearer token. In the last few years, companies started a big push to get all the website traffic encrypted over https. This is a laudable goal for many reasons, but trying to do it to secure cookies is not enough.

With localStorage, and now with Web Crypto, you can do better. The server can require additional information to be sent along with each request. We’ve been talking about signing requests with private keys, so now it’s time to put it to use. Each device would have a master key per domain, per user. Each request would be signed (asymmetric cryptography using data = MyApp.sign(data)) with this master private key before being sent to the server. The session ids would still identify the session on the server, but now, the master public key would be sent along in the request to verify that a known and authorized device was, in fact, used to generate a request.

When new devices need to be provisioned to execute (some or all types of) requests on behalf of a user, the general approach is to use existing devices to sign the provision authorization. Policies could be developed (and checked on the server) for how many devices are needed to provision a new one (typically, one device is enough). This signed authorization can be easily communicated via QR codes (camera), bluetooth, sound recording, email or any other side channels. Ideally, the communication should be secured as well, by encrypting it with the new device’s public key, so only the new device can use them.

Finally, going with the principle of “more proof is better than less”, users should also be able to turn on two-factor authentication. Not only can this alert them when there’s a new login is being attempted, but it requires an attacker to use more than one factor. Factors come in three types:

A) something you have (e.g. your phone)
B) something you know (e.g. password)
C) something you are (e.g. biometrics)

Typically, A is combined with either B or C, and usually this is enough. Provided you lock your phone when you walk away from it, the OS encrypts all your data and requires a passcode (with rate-limiting) to access it, A can be enough. You may relax the extra requirements for personal devices.

But for environments like logging in on a website on a public computer, you might want to require A and C on the phone, or A with B on the computer. There would have to be some way to get information from the phone to the computer without an internet signal, and that’s usually done by typing in 6 numbers from an app like Google Authenticator or Authy.

Notice, by the way, that if you use A and C, then passwords are not needed at all. People usually re-use them, and choose really easy ones. So if you’re going to go that route, at least encourage people to use passphases, by requiring several dictionary words with spaces between them.

Use blockchains for data consistency

When a new device is authorized to be used by a user, and a session is authenticated, it becomes a liability. Anyone who steals the device and unlocks it can make requests as the logged-in user through their authenticated session. So when people lose their devices, you need to be able to repudiate the device key. In general, when a computer becomes compromised, you would like to repudiate that computer.

In order to do this, you would have to log into the server with another device and repudiate it. However, if all it took was one device to repudiate the others, the attacker would be able to quickly go and repudiate all your other devices, locking you out of your own account. It would be your word against theirs. You could send over a copy of some ID card, they could conceivably forge one, etc.

Instead, it’s better to have some additional public/private key pairs for just this purpose, pairs you either keep on other computers, print and hide around town, or give to friends. If you’ve lost ALL your devices, you can still restore your account with M of N of these private keys, plus an additional required key K (so that M of your friends can’t take over your account). The key K could be derived from a passphrase which only you know. If you really want to get fancy, you can allow one of several keys, including keys derived from your biometrics or devices hidden in your butt (you know, for guys like Jason Bourne).

In all this, however, you are still trusting the server. Many people, for example, trust third party websites like Facebook to help them authenticate with other sites. The problem is that Facebook then “controls” your identity on those sites, and can cut off you ability to even get back into them. (The author of this article had such an experience with SoundCloud, because since then, Facebook changed the user ids it reported to SoundCloud.)

We are gradually moving to a web where people own their own identity and information. Qbix is actively participating in this movement by publishing open protocols for authentication, which we implement in our own platform. In such a system, people shouldn’t need to rely on a third party website like Facebook to authenticate with other sites. They should be able to prove they control an account on Facebook, or any other site, by using public key cryptography.

If I can get site A to display something at a URL containing a user id, where only that user could be authorized to post, then I can post some text that includes public keys and is signed by corresponding private keys. This text could also name my favorite apps or domains I prefer to use to authenticate with (the new xAuth). When I visit site B, and want to prove that I am also some user on site A (i.e. I control that account), all I have to do is claim this, and the site would seamlessly open my favorite authentication app / domain, which has my private key, and let it answer a cryptographic challenge, like signing a random piece of text. That proves that the same person who is currently signing into site B also controls the claimed account on site A. Site B can then keep this information. In the Qbix auth protocol, we describe extensions to this scheme where user ids can be pairwise anonymous, so you share your identities with some people and not others.

When you want information, such as your authorized devices, to be propagated in a way that no one site controls, you need a blockchain. Blockchains are a drop-in replacement for security that “solves” the problem of having to trust one server and its database, which could get hacked or compromised. It requires many independent servers to validate each transaction. While it’s possible to compromise all these devices, it’s exponentially harder.

Blockchains help solve many problems where multiple validate validate rules of an evolving stream, and prevent forks. Whether you are repudiating a device, or transferring ownership of a token, the validators need to make sure that all the rules are followed, and that the stream hasn’t forked off into valid but conflicting streams.

Merkle Trees (and the more general Merkle DAGs) have a great property that, if you hold the root hash, you can be sure of the integrity of the entire tree. Given any node in the DAG, you can verify that it belongs in the DAG by simply checking its Merkle Branch, which is O(log n) operations. “Belongs in the DAG” means that some process was followed to generate the hashes of each parent given its children, all the way up the root. “Integrity” means that this process followed the proper rules, at least in the opinion of the computers that generated that DAG.

Now, with public and private keys, you can have many computers signing off on the next parent of a Merkle DAG. All those signatures and hashes are combined into one hash. This is, essentially, a “block”. The trunk of such a Merkle DAG is a blockchain. You don’t need to know about everything in the tree, just the trunk. Holding a hash from the trunk, you’d have access to a wealth of information signed by participants and validators, and have confidence that all transactions until that point were validated and checked.

In Qbix Platform 2.0, we will focus more on decentralized governance and security, as a drop-in replacement for Qbix Platform features like Streams. In other words, by building on the Qbix Platform today, you just have to focus on representing, say, a chess game and add chess rules. And when 2.0 comes out, you will be able to just have a blockchain verifying that all the rules in the game were done correctly. All the access control and subscription rules that we have now will go from being a domain-specific language to being defined in a scripting language. People will write rules in Javascript, including rules about access, and rules about adding and removing other rules. Validators on the blockchain will sign off and verify the consistency and integrity of the whole data structure, which you will be able to have just by holding one hash: that of the root.


Posted in Uncategorized | 1 Comment

What’s Preventing Crypto for Everyday Payments

Crypto as a medium of exchange

It’s been nearly 10 years since Satoshi Nakamoto launched Bitcoin and 13 years since Ryan Fugger designed the original Ripple network. Crypto-currencies are still nowhere near being a mainstream way to pay for things. Almost no one is using them to make actual everyday purchases, the way they use VISA credit cards, or PayPal, or WeChat in China.

Even though Bitcoin was conceived as a “peer to peer electronic cash system”, it (BTC) became mostly a store of value, a commodity and a means of speculation. RipplePay was originally a peer-to-peer electronic credit system, but eventually Ripple (XRP) became a network for moving money between banks. What happened to the original goal of making a currency that people actually use to transact in everyday life?

Design decisions

Much of what we see is a result of the original architectural design decisions behind the networks and how they work. It’s tough to predict how something will evolve, especially when it’s built on a bold new idea.

Bitcoin’s bold idea was a novel use of Proof of Work to determine global consensus. But, this has led to an arms race of mining power, to the point where the Bitcoin miners now use more electricity than 159 out of 195 countries, all to secure a blockchain that can handle a few transactions per second globally, but may reverse them in the future.

RipplePay’s bold idea was to let people extend interest-free credit to one another via trustlines. Payments between friends require no third party at all, and payments within densely connected communities could be routed through intermediaries. In almost every way, this was the opposite of bitcoin: credit vs value, hyper-local vs globally recoded transactions, etc. But in the end, not enough people were willing to take on the risk of being financial intermediaries, and the project turned into a system of moving money between banks. It also introduced a global value-based token called XRP.

Global consensus

Both BTC and XRP networks today are monolithic global networks, requiring global consensus about every transaction. Ripple in particular is well-suited for settling debts between large institutions, but there is still a missing piece on the level of individuals.

It takes a serious amount of time and money to confirm Bitcoin transactions, making them impractical for everyday transactions. Today, fees range between $20 and $40 to get the confirmation time down to 10 minutes (well, several times that by most vendors who want “multiple confirmations”).

Ripple’s XRP confirmation time is much faster, but it has achieved this by carefully and slowly building out its network of trusted validators. Handling validators that misbehave would still be a time consuming human effort.

However, Ripple’s technology is well suited for settling money between large organizations, without the need for them to trust one another. Intercoin aims to provide the missing piece: letting these organizations enable everyday transactions by users within their community, and between communities.

Adoption by Users

Another issue is that people can’t easily move money in and out of the crypto economy. These days, they have to set up an account with an exchange or portal such as Coinbase, verify their identity, scan their documents, and then wait up to a week as payments to the exchange clear. And this is the “user-friendly” way that replaced the old way of meeting up with someone on the street, for a value exchange that functioned similar to a drug-deal.

In general, it’s hard for people to join a monolithic, global network. For example, to really join the Internet, one would need their own IP address, rent technology, enter into agreements with upstream providers, pay lage sums, comply with regulations, and so on. Most people who “just want to get on the internet” walk into a coffee shop and get on the wifi, or connect their home to an ISP.

Thus, Intercoin is building technology to handle the second half of the equation: giving users the freedom to maintain accounts between communities, control their own data and assets, and move freely between them.

Adoption by Developers

There are tons of apps and websites out there. They adopt payment systems like PayPal or Stripe by integrating simple user interface flows to let people check out or start a subscription. Lots of services provide a simple way to integrate a “Pay” or “Subscribe” button on a website or app. ApplePay and AndroidPay have made it even easier by storing credit card information on the phone, and people can now pay merchants with just a fingerprint to authorize the payment.

In order for crypto payments to become mainstream, apps would have to be able to integrate such buttons, where people would be able to pay with their credit card or bank account or crypto account stored in their phone, or on ApplePay. The whole process would have to be seamless, with the user paying in the currency of their choice, and the merchant being eventually paid out in the currency of their choice.

Reversing Transactions

Another issue is the fundamental difference in how the crypto world treats transactions, as opposed to the existing financial system. With Bitcoin and nearly all other Blockchain-based systems, transactions are final, so let the buyer beware. If the seller absconds with the money and never sends the product, there is no financial intermediary to reverse the transaction. If money is stolen from a wallet, there is no way to reverse it.

But more to the point, this difference presents a major problem for letting people pay with traditional financial instruments such as a credit card or even an ACH transfer, because both are reversible. If you’re running an exchange, or a service like CoinBase, you can get screwed by people who deposit money and then issue a chargeback, as this exchange was.

Wires are about the only mainstream transaction that’s electronic and non-reversible, and they charge significant – but fixed – fees ranging from $20 to $70 per transaction. So, individuals would have to make relatively large wires in order to have low fees in terms of percentage.

Intercoin allows the organizations to do the wires instead of the individuals, and handle chargebacks the same way that PayPal or Visa handles them. Coinbase has a few avenues available to them when dealing with chargebacks, but communities would be able to claw the money back from local merchants accepting their currency, providing a smoother transition to and from the traditional payment system. In a sense, Intercoin is letting each community “run its own open source PayPal”.


Bitcoin’s rise in value makes it a good investment and store of value, but a lousy medium of exchange. And, its price volatility would lead many merchants to cash out to local currency, and pay fees (again). They can, however, exchange for tethers which run on top of Bitcoin, and are basically crypto representations of Dollars, Euros, etc. If more people accepted payments in tethers rather than the actual Dollars, etc. then merchants could keep their money in crypto. But that requires adoption of crypto as a medium of exchange in the first place.

Making it Work

On Intercoin, USD and GBP are represented by crypto equivalents similar to how Tethers do it on the Bitcoin ecosystem, but it’s done much more organically: USD and GBP are just another “local currency” which can be exchanged with Intercoin via market makers.

A community in the USA pre-purchases some Intercoin for a low fee by sending a wire to a Market Maker, which exchanges it for Intercoin. When a person comes and pays them $20, the community’s Payment Network begins keeping $20 Intercoin on reserve as an “asset”. The person receives the corresponding amount of Community Coins as a “liability” or “claim” against that Intercoin asset. They go pay some local merchants.

Eventually, the merchants can cash out to Intercoin and exchange it for e.g. some USD Coins, all without paying any fees (just the bid-ask spread between Intercoin and USD Coins). In fact, even this bid-ask spread can be avoided if merchants keep their money in Intercoin and the ecosystem of Local Currencies backed by it. The exchange there is completely without market makers: the exchange rate at any point is just the number of Local Coins in circulation divided by the amount of Intercoin on reserve.

But even one step beyond that, the more businesses and employees accept USD Coins alongside USD, the more the whole crypto economy can proceed without the fees of cashing and in and out of it. For that, the ecosystem needs more adoption by users of crypto as a medium of exchange. And that’s why we need Intercoin.

From the user’s point of view, it works pretty much like in this video:

Posted in Uncategorized | 4 Comments

Economic Analysis of Intercoin

Recently, Qbix launched a new spinoff project called Intercoin. As time goes on, you’ll probably hear more and more about this new decentralized currency platform and the technology that powers it. So it would be helpful to have an article that explains the economic design decisions we made along the way to arrive at its current form. This is that article.

(If you want to read the corresponding article about the technical design, stay tuned for the next one.)

What is money?

Let’s start at the beginning. Money is supposed to be used as a medium of exchange. To a person, the value of any given currency is directly related to how easily (people, businesses) would accept it in exchange for things the person may need or want. Thus, currencies benefit from a network effect: the more people in a community accept it, the more valuable it is to each member. How well a currency fulfills this function determines its value for the community.

Social apps benefit from network effects too. Facebook is much more valuable if all your friends are on it, so can see and be seen – photos, comments, whatever. It’s no surprise that social apps have all incorporated payments into their networks: you can now pay via GMail, Facebook Messenger, iMessages, and more. WeChat in China has all but replaced cash.

When a new payment network appears, people cash in by “depositing” value and receiving internal currency which they then use to transact on that network. Occasionally, people cash out by “withdrawing” value from the network. This is true of casino chips, paypal, banks, or local currencies such as Berkshares, Bristol Pounds and Ithaca Hours. (And it will soon be true of estcoins and the petro).

One size does not fit all

Most currencies today are run by huge communities, whether they are Bitcoin, or federations such as USA, EU, Russia or China. As such, they are one-size-fits-all.

For example, the mysterious creator(s) of Bitcoin made a decision early on that the supply would never exceed 21 million. As a result, as Bitcoin’s network effect grew, the value of each Bitcoin kept growing, too. It became a good store of value — a vehicle for investors and speculators — but that made it a lousy medium of exchange. Who wants to spend their coins on a pizza when the same coins can buy a house a couple years later?

Moreover, Bitcoin is one monolithic global network with an ever-growing ledger that records every transaction ever made. This makes it hard to scale: every block must contain a consensus about all transactions in the world made during that time. This greatly limits the number of transactions the network can handle: Bitcoin can handle 7 transactions a second across the whole world. Moreover, having one monolithic global network with a global consensus means innovation is very limited: even something as trivial as increasing the block size leads to infighting and forks.

Internet scale

The internet is not a monolithic network. It is a network of networks, each one able to determine its own policies, membership, software stack, and so on. Computers on the local network can run apps and accomplish many things among themselves without even needing to go outside the network. However, once in a while a message must be sent over the internet to another network. This is done using a standard Internet protocol such as SMTP (Email) HTTP (the Web), FTP, and so on.

The main idea of Intercoin is to make a currency platform architected like the Internet. Each community can run its own payment network, allowing it to issue and manage its own currency. Payments made locally (eg paying for a coffee) do not need to be recorded on any global ledger. Once in a while, someone may move money across communities (eg paying a vendor in another country) and this is where Intercoin can help by providing

a) a standard way of atomically cashing out of one community and into another

b) liquidity to actually complete the transaction with the lowest fees


One straightforward way to do this would be to require each community X to have an account on the global Intercoin network and keep Intercoin on reserve to back their internal economy. When someone cashes out some amount of currency X and into currency Y, it can be accomplished easily:

  1. The payment network of community X receives the local currency being cashed out and takes it out of circulation
  2. Community X pays community Y the corresponding amount of Intercoin on the Intercoin network
  3. The payment network of community Y issues the corresponding amount of its local currency to the recipient.

There are two major ways to do step 2:

2A. One way to do step 2 is to have “trustlines” between communities, similar to how banks settle their accounts at the end of the day. This form of money is credit-based: the more communities there are, the more credit can be extended. Thus, the money supply grows over time.

In this approach, every community will have to maintain credit with every other community, or find a path to route payments through intermediate communities.

The volatility of Intercoin on the markets would probably be lower, because communities would individually determine how much credit they can extend each other.

However, fees for Intercoin transactions would be higher as intermediate communities would take on counterparty risk as they route arbitrarily large amounts via ILP. Or, the throughput for Intercoin payments would be lower as communities cautiously move a little value at a time, so as not to get stuck holding the bag for another community.

2B. Another way to do step 2 is to have Intercoin be a value-based currency, like Bitcoin or XRP in the Ripple network. In this case, we can have a limited supply of Intercoin, and it can run an efficient blockchain consensus algorithm, such as XRP consensus.

In this approach, the local community networks would gladly employ their machines in validating the Intercoin blockchain, since it is in each community’s interest to maintain liquidity for Intercoin transactions. Otherwise their members would get upset — especially merchants who need to import materials from outside.

Without counterparties and trustlines, communities could hold full reserves of Intercoin and support arbitrarily large payments across communities without any of the risks associated with routing payments through intermediaries. As a result, the fees can be brought to zero, and Intercoin payments can be made seamlessly across any Community Coins. (Exchanges to external currencies such as Bitcoin or Dollars would still require market makers and fees.)

Steps 1 and 3 can be done very simply without any market makers or fees. The payment networks X and Y know exactly how much of their currency is circulating, and how much Intercoin they have on reserve (or in the first approach, the total Intercoin credit across all their trustlines). Thus they can divide one by the other to get the exact exchange rate that would apply if everyone cashed out at the same time.

With simple math for currency exchange, instead of markets, foreign exchange fees are eliminated and the exchange rate becomes a predictable function of the community’s money supply. This allows the community to reason about the effects of its monetary policies (such as issuing a Basic Income to every resident) and even extrapolate them into the future.

To paraphrase Milton Friedman, this will make exchange rates everywhere and always a monetary phenomenon.

The Intercoin project will produce the software and resources for any community to issue and manage their own currency. However, unlike Bitcoin, Ethereum and other monolithic global networks, each community has the freedom to run any payment network it wants. Intercoin is leading the way with software and apps such as Basic Income, but over time there can be many different systems and platforms, apps and innovations.

Posted in Uncategorized | 1 Comment

Power to the People

Access to the global internet

With the repeal of Net Neutrality, the national conversation has once again turned to whether Internet Service Providers will begin to throttle traffic or provide preferential treatment for certain sites over others. They have already done this before, and they’ve even injected their own Javascript into webpages you visit.

Today’s US internet service landscape is run by a cartel of too-big-to-fail telcos, who don’t compete with one another in the same cities. Over 100 million users have no choice in provider. These companies are happy to sue cities in state courts to prevent competition from municipal broadband. It’s very hard to start a competitor to them today.

The people rise up

Meanwhile, in cities across the world, there are now efforts for people to build their own mesh networks, which provide high speed connections outside of the large telecommunication companies. Among European efforts are Freifunk in Germany and in Spain. Now, growing movements in cities like New York City and Detroit have started building their own mesh networks as well. Connection speeds within the network are far higher than what people get on the global internet through the ISPs.

If you think about it, there is no reason why signals have to travel to a Facebook server 3000 miles away just to plan a local dinner or outing with friends. Students in a class should be able to connect with one another and collaborate on documents without using Google Docs. The same is true of passengers on a plane, or shipmates on a cruise, or villagers in Nigeria. Local networks should suffice.

Software to unite communities

All this growing local infrastructure unlocks the potential for people to connect with one another on a local level without relying on the ISPs. However, until now there has been a lack of good software to run on this infrastructure. The platforms people use today are almost invariably centralized and require access to the global internet. Facebook, Twitter, Amazon, GMail, Apple, Microsoft, Instagram, WhatsApp, SnapChat, Etsy, Netflix, Uber, you name it – they get venture-funded, get a bunch of people on both sides of a market, and extract rents. They have 1 engineer per million users, or less. Customer support is non-existent. They choose what features you have and what interface you see. They have the people’s data in one place, and sometimes that makes an attractive target for governments and advertisers. In a recent article, we covered this situation in more detail.

Since Qbix released our first apps back in 2011, we has been steadily developing our Platform to power community apps. Now it turns out that this Platform is a perfect fit for the mesh networks springing up, allowing people to enjoy use apps running on local servers, and get high-speed connections to one another, without even needing to connect to the global internet. Once in a while, a message needs to be sent globally, but most of the time, what happens in Vegas stays in Vegas.

We recently paid a company called Antamedia to develop OpenWRT firmware that runs on many popular commercial routers. This firmware now allows communities to run our entire social platform and apps off of their local wifi. Imagine coming to class and having attendance taken automatically, because your phone connects to the local wifi hotspot. Imagine having messages stay private in the classroom, or unlocking rewards from actually being physically present at a concert, and so on.

As time goes on, we are continuing to push the boundaries of what’s possible in this space. Our next goal is to release software to turn an Android phone into a hotspot, allowing people to host a local community on demand wirelessly just from their Android phone. Even when they’re out camping. And the social apps built on our platform should work on all these networks, whether it’s a wifi router, an Android phone, a mesh network, or a website on the global internet.

Money to unite communities

In the last few years, all major social networks have added the ability for users to pay one another. It’s not just PayPal and Venmo anymore: you can now send money in GMail, Facebook Messenger, and now even iMessage. In China, WeChat (the chat application) has become a huge payment network within a few short years. People can now pay with WeChat at restaurants and other businesses across the country, and cash is rapidly becoming obsolete.

With the recent proliferation of interest in crypto-currencies and blockchain software, we got to thinking, why not help communities issue and manage their own money supply? This was our vision for social networking, but translated to the realm money. Instead of having large, global one-size-fits-all currencies (US Dollars or Bitcoin) we could once again give communities the power to determine their own fate.

So, starting 2017, we launched a spinoff company called Intercoin Inc. to do just that. Where Qbix focuses on social networking, the Intercoin project focuses on building the infrastructure to run a secure and resilient payment network. Similar to Facebook and GMail, Paypal and Stripe, we would implement buttons that app developers and website publishers could easily add in order to seamless get paid in the local currency. Prices would be displayed in the currency of the user’s choice, and Intercoin would make cashing in and out of currencies seamless.

Just like Qbix Platform enables local apps where most actions work without access to the global internet, the Intercoin project enables innovations in local community fintech. Basic Income becomes achievable by any community. All citizens can see how the money is being used, spot issues and deal with them as a community. Governance can be done in a democratic manner. The money supply can be controlled by the people instead of the elites, leveraging the wisdom of the crowd.

Decentralizing the gatekeepers

There is another huge benefit of letting communities install and run open-source software. Qbix Platform and Intercoin enables a richer developer system (just like the Web has done). Developers of apps and plugins don’t have to worry about some gatekeepers kicking them out of the App Store, or revoking their API keys while they build a competing product. Each developer can market to entire communities, who can then recommend the app to one another. Communities can do the work of promoting the app to their own members, while the apps would make it easier for the communities to engage their members and give them tools to get together and feel connected.

So that’s the vision: empowering people, uniting communities. When communities need more apps, they can band together and organically raise funds to pay developers to build and maintain them. It’s an open ecosystem where collaboration leads to more and more positive feedback loops.

Communities don’t necessarily have to be local. A person can belong to several communities, including their neighborhood, city, and a poets’ guild. They can get $20 a day Basic Income from the city and another $5 from the poets’ guild. This can help decrease poverty, food insecurity, and lead to increased freedom and prosperity.

Posted in Uncategorized | Leave a comment

The Future of Money

Hi, this is Greg, one of the founders of Qbix. I wanted to write a post to you in first person.

Our company has been busy building apps to empower people and unite communities. The original goal was to build a social networking platform to offer an open-source alternative to Facebook and other centralized sites, letting people host their own networks. In this video (sorry about the sound) you can see my overall vision about decentralization, not just of software but of cellphone signals, power generation (solar panels), etc.

I believe that, over the next several decades, automation will lower demand for human labor. The hardest hit will be low-wage workers around the world, but when 1 person can do the job of 10, wages are bound to go down in that sector. I believe this has already been happening since the 70s (Piketty, et al) and wages going to be an increasingly ineffective way to bring enough money to the people, so our communities will need to institute an Unconditional Basic Income. The money for this income will come from the growing amount of profits Corporations will make from automating their operations. I’ve written about it extensively, in the larger context of the corporate world. I’ve written responses to libertarians and altruists. Those who wonder how we can afford UBI can look at single-payer systems in countries around the world, or right here at home. In those systems, people wind up paying less per capita for basic levels of service, because buyers don’t compete, only sellers do. A basic income would reduce inequality, remove the need for minimum wage laws, and provide better opportunities for everyone. Everyone from Milton Friedman to Martin Luther King advocated for it, but so far, it hasn’t been implemented.

What we’ve already done

So far, we have built a bunch of apps that got a lot of traction around the world. Now we are working to let communities host their own social networks, and let people use apps on their devices to authenticate with various communities (protocol), manage their identities across communities, and use social apps hosted by these communities. They can move their money between communities, spend it within a community (the businesses cash out through the community bank or crypto-network, etc.) and apply to receive UBI from various communities.

I’m currently in the process of building a team to execute on this vision. We’re also documenting our roadmap, writing a white paper, and speaking with an investment bank to do an ICO in addition to the equity funding that we’ve been doing up to this point. Among the people who have been advising us are Ryan Fugger (original creator of Ripple), the lead developer of solid, the creator of Ruby on Rails, the founder of PlanCast, and Warren Mosler (because MMT talks about issuing currency).

Basically, we started building social networks to decentralize the power of Facebook, etc. and we are now looking to actually build the first implementation of UBI as an app within a community currency.

Where this is all going

Our company is connecting 5 different facets (see above). We already have the first one – People – in 110 countries around the world. Now we started to build our first apps for communities to give to their members, and I should be able to invite you to some in the next month or two.

The last 12-18 months, I’ve been working to design a crypto-currency that would support UBI. Something like but implemented in practice. Here is the reasoning behind its design, in bullet points:

  • UBI needs to be on the local level, because the cost of living varies from place to place. In a desert environment, water is more expensive than right next to an aquifer, for instance, yet water is a necessary good. UBI doesn’t mean everyone can move to the desert environment.
  • Communities can already issue their own currencies, like the Bristol Pound. This is called “complementary currencies” – fiat of the larger polity is accepted, but inside the community, the currencies circulate. Due to Gresham’s law, people would actually spend them much more readily than fiat. You can also see a transition to internal currencies (backed by fiat reserves) in WeChat/AliPay in China, or how the Millennials venmo each other money.
  • Communities can be more resilient – e.g. Detroit Bucks can pay an employed plumber to do a job. Even if Detroit is hemmorrhaging dollars, most Destroit Bucks will stay in Detroit so it won’t go bankrupt. Same with Greece and the EU, for example. Communities need to be able to have their own fiscal policy.
  • Money is just another “social app”, but for now it’s been a dumb one. The value of a currency comes from network effects, just like an app – stores accepting the currency in exchange for all the stuff you need, is similar to all your friends being on facebook. Payments between communities can be done using the interledger protocol.
  • UBI can be implemented in the community currency without coercive taxation by automatically measuring the local CPI (of food etc) every day, and issuing that amount to everyone in their accounts. UBI comes with “immigration quotas” – the community or its representatives make decisions as to who can move there and start to receive UBI. So the U in UBI does have one condition: “membership” in a community. This is similar to how tribes used to live for centuries, except now they don’t need to work.
  • I believe this will also have a great impact environmentally. By stimulating local economies and issuing UBI to local residents, we counteract the effects of Capitalism that cause people to live further and further away from their jobs in expensive cities like SF, and commute to work and pollute the planet. The phenomenon of commuting to work to sit in a chair is only about 150 years old, and is very wasteful for most jobs.
  • The UBI will invariably cause the community currencies to inflate, and lose value against the fiat etc. But all the prices will be quoted in the fiat, so this shouldn’t lead to confusion. The endless inflation will not cause the same problems as it did in the Weimar Republic, but instead will transparently capture the cost of “how much it costs for everyone to eat”, mitigating shortages and fixing them later. Plus, communities can implement taxation to remove money from circulation if they want to disincentivize certain business activity. Or the Federal government can help subsidize the shortages of fiat reserves that some local communities have, the same way they rescued the banks when they overextended themselves.

So far, our talented team at Qbix has been able to put out some impressive apps that are well-received around the world. We built an open source platform that lets communities host their own social network, and for people to manage their own identities and data privately and securely. Hopefully, in the next few months, we will expand our team and bring on board the right partners (from the fields of security, crypto-currency, and economics) who can help us to achieve our larger vision of empowering people and uniting communities.

Posted in Uncategorized | Leave a comment