Bb RealTech

If we've learned one thing from this week's massive attack against the very fabric of our social connectivity, it's that clouds don't make the best stuff on which to build.

Twitter, in particular, has shown how very vulnerable it is—a vulnerability we share as we become more dependent on Twitter for most of our communication with each other. Oddly enough, I needed to contact someone about a business opportunity just as Twitter universe began to crumble, but all I had was her Twitter name—I couldn't find her email address. Since Twitter was down, I couldn't connect up with her for hours.

Of course, massive DDoS isn't all that common, but Twitter still hasn't recovered from the attack. As I've been playing with new Twitter accounts this week, I found varying degrees of responsiveness across the accounts, probably based on how busy they are; possibly based on how many followers a person has. None of the accounts would allow me to change most profile information, including the design. As you can see with my new integrated @shelleypowers Twitter account, I haven't been able to change the picture, or to delete or add a new background image. I've had varying success with just posting a new message.

I have never liked centralized systems, though I understand their appeal and worth. It always seems, though, that just when you start to depend on the centralized service something happens to it.

Yahoo is now out of the search engine business, and with its new business partnership with Microsoft, its side applications like delicious are now vulnerable. I've managed to replace delicious with Scuttle, though I no longer have the social aspect of delicious. However, my Scuttle implementation does an excellent job with bookmarks, which is what I needed.

What can possibly top Twitter and its immediacy, as well as brevity of contact? I think we found out this week, with Google Wave. Tim O'Reilly describes it as what email would be like if invented today. My first reaction, and judging from other responses, is that it's remarkably similar to Ray Ozzie's Groove, before Groove became little more than a ghost appendage to Microsoft.

Folks immediately started rumbling about "twitter killer", but I look at it and see the answer to the question, "What can beat out 140 characters?" The answer is, evidently, echoed keystrokes as people make them.

I watched the presentation video (thank you for that, Google). Technologically, Google Wave is intriguing. What was also intriguing was Google's strong emphasis on HTML5 during the presentation, including a reference to additions to the HTML5 spec. But the part that caught my attention is that Wave is actually echoing keystrokes. I can imagine the following discussion, happening live:

A: I just saw the demo of Google Wave ...

B: Oh, yeah, that was terrific

A:....and it sucked

B: Oh, um, well I thought...

A: You liked it! Are you...

B: ...it was innovative

A: ...cracked?

Google Wave is ADD heroin.

I was thinking about Google Wave yesterday, as I ran the gauntlet that is known as Watson Street, here in St. Louis. As I dodged little old ladies who pull into the road without looking, and the 30 something guy who cut me off when he should have yielded, or contemplated the new ding in my car from some mother's precious child opening his or her car door too hard, and too wide, I began to appreciate what Twitter, Google Wave, Blogging, Facebook, and other social media are: real life alternative communities.

Because in real life, we're all pricks.

I've now used Twitter seriously for a month or two. I've enjoyed chatting with friends, and experiencing an application that brings genuine enjoyment to people I like, and admire. I can also now see the utility of the tool, especially for those who don't communicate frequently online, as it gives us a way to keep in touch and stay informed. But in the last week, I've grown less interested in using the application.

One reason for my growing lack of enthusiasm for Twitter is posts disappearing—a relatively frequent event that has happened to a lot of people this week. Given how taxed the application is, problems of this nature are not surprising. What is surprising, though, is how indifferent most people seemed to be about the whole thing. Perhaps I'm old fashioned but one fact I've learned over the years in developing applications is that the data is sacrosanct. That the loss of "tweets" is no big thing to folks tells me that a) the underlying application has problems more profound then just being able to access the service, and b) that people don't really seem to value what they post on the service. That last one is particularly confusing: if the people don't value what they post, then why spend so much time using the tool?

Another reason I'm thinking of using it less is that I can't keep up with the posts. By Twitter standards, I'm practically a loner, but I find the amount of news and information to be overwhelming. Before this week, if I wanted to catch up with specific people, I would just go to their Twitter page. However, with Twitter dropping posts, I'm most likely going to miss half of what they said, anyway.

Then there's the whole "mean" thing. I guess I'm "mean" or sarcastic with too many of my postings. The problem is, you can easily write upbeat, positive, and wonderful things within 140 characters, but the same can not be said about criticism. Not all of us have mastered the art of Twitter snark.

None of this would matter, though, if it weren't for my lack of comfort with Twitter. I cannot get over that feeling of being the person at the party who drinks too much and says the wrong thing at the wrong time; or puts on the lamp shade and dances around wearing nothing but socks and strategically placed jello shots. Frankly, I don't think everyone is cut out for Twitter.

Remember the scene in the movie Pretty Woman, when Edward Lewis (played by Richard Gere) takes Vivian (played by Julia Robertson) to the Opera? Just before the curtain goes up, Edward tells Vivian, People's reactions to opera the first time they see it is very dramatic; they either love it or they hate it. If they love it, they will always love it. If they don't, they may learn to appreciate it, but it will never become part of their soul. Well, I hated Twitter when I first saw it.

I have been focused on OpenID implementations lately, specifically in WordPress and Drupal. The Drupal effort is for my own sites.

Until this weekend, I had turned off new user registration at my Drupal sites, because I get too many junk user registrations. However, to incorporate OpenID into a Drupal site, you have to allow users to register themselves, regardless of whether they use OpenID or not.

I think this all or nothing approach actually limits the incorporation of OpenID within a Drupal site. If you limit registration to administrator's only, then people can't use their OpenIDs unless the administrator gets involved. If you allow people to self-register, there's nothing to stop the spammy registrations.

I believe that OpenID should be an added, optional field attached to the comment form, allowing one to attach one's OpenID directly to a comment, which then creates a limited user account within the site specifically for the purposes of commenting. Rather than just providing options to allow a user to register themselves, or not, add another set of options specific to OpenID, and allow us to filter new registrations based on the use of OpenID.

Currently the new user registration options in Drupal 6x are:

• Only site administrators can create new user accounts.
• Visitors can create accounts and no administrator approval is required.
• Visitors can create accounts but administrator approval is required.

Turn on the latter two options and you'll get spammy registrations within a day. Not many, but annoying. I believe there should be a fourth and fifth option:

• Visitors can create accounts using OpenID, only, and no administrator approval is required.
• Visitors can create accounts using OpenID, only, but administrator approval is required.

With these new options, I could then open up new user registration for OpenID, but without having to allow generic new user registration for the account spammers that seem to be so prevalent with Drupal.

To attempt to implement this customized functionality at my sites, I've been playing with Drupal hooks, but the change is a little more extensive than just incorporating a hook handler and a few lines of code, at least for someone who is relatively new to Drupal module development like I am.

Taking the simplest route that I could implement as a stand alone module, what I'm trying now is to modify the new user registration forms so that only the OpenID registration links display. You'll see this, currently, in the sidebar if you access the site and you're not logged in. Unfortunately, you have to click on the OpenID link to open the OpenID field, because I'm still trying to figure out how to remove the OpenID JavaScript that hides the field (there is a function to easily add a JavaScript library, but not one to remove an added library).

With my module-based modifications, rather than a person having to click a link to create a new account, and specify a username and password, they would provide their OpenID, and I would automatically assign them a username via autoregistration. To try my new sidebar module, I decided to turn my Durpal sites into OpenID providers, as well as clients, and use one of them as a test case. Provider functionality is not built in, but there is an OpenID provider module, which I downloaded and activated with my test Drupal installation (MissouriGreen).

I tried my new module and OpenID autoregistration, but ran into a problem: the Drupal client does not like either the username or email provided via the Drupal OpenID provider. Why? Because the OpenID identifier used in the registration consists of the URL of the Provider, which is the URL of the Drupal site I used for my test, and the Drupal client does not like my using a URL. In addition, the provider also didn't provide an email address.

Uploaded with plasq's Skitch!

Digging into the client side code, I discovered that the Drupal OpenID client supports an OpenID extension, Simple Registration. Simple Registration provides for an exchange of the 9 most requested information between the OpenID client and provider: nickname, email, fullname, dob (date of birth), gender, postcode, country, language, and timezone. With Simple Registration you can specify which of the items is optional and which mandatory, and the current OpenID client wants nickname and email.

By using Simple Registration on the provider, I could then provide the two things that my Drupal OpenID client wanted: nickname and email. Unfortunately, though, the current version of the OpenID provider doesn't support Simple Registration. I was a little surprised by this, as I had made an assumption that the Drupal OpenID provider would work with the Drupal OpenID client. However, OpenID is in a state of flux, so such gaps are to be expected.

Further search among the Drupal Modules turned up another module, the Drupal Simple Registration module, which allows one to set the mandatory and optional fields passed as part of the OpenID authentication exchange. The only problem is that the OpenID Provider also doesn't have any incorporated hooks, which would allow the Simple Registration module to provide the Simple Registration data as part of the response. To add these hooks, the Simple Registration module developer also supplied a patch that can be run against the OpenID Provider code to add the hook.

I applied the patch and opened the module code and confirmed that it had been modified to incorporate the hook. I then tried using the Drupal site as OpenID provider again, but the registration process still failed. Further tests showed that the Simple Registration data still was not being sent.

All I really want to do is test the autoregistration process, so I abandoned the Drupal OpenID provider, and decided to try out some other providers. However, I had no success with either my Yahoo account or my Google GMail account, even though I believed both provided this functionality. The Yahoo account either didn't send the Simple Registration fields, or failed to do so in a manner that the Drupal OpenID client could understand. The Gmail account just failed, completely, with no error message specifying why it failed.

I felt like Barbie: OpenID is hard!

I finally decided to use phpMyID, which is a dirt simple, single user OpenID application that we can host, ourselves. I had this installed at one time, pulled it, and have now re-installed at my base burningbird.net root directory. I added the autodiscovery tags to my main web page, and uncommented the lines in the MyID.config.php file for the nickname, fullname, and email Simple Registration fields. I then tried "http://burningbird.net" for OpenID autoregistration at RealTech. Eureka! Success.

The new user registration is still currently blocked at creation, but the site now supports autoregistration via OpenID. Unfortunately, though, the registration spammers can still access the full account creation page, so I can still get spammy registrations. However, I believe that this page can be blocked in my mandatory OpenID module, with a little additional work; at least until I can see about possibly creating a module that actually does add the OpenID only options I mentioned above. The people who generate spammy user account registrations could use OpenID themselves, but the process is much more complex, and a lot more controlled at the provider end point, so I think this will help me filter out all but the most determined spammy registraters.

Once all of this is working, I'll see about adding the OpenID login field to the comment form, rather than in the sidebar. If one wonders, though, why there isn't more use of OpenID, one doesn't have to search far to find the answers. Luckily for Drupal users, OpenID seems to be an important focus of this week's DrupalCon in Washington DC, including a specialized Code Sprint.

I was reading posts and comments at Mathew Ingram's weblog, when I ran into a comment where the person referenced "Google haters", and I stopped reading the comment at that point. I no longer cared to read what the person had to say.

I have developed an intense dislike, loathing really, of the term "hater". It's little different than the term "hysterical" when applied to women commenters in order to demean the person or persons referenced, rather than views, attitudes, writings, or other work. It's a lazy noun by lazy people who don't want to take the time to write about why they agree or disagree with what the person is saying—just use the word "hater" and that should be sufficient. And quick, too.

I feel towards "hater" about the way I feel towards moonbat, wingnut, or any of the other terms used by indifferent writers incapable of writing a detailed, thoughtful criticism or disagreement. These writers don't have time to spend on their arguments, because they're too busy looking for the next hater, moonbat, or wingnut to vilify. My suggestion to them is to pick their targets and write well, rather than quickly. Don't use epithets like shotgun pellets, firing haters, wingnuts, or moonbats hither and yon in an effort to blanket as many people as possible. This approach might net them a bigger following, but of what kind of people? The barely literate xenophobe?

...