Blackbox
Part 1: I Promise This Is Going Somewhere #
“The unexamined life is not worth living.”
– Socrates
The process of self-discovery is very similar to any process of scientific inquiry. We start by forming a hypothesis about ourself, which we use to make our lives more manageable and efficient. For example, I have a belief that I don’t like country music. I use this belief in my day to day life frequently: for example when I turn on the radio in my car I don’t re-check the country station to verify that I don’t want to listen to it. I assume that my belief still holds and I can safely tune to the indie rock station. But what happens when I start grooving to a country song at a party? My actions no longer agree with my beliefs. This hypocrisy creates dissonance which our brain resolves by either refining our belief or redefining ourself. Perhaps I decide I’ve been classifying country music too broadly and I refine my definition of country music to something more exclusive. Or perhaps I decide that I actually do like country music. Either way I’ve created a new, more informed, belief about myself.
This cycle - refining and testing beliefs - is the means through which we learn about ourselves, and it’s highly iterative. The more iterations you make, the more specific and granular your definition becomes. But going through this process is not easy. Our brain is wired to resolve cognitive dissonance with less than scientific rigor, at times so seamlessly that you might not even realize it. This situation provides us with an opportunity for improvement. How can we maintain and even expand the brain’s ability to efficiently make decisions while increasing our awareness of how these decisions are made?
This sounds difficult but we have the benefit of computers and lots and lots of people, all of whom are constantly producing data. Computers are really good at remembering this data, and algorithms are really good at transforming and condensing data into more useful forms. Computers and algorithms, however, are not so good at becoming happy and fully-actualized human beings. By delegating the rote parts of self-definition to a computer we can free up more time for our brains to focus on the higher level process of becoming actualized.
Part 2: Somewhere #
“Nothing exists until it is measured.”
– Niels Bohr
Blackbox is a platform for tracking your life. Unlike my previous attempts to create something based on these ideas, Blackbox is not a product; it has no user interface and you can’t push buttons to make it do something. Blackbox by itself is useless. What Blackbox provides is a standard model for data tracking and an interface to make incorporating this model into products as easy as possible.
The Model #
Log #
- int id
- int timestamp
- User owner
- Tag[] tags
- {} data (arbitrary json)
Logs are the core data structure in Blackbox. Each Log object represents a change in the state of some User at the timestamp. This change is defined by some arbitrary json data and can be categorized with tags. Logs are intended to be used liberally, and rarely deleted or modified.
Tag #
- int id
- User owner
- Tag[] supers
- {} requiredData (arbitrary json where the value corresponds to the type of the key)
Tags are used to categorize and enforce a schema on Logs. A Tag can require that a Log contain at least a minimum set of data. Tags can also extend themselves from pre-existing tags. A Log that contains a Tag ‘x’ where extends from tags ‘y’ and ‘z’ must contain both the data required by ‘y’ and the data required by ‘z’. In a similar vein, a Log can belong to any number tags as long as it satisfies their requiredData. Tags are intended to be applied liberally but created sparingly, and only when existing tags can’t provide the desired level of granularity. When new tags are created they should extend from existing tags whenever possible.
User #
- id
Users are the most un-explored part of the Blackbox structure. Right now they simply represent one consistent logging entity, and provide the same functionality as Tags. What I’m working on is using Users to incorporate privacy and protections. Additionally, Users could be used to enforce consistency and security, and could also be extended to allow for a ‘groups’ concept.
The Interface (as a REST API) #
GET /logs/:query returns the Log objects matching query
- default ordered by timestamp and paginated POST /logs/:log adds log as a new Log object
- log must satisfy the data requirements prescribed by its tags PUT /logs/:query/:log modifies the Log objects matching query by log
- must be performed by the owner of the log DELETE /logs/:query deletes the Log objects matching query
- must be performed by the owner of the log
GET /tags/:query returns the Tag objects matching query
POST /tags/:tag adds tag as a new Tag object
- must be performed by a validated User PUT /tags/:query/:tag modifies the Tag objects matching query by tag
- only the creator can modify their tag
- due to potentially conflicting dependency chains, modifying the supers of a tag can produce inconsistent data DELETE /tags/:query deletes the Tag objects matching query
- only the creator can delete their tag
GET /users/:query
POST /users/:user
PUT /users/:query/:user
DELETE /users/:query
In Progress #
- authentication
- permissions
- security
- limits
- privacy
- groups
- streaming api
Part 3: What Makes This Different From _____? #
“Sometimes it’s as important to know what something isn’t.”
– my dad
When talking about this idea with friends I have found its abstractness susceptible to confusion with existing products and services. I’d like to address those concerns here.
Blackbox is not Google, or Facebook. Yes, both Google and Facebook have a lot of data and both release that data in a platform format, but Google and Facebook are not about that data. Google is about search and advertising. Facebook is about social and advertising. Google and Facebook track your data so that they can search, social and advertise to you better. Blackbox is about you tracking your data to do what you want to do with it. Period. If you want to use your data to make advertisements towards you better, go for it. If you want to use it to make advertisements towards you worse, alright. Whatever you want to do with your data is your prerogative.
This user-centric focus is crystallized in one of Blackbox’s core beliefs: you own your data. When you play a song in iTunes, Apple doesn’t own the fact that you played that song. You own that fact, and you should be able to do with it what you wish. Blackbox puts you in complete control of your data. You can easily see what data is being tracked, where it is being tracked from, and where it is going. You can easily restrict or remove any of these processes, and you can easily modify or delete any of your data. Blackbox doesn’t do anything that you don’t explicitly enable. You’re in charge.
That being said, Blackbox is not a notepad (at least, not in the sense of a traditional pen and paper notepad) because Blackbox is much, much more powerful. Consider an app for managing a grocery list that’s built on top of Blackbox. It could start by cloning the traditional pen and paper grocery list functionality by providing a list view of text items with checkmarks and an add new button at the bottom. This is alright, but with Blackbox we can make it better. For example, we might start by adding autocomplete functionality based on your previously logged items. Or, if the user has decided to make this data public, based on everybody’s previously logged items. With all this data we could even take it a step further and begin predicting what items you’ll want to add to your list and use that information to make the experience even more seamless. Or make recommendations about items you might not have even known about. Blackbox makes it easy to incorporate big data into your products.
This brings us to another of Blackbox’s core beliefs: data is better together. Data is like a currency - the more it’s spread around the more value it creates. As we said before, Blackbox puts you in control of your data, but that doesn’t mean you should hide it. When you can, share your data! Let it be free! Developers will use this data to make their products better and everyone will benefit.
This applies vertically, like in the example, but also horizontally. For example, perhaps you think you think grocery lists are correlated to emotional state. If somebody else out there has an app built on Blackbox that tracks emotional data, and makes that data public, then you have access to it also. Data should be shared and Blackbox makes it easy to do so.
Blackbox is not an analytics service.
Blackbox is not Dropbox, Google Drive, or whatever Microsoft’s cloud storage is called these days.
Blackbox is not Wikipedia (although it pulls inspiration from the idea of democratized knowledge and trust based aggregation).
Blackbox is not Twitter (although it admires Twitter’s structure and belief system (open source, inside-out, realtime, etc))
Blackbox is not LastFM (but actually it kind of is just not just for music)
Blackbox is not Parse or Meteor or AppEngine.
Blackbox is not just a wrapper around a database (although it does wrap a database). Blackbox is a paradigm for structuring data interactions. Part of this paradigm is a kick-ass database wrapper; Blackbox provides an interface which is intuitive, yet flexible. More importantly, however, the Blackbox paradigm involves standardizing the the way we interact with data. You don’t retrieve the memory of last sunday at the beach any differently then you retrieve the last page you read in your mystery novel before falling asleep; the process just happens naturally. Similarly with Blackbox, the data may come from different places and be used in different ways, but the interface for interacting with the data stays the same.
This leads us to Blackbox’s final core belief: Blackbox is a philosophy; It’s an opinionated belief in both data ownership and data sharing, a paradigm for conceptualizing data, a vision that data tracking can unlock human potential and lead to better, more fulfilled lives, and for Blackbox to work, all the stakeholders need to buy into the philosophy. Blackbox is about creating and tending a data ecosystem, where value comes from everyone participating.
Part 4: Starting Lean #
“Learning is the essential unit of progress for startups.”
– Eric Ries in The Lean Startup
Blackbox rests on a set of assumptions. Some of these assumptions have been previously validated through external circumstance, but some are as of yet untested. Part of the process of validating Blackbox as an idea involves validating each of these new assumptions. Usually this involves iterating on an MVP, but Blackbox is a tad more complicated than the average app idea. As a result I think it makes sense to split the Blackbox idea into several different ‘products’ which can each validate different parts of the idea. Some of these products can take the form of actual products that are built on top of the Blackbox platform, and those will be explored in other blog posts. For this blog post I want to highlight just two MVPs: one testing the philosophy assumption, and the other testing the technology assumption.
Stakeholders agree with the Blackbox philosophy (or at least some subset of the Blackbox philosophy) #
To test the Blackbox philosophy I would create a landing page similar to this where stakeholders can start getting excited about Blackbox, and sign up to a wait list to show their support. This landing page should be clear and direct in explaining the Blackbox philosophy. It should do this, in part, by providing examples about how the technology would affect different types of stakeholders. For example, for companies it could include information about how integrating Blackbox could make their products more valuable. For end users it should include examples of the types of products that could be built on top of Blackbox.
This MVP would measure success based on the number of people that sign up to the wait list, and the number of people that share the idea. It would iterate on both the Blackbox philosophy, and the way that the Blackbox philosophy is communicated.
Developers will build apps on top of Blackbox (or at least integrate it somehow) #
To test the viability of the Blackbox data interaction paradigm I would create an interface. This interface could be provided in the form of a js library for website development. In order to maintain feasibility this interface would reduce scope in three major ways:
- Not perform at scale
- Built on existing infrastructure
- Contain less features
To limit the scale of Blackbox.js it would only be available to a select few developers, and those developers would be limited in the number of new tags they could create. These developers would also be chosen in part based on the scope of their product so as to prevent the early Blackbox MVP from being inundated with logs.
Nothing is ever built completely from scratch, but the Blackbox MVP can rely even more than most on existing products. For example, it might rely on free (but slow) Heroku hosting for early iterations.
Blackbox.js will export the following interface:
- Blackbox.log(accessCode, tag, data)
- Blackbox.query(query, cb)
var Blackbox = require('blackbox');
var accessCode = 'xxxx';
Blackbox.log(accessCode, 'grocery', {
name: 'Milk',
quantity: 2
});
Blackbox.log(accessCode, 'grocery', {
name: 'Bread',
quantity: 1
});
// empty query to get back all of the data that's been logged
Blackbox.query({}, function(error, data){
data.forEach(function(item){
console.log(item.quantity + ' ' + item.name);
});
});
Anything logged without a valid accessCode or tag would be rejected. To create new tags, clients must go to a different website and authenticate themselves with their accessCode. Although the functionality of Blackbox.js is severely limited, I believe it is still extensive enough to be of use for some developers on simple projects.
The MVP would measure success based on subjective response from developers using the technology and would iterate on the interface.
Part 5: Join the Revolution! #
Interested? Tweet me @jomrcr.