Will Norris

Outsourcing comments to Google+

2011-09-15T21:42:14Z

A few weeks ago I quietly (or not so quietly, as it were) disabled comments on my blog. It was something I’d been considering for a while, and I finally resolved to do it after talking with Shane Becker at IndieWebCamp back in June. Shane takes the stance that his site should be about him and his content. If you want to comment or respond, you’re welcome to do so… just find your own place to publish it (like your own blog, perhaps).

I’m not interested in building a community or a personal brand, so I really don’t care about capturing engagement here on my site. I do value a lot of the comments I get however, so I’m not looking to cut things off entirely. Instead, I’ve decided to outsource my comments to Google+.

Today we announced the launch of the Google+ API, starting with read access to public data. Using the new API together with the +1 button, I’ve added support to my snowflake to share my posts to Google+, and then to easily direct conversations from my blog to there. It allows me to keep my own home on the web dedicated to just my content, and at the same time leverage the great community that has formed around Google+.

Please try it out yourself, and let me know how it works for you. This was the work of a single evening, so I’m sure I’ll enhance it over time. Please file any bugs or feature requests you have.

https://github.com/willnorris/wordpress-snowflake

Launching the Google+ Platform

2011-11-28T03:20:46Z

A couple of months ago, I mentioned how excited I was to reveal to family and friends what I’ve been working on at Google for the last year or so, Google+. Well, that was only partly true. What I’ve really been working on is the Google+ Platform, which we are finally starting to roll out today.

In many respects, today’s announcement is perhaps more exciting for myself and the team than it will be for some of you. The surface that we are launching today is small, just three methods focused on reading public data. That’s what we’re starting with. You won’t find the ability to post into the stream or +1 a post, or the ability to access a user’s circles. But what you will find is a small taste of what we’ve been working on for a long time. You’ll find a clean and simple API that should feel very natural because it follows RESTful designs and uses JSON data formats. You’ll find an API that uses industry standards like OAuth 2.0 and that is based on open formats like Activity Streams and Portable Contacts. You’ll find well-written documentation with in-line code samples and an in-line API explorer so you can play with every method, all hosted on our new Google Developers site that will redefine what it means to be Google developer. You’ll find an API that is relatively small, but one that is the start of something very, very big.

This is perhaps the most important project I’ve worked on in my professional life, and I’m incredibly proud of what we are beginning today. I’m excited to see what people will build with the API, and I’ll be sharing some of my own Google+ projects very soon.

Excited to finally be able to talk to family and friends about what I’ve been working on

2011-08-20T06:39:01Z

Excited to finally be able to talk to family and friends about what I’ve been working on: http://googleblog.blogspot.com/2011/06/introducing-google-project-real-life.html

Post Once, Syndicate Everywhere #pose #indieweb

2011-08-20T06:39:01Z

first post using snowflake, my new WordPress plugin for syndicating personal published content #indieweb

Git is the next Unix

2011-08-20T06:39:01Z

Avery Pennarun in 2008:

With git, we’ve invented a new world where revision history, checksums, and branches don’t make your filesystem slower: they make it faster. They don’t make your data bigger: they make it smaller. They don’t risk your data integrity; they guarantee integrity. They don’t centralize your data in a big database; they distribute it peer to peer.

Hum – A Personal URL shortener for WordPress

2011-08-20T06:39:01Z

While I haven’t had much time over the last year or so to spend actually writing code for DiSo, I’ve been really interested in the new direction Tantek has been taking things with his DiSo 2.0 concepts. Many of the early efforts in DiSo were focused just on how to move social data around the web (data formats, protocols, authentication mechanisms, etc). Tantek is taking a slightly different approach to this by first emphasizing the importance of data ownership. It’s not enough to simply pull in a copy of your content from social networks into your local repository. In order to truly own your data, the original should be on your site, and then copies pushed out to whatever social networks, with links pointing back to the original where appropriate. It may sound like a purely academic distinction, but it’s the difference between sharecropping and homesteading.

So just to prove that I don’t actually spend all of my time in the belly of the beast, I’m happy to announce a new project I’ve been working on – Hum. It’s a personal URL shortener for WordPress, inspired by Whistle. It’s important to note that this is not a traditional URL shortener like bit.ly or goo.gl that is designed for creating links to any arbitrary site on the web. Instead, a personal URL shortener is intended to link to your own content… your blog posts, your status updates, your photos. When pushing content from your site out to social networks, you often need the ability to link back to the original. Thanks to Twitter this means short URLs, and following DiSo principles, this means controlling those URLs. A URL shortener may not be sexy, but it’s necessary infrastructure for DiSo 2.0.

Hum is like Whistle in a lot of ways. It’s designed to be run on a personal domain. It use NewBase60 encodings to keep the URLs both short and human readable. And it uses the same content-type partitioning of the URL space. The key difference is in the use of database keys. One of the design principles of Whistle is to have algorithmically reversible URLs. That means that anyone who knows the algorithm can convert the short URL back to the fully expanded form without actually having to make an HTTP request. It also means that you don’t need any kind of datastore to lookup the mapping. You can easily store everything in flat files. This results in a more stable and overall faster system. But because we’re building on WordPress, which is tied to a database anyway, there wasn’t as much of a benefit in avoiding the use of database keys in the short URLs.

How it Works

Hum is actually pretty simple. It’s very lightweight and currently uses no data storage of its own, as there are no configuration options. It registers a few URL patterns like /b/* and then handles any requests to those paths. For example, the short URL for this blog post is http://wjn.me/b/FJ. It also hooks into the built-in WordPress shortlink functionality to expose these new shortlinks in the metadata for each page.

Doing nothing else, this should give you reasonably short URLs, depending on your domain name. But the real value comes when you couple it with a personal short domain, and it’s incredibly simple to do. Buy a short domain, and set it to redirect to your primary domain. I did this by putting the following in my .htaccess for my short domain:

RewriteEngine On
RewriteBase /
RewriteRule (.*) http://willnorris.com/$1 [L,R=permanent]

Then you want to tell Hum that you have a short domain that it should use for generating URLs. To do that, add something like the following to your theme’s functions.php file:

add_filter('hum_shortlink_base', create_function('', 'return "http://wjn.me/";'));

And that’s it. You now have simple short URLs for all of your WordPress content. Hum includes additional hooks to make it very easy to link to offsite content, which I’ll hopefully cover in a future post. In the meantime, read the source… it’s pretty well documented.

This is only the first step in what I’d like to build for a WordPress implementation of DiSo 2.0, but a necessary one. If you’re interested in this, please contact me. You should also consider coming to IndieWebCamp in Portand, Oregon where we’ll be discussing this stuff for a full weekend.

Download Hum on GitHub: https://github.com/willnorris/wordpress-hum
Also on WordPress Extend: http://wordpress.org/extend/plugins/hum/

Cached Commons

2011-08-20T06:39:01Z

I’ve been working on rebuilding the theme for my site as I find a free hour or two every now and then. Eventually I’d like to do a new design, but for now I’m just working on rewriting the code itself. That will be a post for another day, but one of my focuses is to make things leaner and faster. One of the ways I’m looking to do that is by offloading as much as I can, using things like the Google Libraries API to load jQuery from a CDN. I’ve also been thinking about using Modernizr, though it has not yet been added to the Google CDN (or any other CDN that I can find). I did however find a very interesting project tonight that is trying to address this kind of problem.

Cached Commons was setup by Lance Pollard earlier this summer to provide a common repository of popular (and some not-quite-as-popular) javascript and CSS libraries. This is a great idea, and one I’m a little surprised hasn’t been done before, at least not quite like this. I do have a few random thoughts and concerns though that struck me as I debated whether or not to use Cached Commons’ hosted version of Modernizr:

I don’t know Lance Pollard. I’ve never heard of him before, and I have no real reason to trust him. Looking at his website and GitHub profile, he seems to be very active in the open source (and specifically ruby) community, which is a big credit. By relying on his hosted version of any of these libraries, I’m taking a risk that he could change the hosted files and do some nefarious things to my site. I have absolutely no reason to believe that he would, but it’s always possible. I don’t really have this worry with Google.
What happens if Lance loses interest in maintaining this project, or gets too busy to keep things up to date? Again, not something I worry about with a company like Google. Now in reality this isn’t really an issue for a number of reasons. First of all, it’s not likely that I would absolutely need the latest version of a given library sooner than Lance would get around to adding it to Cached Commons. And because all of his work is being done in the open, especially being hosted in GitHub, I or anyone else could make a complete copy of all his work in a matter of minutes and maintain it ourselves.
Cached Commons is powered by GitHub pages, which is certainly faster than pulling the files directly out of the git repository as Lance points out. However, I’m pretty sure it’s not actually a CDN in the traditional sense, so it’s not as likely to have the same speed or reliability over time. That being said, I have no reason to believe that GitHub would be any less reliable than my own site, which is hosted with Joyent.
One of the biggest benefits of using javascript libraries from the Google Libraries API has nothing to do with the speed at which the data can download, but rather the fact that it may not need to be downloaded at all. As more and more sites begin to use the same exact copy of a particular library, the higher the likelihood that a given user will already have the file in their browser cache. So if a user has visited any site in the last year or so that uses the Google Library API to host jQuery for example, there’s a decent chance that it won’t need to be downloaded again and your site will load all that much faster. This is really more in reply to Lance’s comment about jQuery loading faster from Cached Commons than from Google… it’s about more than just transfer speed. But for things like Modernizr that aren’t included on the Google CDN at all, Cached Commons is certainly a good potential alternative.
Another important principal when trying to optimize speed is to serve static content from a cookie-less domain. Cached Commons is not cookie-less because Lance uses Google Analytics on the site. Of course, the only way that a user would have a cookie set for Cached Commons is if they had visited the site directly, which for most users will be pretty unlikely. However, it is something to consider. This could be addressed by using different hostnames for the website and the file repository, but at this stage it’s probably not worth the effort.
Finally, I’m very curious how the folks at GitHub feel about this project. I’m sure they didn’t exactly intend for GitHub pages to serve as a blind file server for the world, but then again, maybe this is the kind of project they had in mind… GitHub pages is certainly optimized for hosting static files. But it’s still not quite the same as Google committing to support their Library API, and designing the service for exactly that purpose. GitHub is, without a doubt, one of my favorite services in recent years, and I certainly wouldn’t want to abuse that service in any way.

In the end, I’ll quite likely use Cached Commons for hosting various libraries like Modernizr… you have to find a balance in all these things, and the ease of just linking off to them is quite attractive. I’d love to see GitHub actually work with Lance and make this a real service that they offer similar to GitHub RubyGems (and others?). All in all, the work Lance has done on this is great… I’ve been wanting something like this for a long time, and am very pleased with what he’s come up with.

Going to Google

2011-08-20T06:39:01Z

I’m happy to announce today that I’ve accepted a job at Google, working on the newly formed Social Web team. I will be joining fellow new-hires Joseph Smarr and Chris Messina, as well as a host of other incredibly talented engineers, in contributing to the emerging standards and growing developer community in this space.

Instead of the long contemplative post on how this move is the next logical step in a career of working in Identity Management, I’ll keep it short. I start work next Monday, February 1st, and I’m a bit pre-occupied this week with getting moved from Portland, Oregon down to Half Moon Bay, California.

I expect great things from our team in 2010, and so should you.

Identity and Identifiers

2011-08-20T06:39:01Z

I still remember when I made the conscious decision to go by the name “Will” instead of “William”. I was 11 or 12 years old, and we were moving from Irving, Texas, where we had lived the last 7 years or so, to Olive Branch, Mississippi.

I don’t honestly recall why I decided to go by a different name. Name changes are common throughout history to mark a new beginning in one’s life. In the Bible, Abram is given the name Abraham, Jacob is renamed Israel, and Saul of Tarsus becomes Paul the Apostle. Converts to Islam will often take on a new Islamic name, and it is common for monarchs and newly elected popes to take a regnal name when they inherit the throne. It is customary in many cultures to take the surname of a spouse, or a blending of the two surnames, when one is married. Perhaps at some level I wanted to mark this new beginning in my life. I was leaving behind everyone I knew, and would be starting fresh with school, with friends… with everything. Maybe I wanted a new name to represent this new part of my life. Or perhaps I was simply emulating my older brother Steven, who at the time had chosen to go by “Steve”.

My immediate family was pretty good about respecting my decision. My mom later told me that when they were picking names for my brother and me, they went through all the possible nicknames and made sure they would be okay with them. Occasionally my mom would slip and call me William, and I remember that I used to get really mad about that. I don’t think my grandparents ever stopped calling me William, but after a while I got over it.

Identity Online

I think that I really started giving thought to my online identity when I was in college at George Tech. When I was a student, we were all given a “GT Number”, which was simply an opaque username and email address. Mine was gte739u, and so my email address was gte739u@prism.gatech.edu. Everyone had these numbers, and we all got used to them. Papers and tests might have a place to put your name, but they always had a place to put your GT Number. We weren’t names, we were numbers… we were simply $student++. I’ve never been one for pseudonyms, maybe because I didn’t have any real issues with my name. Up until this point, I had always used variations of my name for accounts: wnorris, wjnorris, or wjn730 if nothing else was available. It was only when I no longer had that freedom to identify myself how I chose that I became aware of how important it was to me.

It wasn’t until my second or third semester that I was eligible to get an account in the College of Computing, which you got to choose yourself. I was quite happy when I could finally give out a decent school email address to people — wnorris@cc.gatech.edu. In a small way, I felt like Equality 7-2521 asserting his individuality, taking the name Prometheus.

When I began to realize the benefit of a personal homepage, I found that the domain willnorris.com was already registered, so I settled on wirewater.org instead. I thought it sounded cool and I liked the definition in the Jargon File. I used that as my personal homepage as well as my main email address for several years, until I was able to buy willnorris.com a few years later and switch everything over to that. I had used wirewater.org so much during those years that I decided to just keep it indefinitely. I don’t think I ever receive legitimate email on that account anymore, but it costs so little that I don’t really worry about it. There is a competitive market for registering “.org” domains, so I can be assured that the price will always remain at a reasonable rate. If I want to change my registrar for whatever reason, I can easily do so.

A(nother) New Identity

In 2007, a new service called FreeYourID was launched by GNR and Janrain. For $11 a year, you could get a third-level .name domain of the form firstname.lastname.name. They would also forward email sent to firstname@lastname.name, and later added a few other identity related services like XFN links and redirects to your social network profiles. The most exciting part of all this was that every FreeYourID domain was automatically an OpenID, backed by MyOpenID. It was a great example of putting individuals in control of their identity online, and how OpenID delegation fit into that picture. Seeing the potential for this, I grabbed will.norris.name on the very first day. It wasn’t long before I started using this new URL as my primary identifier online. I still had willnorris.com and continued to use it as a blog, but will.norris.name became my “identity site”. It was a simple landing page that had contact information and links to my profiles on various services. Later I added an activity stream, and XFN links to friends and colleagues. More importantly though, I used it as my primary OpenID on any services that supported it.

About a year and half (and hundreds of OpenID logins) later, I decided that I didn’t want to maintain two sites. I polled my friends, and decided to migrate away from will.norris.name. It was a very manual process of updating my various online profiles, and presented even more challenges with OpenID. But like my transition from wirewater.org I had done several years earlier, I didn’t worry too much about because the extra domain wasn’t really costing me that much.

That all changed this year when it was announced that FreeYourID was shutting down after just two years of operation, and that all accounts would be transitioned over to Key-Systems GmbH. Never mind the fact that the new site to manage your registration is absolutely terrible, the cost for renewal was also raised to 23.39 € (about $35). And unlike my previous .org registration, hours of searching and phone calls have not revealed any way to transfer a third-level .name to a different registrar (in fact, most registrars won’t even transfer second-level .name domains). My domain was scheduled to expire in a few weeks, and I would have liked to just let it go so I don’t have to spend the $35, but there’s a little problem…

OpenID and Reusable Identifiers

I started the process of updating my OpenID on sites a year ago, but I’ve still identified three relying parties that do not support changing your OpenID (at least not that I can find): Disqus, Clickpass, and Pibb. I’m certain there are many more, but these are the only ones that I know I have accounts with, and are currently set to use will.norris.name. So if I let my domain expire, and someone else buys it, they can immediately login to my account at these three services. This is the way OpenID is designed to work… whoever controls the domain is able to authenticate as that URL. So what does this mean for me? Quite simply, it means that if I want to make sure that no one else is able to access my account on any of these three services, I’m forced to pay $35 to renew a domain I don’t use and don’t want.

Who’s to blame for this? Well, I could blame Key-Systems for tripling the price of .name accounts when they took over the FreeYourId service. I could blame myself for having bought the domain in the first place, instead of just sticking with the .com I already had. I could blame the services listed above for not supporting OpenID changes on accounts. And I could blame the OpenID protocol itself for keying on reusable identifiers, instead of using those as aliases to unique, non-reusable identifiers like XRI has been architected to do from the very beginning. All of these would be fair parties to place the blame on, but this post isn’t about placing blame. Instead, this post is about getting the technologists developing and deploying this stuff to start thinking through the entire account lifecycle.

Identifiers Change

We’re living in a world where the identifiers we use to refer to people online are more important than ever. From IRC nicks to email addresses to Twitter handles. These monikers are typically all that identifies us within a particular service context, and sometimes between contexts. This is particularly true of Twitter handles, which in recent years have come to be seen by some as the de facto namespace for people. I was more than a little upset when my former employer (a company focused on OpenID, no less) linked to my Twitter profile instead of my personal homepage when they announced my hiring. And again this year at WordCamp Portland, it was disheartening to discover that the attendee name badges had a place for your Twitter handle, but not for your blog URL. At a WordCamp! The emphasis on our identifiers on these services makes it increasingly difficult to change your identifier without breaking things. But the fact is, identifiers do change. As our online and offline worlds collide, more and more people are moving away from pseudonyms toward using real identities online (something Facebook had the forethought to require from the very beginning). While this is of course a personal decision, it’s one that Chris Messina recently undertook. Similarly, Tom Coates and Ben Metcalfe, two individuals who understand online identity and social media very well, have considered doing the same.

I guess my point is just this. Identity is important. And identifiers change. So we need to be ready for that as we continue to build the “social web”.