In the hours following a massive data leak where data from almost all Turkish citizens was exposed, users of the only industry where this kind of mass security failure routinely happens concluded there was no way to prevent such breaches from taking place. “The data breach involved 85 million people, and that happens to be also the population of Türkiye, but sometimes these things happen and there’s nothing anyone can do to stop them”, said Oysel Vek, echoing sentiments expressed by millions of individuals who post their names, religion, sexuality and personal information into centralized computer networks in order to send cat memes to one another. “And besides,” he continued, “we’re mostly just talking about all personal data, including that of relatives, bank details, title deed information, and addresses of every resident in Türkiye. There’s much more to life than these things.”
“It’s a shame, but what can we do?” asks Melon Usk, quizically raising his eyebrow. “It’s not like we have some kind of alternative open source platform that lets each person and organization control their own data. ” When asked about WordPress, which powers 4 in 10 websites in the world, he exclaimed, “Are you kidding? I want videoconferencing, chats, events, payments, profiles, and I want it all in real time with slick notifications. If I am going to check my phone 10 times a day, and share the latest controversy with my friends it’s definitely not going to be on that old software. That’s the modern internet industry. But they better beware, if WhatsApp wants to sell my data, I’ll show them!” At press time, millions of people around the world were seen switching from WhatsApp to Telegram and Signal, in an effort to escape putting all their data, conversations, money and votes in one place.
This article is an homage to The Onion’s article about mass shootings that happen with some regularity in the USA, which is reposted every so often with only the dates and names changed. Here is last year’s article.
In the hours following a massive data leak where data from almost all Brazilians was exposed, users of the only industry where this kind of mass security failure routinely happens concluded there was no way to prevent such breaches from taking place. “This is literally hundreds of millions of people, but sometimes these things happen and there’s nothing anyone can do to stop them”, said Bark Megor, echoing sentiments expressed by millions of individuals who post their names, religion, sexuality and personal information into centralized computer networks in order to send cat memes to one another. “And besides,” he continued, “this only happened because some employee uploaded a spreadsheet with usernames, passwords and access keys into a GitHub repository. Mistakes do happen, after all.”
“It’s a shame, but what can we do?” asks Wenin Denig, quizically raising his eyebrow. “It’s not like we have some kind of alternative open source platform that lets each person and organization control their own data. ” When asked about WordPress, which powers 4 in 10 websites in the world, he exclaimed, “Are you kidding? I want videoconferencing, chats, events, payments, profiles, and I want it all in real time with slick notifications. If I am going to check my phone 10 times a day, and share the latest controversy with my friends it’s definitely not going to be on that old software. That’s the modern internet industry. But they better beware, if WhatsApp wants to sell my data, I’ll show them!” At press time, millions of people around the world were seen switching from WhatsApp to Telegram and Signal, in an effort to escape putting all their data, conversations, money and votes in one place.
This article is an homage to The Onion’s article about mass shootings that happen with some regularity in the USA, which is reposted every so often with only the dates and names changed.
The social platforms we use today are all centralized under the control of large corporations. Our conversations, our identities, private documents, and public announcements are hosted on their servers. The vast majority of people online live in a feudal society dominated by Facebook, Amazon, Google, Apple and Microsoft. This is also true of small businesses, whether they sell their products on Amazon, release apps on Apple’s store, announce events on Facebook, reach their followers on Twitter, or blog on Medium. They even put their brand behind the brand name of the rent-seeking platform that hosts the infrastructure.
But the societal problem is even bigger. As a society, the problem is that our public forums, spaces and discourse take place on privately owned platforms. The mentality of “I built it, so I own it” has led to Mark Zuckerberg controlling Facebook, Jeff Bezos controlling Amazon, and so on. With great power comes great responsibility, and these companies are often held directly responsible to somehow do “the right thing” on an impossibly wide variety of circumstances. Even public interest groups like EFF admit it may be infeasible. Zuckerberg was excoriated by Congress in 2019 for not taking down certain content, but then in 2020 grilled for censoring similar content. For everyday communication online, most people are forced to trust large corporations whose interests may not align with our own. The issues of deplatforming and money in politics are actually secondary symptoms of this main problem.
The Solution
The solution is open source software that can move our digital society from feudalism into a free market. Such software is motivated by principles of agorism and distributism rather than pure capitalism. Tim Berners-Lee invented the Web, Linus Torvalds built Linux, and Vitalik Buterin launched Ethereum, but they don’t “own” it. The Web, Linux and Ethereum are permissionless for anyone to use, and this is precisely why they have led to an explosion of wealth for the world.
There was a time when America Online, CompuServe, Prodigy and MSN were the companies through which most communication online happened. People dialed in and chatted. But the open Web changed all that: companies were suddenly able to serve their websites with a large free market of hosting providers, and domain names were available to everyone. People no longer needed to rely on infrastructure provided by AOL, cable channels, TV stations, radio stations and other gatekeepers. As a result, the Web has led to trillions of dollars in business models like E-Commerce and Software-As-A-Service, which would not have been possible otherwise. Google and Amazon could not have built their businesses on top of AOL; they were given their start precisely because the Web was open.
Today, WordPress powers nearly 40% of all websites in the world. But it is good for one-way publishing (Web 1.0) . When it comes to community software (Web 2.0), people turn to Facebook, Twitter, WhatsApp, YouTube to connect and interact. In order to liberate people from this feudalism, there has to be an open source solution like WordPress, but to provide an alternative to those companies. Just as the Web once provided an an alternative to AOL, MSN, etc.
The Qbix Platform allows you to deploy your own open source Community Server, and totally own your data, brand and relationships. No more need to pay Facebook to reach your own audience. No need to worry if Apple kicks your app off their Store. You’ll always be accessible on the open Web. And if hosting on Amazon gets too expensive, back up your database and move it somewhere else. Install third party plug-ins from a growing ecosystem of developers, built on open standards. The software is yours. Do with it as you wish.
Learn more about it in the video below. If you to get in touch, back our project, or just want us to build an app for your community, fill out the form at Qbix.com
Okay, that was quick. A few months after writing that we hit 7 million users, we blew past our 8 millionth user. By now, over 8 million people across more than 95 countries have installed Groups and Calendars.
But, how many people have kept our apps after downloading them? We learn that information whenever we release a new version of our app. Over the next 30-90 days, we are able to see how many people are updating the apps. We began to do a “phased release” and closely monitor if any of our users experience crashes or other problems. After our latest release this March, how we found out that at least 1.5 million people have updated the Groups app:
Last August, we found out that at least half people have updated the Calendars app:
Here is an overview of the countries these Groups users are in, from the period of March 22 – April 22. Around half of them are in the United States:
We passed a new milestone recently: Qbix apps have attracted 7 million users from around the world. Here are some more cool stats:
Qbix apps are used over 1.2 million times a month
by people in nearly 100 different countries.
They are translated into 15 languages by hand,
and another 100 languages using Google Translate
Every day, 2000 new users discover our apps,
including 300 community leaders and 80 business owners.
We have 80,000 community leaders to date.
The Calendars app runs continuously on 27,000 computers
Below, we put together an interactive visualization of all our users around the world, complete with sample reviews in their native languages. Feel free to rotate the globe below, tap on some countries and explore the reviews in the app store. Those white animated pings you see represent people actively using our apps around the world!
Of course, we are pretty proud of reaching this milestone. But our biggest announcements are still ahead this year. They have to do with the Qbix Platform and the QBUX Token.
Now that 2020 is here, let’s look at what we can expect from the next decade in software. As Web developers, our solutions can help shape the organizations we work for. The tools we build and the architectural decisions we make have a compounding effect on society at large. What are the new trends, and will they help empower or enslave people?
The Old Trends
The trends in the last 10-20 years have led to more and more centralization of the Web, consolidation of power in the hands of the largest services (Facebook, Google, Amazon, Reddit) and their extended ecosystems. Between these and the large publications, the “independent Web” has suffered a tremendous setback. Most people and organizations trust large corporations with proprietary algorithms to manage their data, identity and brand. This has led to massive new issues for individuals and society, involving governments and corporations, and how we all relate to one another. Attempts to resolve these issues have spawned some projects to decentralize the Web.
When the Web was born, browsers rendered HTML documents, and there was very little support for client-side programming. Whatever Javascript support was introduced over the next decade was inconsistent because of the browser wars, and led to Javascript libraries to bridge the gap, of which jQuery emerged as the winner. The last 10 years saw the rise of Angular and React, new versions of Javascript and HTML5 Web APIs, which finally made front-end Web programming a powerful proposition on the most widely deployed platform in the world.
Client-First Web Apps
As Javascript was maturing, a conventional wisdom has developed among most Web developers, that you should render the HTML on the client side, and then progressively enhance it with Javascript. This was considered best practice and recommended by pretty much every authority from 2009 to 2018.
In this decade, Web developers will turn this conventional wisdom on its head, and start to consider progressive enhancement to go the other way:
First, develop static HTML, CSS and Javascript
Make Javascript fetch data from servers, render it on the client
Progressively enhance the site for older environments (Server-rendered HTML)
What follows are multiple reasons for why this is the better approach going forward. This one shift in how we approach Web development will have profound technological and societal implications.
Distributing Software
1. Separation of concerns. It pays to decouple the rendering of an interface from the delivery of code / markup. That way we are not tied to one type of app delivery — that of a server on the web sending our executable code. We are able to sideload apps, download them from app stores, and update specific files when they have changed. And we use one language for each task, too: JS is the code. HTML / Handlebars / etc. can be used for templates / markup. CSS is used for presentation. JSON or XML is used for data. After you have done this, if you want to pre-render HTML on a server for AJAX, you can, but will start to feel “dirty” as you’ll be coupling things unnecessarily again. Things are going this way as headless CMSes are making an appearance, while Cordova, Ionic and React Native represent other ways of delivering code through app stores.
2. Trust. You can’t trust what code is running remotely (although Signal has been experimenting with using Software Guard Extensions by CPU makers, originally designed for DRM, to go the other way and ensure what code runs on a server). But even if you can, you have no guarantee some other process won’t steal or corrupt your data. The Trusted Computing Base should not include arbitrary amounts of remote sites shipping code at any time. Decoupling how the code is loaded (see point #1) onto your client allows you or your user agent to verify checksums and certify that it is indeed the code you think it is. And it is that code that should be managing your data and using the personal keys on your device. Package managers and app stores will be able to distribute code that has been audited by third-party security firms, and people will be able to trust them.
3. Decentralization of Code. As the next decade unfolds, we will find that code bases don’t necessarily have to live shrink-wrapped on a specific server. Rather, clients can use multiple interoperable software modules and versions and can have multiple app stores and distributors in the future helping maintain repos and package managers for end-users and organizations. We will probably see automated package management become more user friendly in the 2020s, as we already have a docker container culture, we have browser based package managers etc.
Data Ownership
4. Decentralization of Data. This is the big one in terms of effect on society. By having web servers render your webpage, you are implicitly locking yourself and your organization into the type of model where the servers store and access the data in a private database. They have enough data to render everything, apply access control rules to manage what you can read and write, and so on. Instead, we as a society need to empower people and their client side apps, and push the logic of fetching data, caching it and assembling it to the user agents. We can use capabilities / access tokens for data instead of a centralized site rendering HTML. In this way, always inverting the progressive enhancement is an activist position to change society against the abuses of power like the ones listed here.
5. Reliability After the 2015 ISIS attacks in Paris, countries around the world expressed solidarity with the French people. French colors were flown, but similar-sized attacks at the same time by ISIS in Beirut were totally forgotten. Facebook rolled out a feature to customize one’s profile with the French flag superimposed, but only the French flag. So we used the Qbix Platform to quickly build a small app called customizemypic.com to allow anyone to change their profile picture to a flag of their choice. The goal was to make a statement and express solidarity with people in Beirut, Baghdad and other areas hard hit by terrorism. Today, that same app is no longer able to do its core function because Facebook removed any way for users to give permissions to apps to upload a photo on their behalf. This is what happens when you rely on third parties to announce what you can and cannot do with your own profile picture. The most extreme reliability is achieved by an offline-first approach, which is a close cousin of the client-first trend that will grow in the 2020s.
6. End to End Encryption. Server-side rendering perpetuates a culture where the server has all the data unencrypted. Even if the data is encrypted at rest, the served holds all the decryption keys and is one central target for hackers, government agencies, and advertisers. Rendering things client-side goes hand-in-hand with a culture of people storing their own keys on devices of their choice, and letting key management and password management be the domain of operating systems and trusted computing bases, not random websites.
Data Delivery
7. Bandwidth. Ever since Steve Jobs presented WebObjects, we have wanted sites to render dynamically. Well, that often involves looping through various items and rendering each one. It is extremely wasteful to send the HTML results of rendering hundreds of items to a client, when you could have just sent the data, which would then be “hydrated” into 5. templates by the client. However, I can understand pre-rendering just the items above the fold (if one could estimate this number, not knowing the size of the window on the first request).
8. Caching Issues. Often, you have subtle and pervasive changes on every page when a person is logged in vs out. (I should remark that “logging in” into a site itself is an artifact of “centralized” thinking, but I digress.) Their avatar might be rendered in various places. New links are shown that might not be available otherwise. And new information may be shown that access control and discovery suggestions determines they can see. If you render everything on the served, there is no way to cache most of the fragments of the page, because they are changing. If you render client-side, all this comes for free.
Next Steps for Web Developers
So by now you may be convinced that “client-first” is a good design pattern and progressive enhancement can be implemented later, by “speeding up” the first render, and by making it available to “dumb” crawlers and user agents who don’t execute Javascript in 2020. Here is how that would actually look, in actionable terms:
9. Preloading. Okay, now that you are rendering everything client-side, you can implement a mechanism to preload data from the server. Perhaps put all the JSON in one file and send it over on the first render. Which — remember — happens only when you use a Web Browser to visit a page directly, a very specific scenario. Every other request besides that, including subsequent requests from a web browser, don’t need this preload. It’s an extra flair you can add for that specific use case. So the preloaded data comes and your Javascript will already have it and will render the HTML synchronously and quickly.
10. Static Site Generation. The most popular static site generators today are still pretty narrow in their use-case. They help with blogs and publishing, eg Jekyll, Hugo, etc. But if you already have a dynamic site, you can sort of transform it into a static site by having a server-side script request some (dynamically specified) set of pages and render them to some related static html documents, and then begin sending 301 redirects on the dynamic pages to permanently tell browsers to go to the static pages in the future. (Because rewriting all links in your site may be infeasible). This approach runs into problems I described in point 5 — so a naive approach would only work for publicly accessible pages that don’t change when someone is logged in. You may still need to add client side JS to “fix up” at least the basic affordances for logged-in users.
11. Caching, Throttling, Batching. Every function that issues a GET to a server could be made smarter to take into account caching, throttling, and batching of request. In Qbix Platform we have middleware methods like Q.getter and Q.batcher which take any getter functions and transform them into ones that do the above things. They work with instances of the Q.Cache class which have adapters to cache in the current document, in sessionStorage or localStorage. (And later maybe in IndexedDB etc.) They have hooks for additional steps when serializing and unserializing objects etc.
12. Deployment. We have built various scripts in the Qbix Platform to help not just Qbix apps but general websites be deployed, including:
combine.php (which fixes css files to have absolute URLs, minifies, combines etc. all scripts and stylesheets you tell it, and Qbix Platform rewrites links when you add scripts and stylesheets)
urls.php (which goes over all the static files inside the publicly accessible web directory, checks their modification time and builds indexes in php and JSON as to what changed since the last time it was run… allowing clients to eg download a diff of what files changed since last release. If also calculates hashes for SRIs and Qbix apps automatically append the correct SRI information when rendering certain tags, and the correct timestamp for cache-busting.)
static.php goes over your site, whatever it is, and generates a static version that you can serve, and 301 Redirects for the rest. It helps turn a lot of your public pages into a static site.
bundle.php (which builds a bundle for Cordova app deployment. The client-side Cordova plugin from Qbix intercepts requests and sees if there is already a local version in the bundle, and serves that if needed. This works with https as well. One of the many client-side Cordova features that allows us to turn websites into native social apps. Sadly, Apple doesn’t support Service Workers or AppCache for WebView.)
These PHP scripts are part of a larger open-source ecosystem that we developed to help Web Developers take advantage of modern security practices and build advanced social web / native apps like this one for Andrew Yang.
The Platform is free and open source, with tutorials and a guide on how to use it. If you are interested in learning more about the Qbix Platform, then reach out to us. And if you have a meetup or group that you’d like us to present and answer questions, let us know.
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.
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.
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.
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:
End to end encryption
One giant, actually decentralized cloud composed of all nodes running the software
Storing chunks of encrypted data using Kademlia Distributed Hash Table, a technology that’s available since 2002 and used in BitTorrent and MaidSAFE
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.
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.
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.
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.
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.
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.
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.
Intercoin
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.
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:
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.
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.
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.
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.
Get blog updates
