I have a long list of ideas for applications. But as they say, ideas are cheap. Execution is everything. And the key to execution is the ability to prioritize, which is never easy when there are so many ideas floating around. This is an attempt to get some of them down on paper and solicit feedback and opinions.
There are a few core principals I am working with here. First is that I want unto.net to remain non-commercial in the sense that it should be a way of giving back to people even more than it takes in. Profit-making is ancillary at best. Doing something that people (including me) can love comes first. (Though I do dream of some day taking a company public independently -- offering ownership directly to the consumer in a private auction. We'll see how the SEC feels about that one...)
If I could envision one tag-line at the bottom of every page of every application on unto.net it would be:
It's our Internet. Let's take it back.
Second, I need to build something I personally believe in. If an application isn't useful enough for me to use day-to-day, it will be impossible to sustain the passion necessary to make it successful. Delancey was built with that in mind, and it has been my browser homepage since launch. That makes all of the difference in the world. I'd almost go so far as to say, if you aren't personally passionate about what you do for a living, it is time to make a career change. (Fortunately, this isn't a problem for me.) So I am thinking about what applications I'd want to use but don't currently exist on the web (or ones that can still be improved on).
Third, everything should be done according to the "open secret" of Web 2.0. (I keep meaning to write about what I belive this is -- soon, I promise.)
One of those ideas is actually related to the topic of this post: polling and surveying people. In particular, a way of polling broad audiences for their opinions. I would like to be able to post a quick survey that reads "what should I build next on unto.net?" For possible responses, I would want to both offer a handful of my own ideas and solicit additional suggestions from the readers. And I would like people to be able to add their own polls -- it would be fantastic to have a place where you could post a question like "Which of the following CDs should I buy?", or "I am building a new machine, AMD or Intel?", where readers could not only vote, but also offer their opinions as to why. And here's where that idea gets interesting -- everything should be weighted. People can weight their votes based on how strongly they feel. Votes can be dynamically totalled based on a time-based decay, so as to maintain long-running polls that can change (and be charted) over time.
But more than that, I want the users to have more control over the ratio of signal to noise. The clearest path to that is to introduce the element of trust. In the ideal model that I am imagining, every thing, be it a person, a poll, a message, or whatever, would be subject to a trust value. Taken to the extreme, these trust values would be purely relative (think of Einstein's general theory for a moment here) -- there is no universal trust value for any entity, trust is entirely dependent on the observer.
Here's a scenario: I create a poll asking "what should I do next on unto.net?" and offer a handful of suggestions. Anyone with a trust value over "0.2" can respond (to weed out entirely untrusted people), and anyone with a trust value over "0.7" can add their own suggestions to the poll. When a user's vote is tabulated the score is adjusted roughly according to the formula: [how much do I trust them as a user] * [how much do they weight their own response] * [time decay]. My trust for another user is again relative -- either I have explicitly said I trust them at a certain value, or it is dynamically calculated based on the trust values of the people that connect us. (In a purely relative trust universe this would take into account everything, though there would presumably be some exponential fall-off based on some notion of "distance".)
(In practice. to keep things scalable, trust values will likely never be either entirely relative or entirely dynamic -- but there are ways to make it appear approximately so.)
Relative trust values could be applied to more than simple polls, of course. Remember the idea of the Blwog (the hybrid Wiki/Blog)? Imagine if you could restrict edits or comments to only those users that pass a certain trust level. Think how quickly this would defeat comment spamming, for one.
The trick is to make assigning trust values trivial. In the idea world it will be as simple as seeing a user's profile, or a "blwog" posting, or a comment, and dragging a slider somewhere between "not at all" and "more than I trust/value myself." The slider would appear everywhere, ubiquitious in the same way the Amazon rating stars are ubiquituous, but so much more powerful and flexible.
Or how about a review system? Users are encourage to review their favorite things -- restaurants, movies, albums, video games -- and other users can assign trust values to the reviews and the reviewers alike.
What else could you assign trust values to? I have an idea of one thing -- perhaps quite paradigm transforming -- but I'll keep that to myself for now.
For the sake of community, I would want to do the following things:
One, trust values are not public. At least not in a universal sense. I don't want this to be a competition for bragging rights. Slashdot did the right thing years ago when it made the "karma" values private. Two -- and this is a big one -- the network is not exclusive or closed, but it is controlled in the sense that it will be invitation-only. The people you choose to invite reflect on you, both positively and negatively. If someone you have invited is a valued contributor to the community, then your trust value will increase by association. If they are poorly behaved (spamming, acting in a spirit that violates the spirit of the community as it evolves, etc.), then they will in turn drag you down. And since high trust values will entail more privileges (where and when and how much one can post) vs. low trust values taking them away, people will be naturally encouraged to promote a healthy ecosystem.
Which leads me back to Orchard. Orchard will be a distributed system for user identification. This software component will handle the authentication and security for user logins (pluggable for integration with existing backends), as well as manage the invitation system. I will go into details about the goals and implementation of Orchard in my next new project post.
The key unifying force here is that all of these ideas are centered around community. I've been fascinated by community ever since the first time I used a computer -- so much so that I've never seen much use for these things when they aren't plugged into a network of some sort.
Thus the partial list of "what's next" for unto.net includes:
- Orchard, a distributed user identification system
- A polling/survey application
- A hybrid wiki/blog
- A universal trust-based review system
- A simple "sticky-note" note taking system
- The secret project
There is not a single thing in there that really worries me on a technical level. While some parts are hard, nothing is impossible. The underlying technologies are all available, and many of these applications can leverage existing components to save time. The limiting factor is simply time, which is why prioritizing is so important. But up first is Orchard, if only because it is a core bit of technology that everything on the list requires.
Oh, and one neat side-project that I'd like to build is a "REST Queue." As I imagine it, a REST queue is a proxy server that intercepts incoming HTTP requests and looks for the presence of special queue headers that indicate that the message does not require a synchronous response. If those headers are found, or if the proxy is configured to intercept that particular path, then the message would be spooled to a high-speed storage facility to await future retrieval. Servers could then register with the queue and request that the messages be replayed exactly as they originally arrived, dequeuing if they are processed successfully. The REST queue could help ensure eventual delivery, and enable a system to scale laterally by decoupling the processing of potentially computationally intensive events from their underlying delivery mechanisms. One obvious use of a REST queue is as a proxy for the AJAX messages that will be sent from a client to the server that handles trust value change events. (I could also use this in Delancey for the bookmark click events.) A neat project for anyone that has time... I can see it being easily implemented using either mod_perl or as an Apache module written in C.
As always, more to come...
[Oh, and to head off a possible concern about trust-values, the emphasis placed on trust will be configurable on a per-user basis. I could chose to filter/sort/prioritize trusted "things" to a high degree, whereas you may find trust values to be far less useful, and discount them entirely.]
Update:
I just went back and read what I wrote last June in an article entitled The Shape Of Things To Come. It is worth looking at again, both to see the evolution of ideas and to be reminded of a number of good ones from before. It is a little discouraging to see how little progress I have made to date, especially considering how little effort it would have taken. Fortunately these new ideas build on the older ones rather than invalidate them. If anything, the parts are now even more clear: a "trust value enhanced" distributed user identification system, a "trust value enhanced" distributed indexed document storage and retrieval system, and the various applications that can be built on top of each.