Somehow I got subscribed to a $4.99 per year program on GoDaddy that is impossible to turn off. I seriously suspect that there are actually no commands on their website to turn it off. When I ask their support people to do it, they point to the Terms of Service that apparently gives them the right to continue to charge me for a service that I never used, don't want and have explicitly told them to unsubscribe me from, several times. In writing. They refuse to do it.

So it looks like I need to finally cut the cord with them. Unfortunately I have registered a lot of domains with them. I will move them to another serivce and just close the account. It seems that should get rid of the auto-renewing service that I don't want. Yes? I am that foolish. I will spend several days of my life as a matter of principle to get rid of a nasty vendor that has no sense of honor, and is willing to risk an account that pays them several hundred dollars a year for a benefit of $4.99, and the possibility that they get in trouble for stealing money from customers. That should get them in a lot of trouble. Imho.

I'm so sick of companies whose systems screw their customers automatically, always erring in their favor (so forget about it not being intentional). They make it impossibly hard to opt-out and figure you'll just go ahead letting them take the money from your account because it isn't worth your time to actually get rid of them.

PS: If there were a corporate death penalty, I'd vote for GoDaddy getting it.

PPS: I sent a link to this blog post to the "people" at GoDaddy I'm theoretically emailing with. They never give you a name, and their responses are clearly from a database. So to think I'm conversing with an actual person is wildly optimistic.

PPPS: After I sent a link to this post, they cancelled the subscription. They also apologized "for any inconvenience this might have caused." That's all they'll ever cop to, inconvenience. A more responsible apology would be: Sorry about all the money we took out of your account while you weren't watching.

PPPPS: I wrote a checklist for transferring domains from GoDaddy to Hover.com.

 10/26/2011; 11:50:10 AM.   .

It was really interesting to read the followup from Brent's post about synchronizing the user interface of RSS reading apps. Comments appeared on a bunch of blogs, and it's a fresh group of people, which is good to see.

To be clear, I have developed a river-of-news RSS reader that's based on the same idea in the original aggregators I wrote, dating back to 1999. Only now the user interface is a jQuery app written by a community of developers who are fluent in this new environment. In my talk yesterday with Anderson of Couchbase, I got a much better idea of the variety of ways jQuery is being used.

There's absolutely no doubt that the technology Brent was writing about was a blind alley. RSS has always been a great basis for a web app. I don't think it should be a desktop app. Brent illustrates that so clearly. That means there's a tradeoff, offline reading would work differently if you're using a web app for RSS. And that could be handled by the web browser. A simple function that says suck down all the pages linked to from my river and put them in the cache. I'm about to unplug. I don't see how the problem is any more complicated than that. (And I'd be surprised if this doesn't already exist in some browsers, and is on its way for the rest.)

What we do need, however are two very important features that are easily provided, without requiring the creation of any new computer science.

1. A central place to subscribe. This is why Twitter and Facebook beat RSS in simplicity. Because managing your subscriptions is a mess in RSS. To follow someone in Twitter means just clicking a button. It can be that easy in RSS. It just means that the developers have to give up control of the subscription list. Let that be something the user stores elsewhere, that you reference, and can write to, but do not own.

How to develop that? I propose that a university or group of universities develop and run this system. If there's a consensus among developers, I have good contacts now, and can make more. Especially if I can show that there's a consensus among developers to cooperate. This is the kind of project that students can and should work on, imho.

2. Really simple notification. RSS 2.0 provides for notification with the cloud element. I have built on this in my aggregator and content tools. It's the kind of thing that needs to be provided by many vendors. So far WordPress has supported it. We need to do better. To be clear, there are no patents on anything in the RSS 2.0 spec, including this feature.

My goal is to create an open and distributed equivalent of Twitter that runs on lots of people's servers, and give up none of the ease-of-use and maybe just a bit of performance (there are some advantages of centralization). I don't want anything from Google at this time. But I do want to provide incentives to them to support open formats and protocols in a cooperative way in the future. I don't ever want to be in a position where to participate in a community you have to support an undocumented API that's implemented by a single vendor. I'm sure by now we all understand why that is too fragile a foundation to build on.

 10/26/2011; 11:15:16 AM.   .