Seems to me that there is a DNS issue at play here in that if your browser requests a fresh IP resolution, it works, but the IP addresses fail. If your browser has an IP address cached it seems you're fine.

Reports:

• Summize, which is a live Twitter search engine: Search for [google down].
• Over at Cre8asite Forums, there is a discussion thread.

Anyone else seeing this?

There are two ways it breaks:

• Eternally looping on the loading progress bar. What happens is that it keeps refreshing the loading page and never making it to the email list.
• Mostly on Opera, it just returns to the login page although the username and password are correct; it doesn't show any error messages.

I've learned to be very quick at clicking the the simple HTML view link, but even with all the practice sometimes even that doesn't work.

Anyone else seeing this?

A few days into this exodus of sorts, Brian asked who was still around on twitter, and I replied that I didn't like it so was still around. Surprised, Brian suggested I give Plurk a second chance and so I agreed. Plurk got a second look, and I promised Brian a review. This is the review.

In short: it's bad, and not only that, I think they won't make it as a company with the product with its current interface. Here is why.

What is Plurk?

Plurk is a service for engaging in conversations with other people. It is centered around a timeline, a very cool looking scrolling interface that maps conversations as points on the timeline. The conversations start with someone posting some text and the replies come in attached to the original reply. A screenshot is below:

The timeline's 'now' is at the left, and the past is going to the right. When you're browsing past conversations, you scroll left to go to later ('future') posts. At first pass, this is very counter-intuitive: for some reason I expect the future to be to the right and you go back in time by scrolling left - i.e., the reverse of the Plurk arrangement. I've seen other comments along those lines but I can't for the life of me find them. However, this is the best arrangement for a timeline written in English, and Plurk either are genius designers or extremely lucky people. Why? English is written left to right and so as you scroll the first thing you see of a new conversation is the starter's name and the first few words in the sentence of the conversation. If you were scrolling right to left, you would actually see the last few words in the conversation's start's sentence. The Plurk arrangement works much better.

The conversations themselves are shown as little rectangles. You click on the rectangle and it expands to show the full conversation and replies. The layout is a forum thread layout with avatars, usernames, time stamps, and icons. The rectangles are placed along the time line in relation to when the started, and plotted at randomly in the vertical position.

Plurk also has karma, that eternal currency of Web 2.0. The more you use Plurk (start conversations) and the more people you invite, the more karma you get. And the more karma you have the more icons you get. However, if you don't use Plurk for a day, the karma starts dropping. I peaked at 20+ karma about 2 weeks ago and now I'm under 8 karma. It's an interesting twist to an age-old way to foster user engagement.

Why is Plurk Bad?

Plurk is a bad service because the timeline arrangement is the worst implementation to show conversations. There is absolutely no need to have conversations plotted in a timeline. A simpler listing (the extreme of which is a forum-index type of listing) would do much better. Right now, the timeline mars the usability relating to the fact that Plurk is about conversations and not microblogging like Twitter is. It's a gimmick and an annoying one for that.

To know just how annoying this is, try not going to Plurk for a few days and come back. Heck, go to sleep and check it in the morning: you'll have dozens of conversations that have either been started or updated and you can't just seem them and quickly browse them. No, you have to scroll, click each one to expand it, and then read. And there isn't any obvious way to see which conversations were ones you engaged in previously to see if there are any new replies. Nope, they're all lumped together. Raise your hand if you simply just gave up and marked all conversations as read because you just can't be bothered.

And what's with the karma loss? Listen, I try to have a life outside the internet and certainly won't center my life around Plurk. If I don't visit for a day or two, I should not feel like I'm being punished. This is the first time I see anyone implement a karma loss over time idea. Karma should only be deducted if other members of the community feel that way, and even then, it should be implemented carefully - there is no easy answer for this question, but Plurk's implementation is definitely wrong.

Finally, a pet peeve from a marketing point of view: I get an email every time someone wants to follow me so that I can authorize them. Ummm, I love it for people to follow me and they shouldn't ask permission. They should come and go as they please. Twitter called it spot on: people follow you and stop following without intervention, but there are two options: you can lock your conversations or you can use direct messages which are private. That covers pretty much all shades of having an open to private conversation. Having a single blanket permission system by default is weird.

So all in all, a very crappy implementation of a potentially good idea. I've written it off for now but I'm sure my network of friends on Twitter and elsewhere will let me know if things improve or not.

So, pray do tell us Pierre, where would you come up with such a silly name? Why I'm glad you asked. It's the service that's been spamming me blog for the past few months, hosted at the one and only ectio dot us. See, them scrapers have a serious claim: "Find something to read, guaranteed!" I believe them given all the scraping they're doing.

And thus because I am in the mood to return them the favo(u)r, I hereby declare them the prototypical scraposphere service. Beat that!

• Plurk, which is Twitter on steroids, jam packed with fun conversations. A full review is coming soon. Please note that I blame Brian Wallace from NowSourcing for my enjoyment of Plurk.
• friendfeed. I still need to dive into ff deeper but it seems very cool so far. In particular, the Social Media room is interesting...

So if you're a user of any of those services, join me

The first hit I've seen was on April 27th, which came from the IP address 216.39.58.78. Back then, that resolved to htproxy3.ops.re4.yahoo.net. However, ever since, the hits are all from a different C-block, 209.131.41.*, which resolves variously to, htproxyX.ops.sp1.yahoo.net (X is a number like 1 or 2 to give htproxy1.ops.sp1.yahoo.net or htproxy2.ops.sp1.yahoo.net). Even more recently, the IP addresses remained the same, but the hosts they resolve to changed to htproxyX.ops.re4.yahoo.net (again, X is a number to give htproxy1.ops.re4.yahoo.net or htproxy2.ops.re4.yahoo.net).

I post about this bot for one simple reason: the UA is very intriguing and the fact that it's requesting just RSS XML feeds is also interesting. Are we going to see a Yahoo! service or a set of services that deal with just blogs?

TechCrunch reported way back in 2005 about the launch of Yahoo! blog Search, which back then and today has pointed to what Yahoo! calls the News Search, which according to the web page is to "Search real-time news stories from Yahoo! News and across the web." That's fine and dandy, but it's no blog search per se.

So the YahooCacheSystem bot could represent one of two things:

• Yahoo! is consolidating its backend infrastructure to deal with RSS-based sites better. So they are building a centralized RSS cache for all their services to use. For webmasters, this means we now have a new analytics data point we can look at.
• Or... (wait, I need peer at my crystal ball...) Yahoo! is moving towards building a serious set of services centred around XML feeds. This could mean we could see a true blog search product soon, or something else we can only guess at.

So which one is it? I can only provide guesses. Given the utter lack of evidence and, more importantly, rumors, I'm leaning towards the infrastructure explanation. However, a good infrastructure is necessary for a major strategic shift or product launch. Time will tell.

So come on, Googs, help him out.

Case in point, this hit from today over at Social Alerter:

Is it just me or is this beyond comical now?

Is this a bug or account specific? Each of the reports I see are different.

I just had an "OMG this will change the world!" kind of moment while playing for just 5 minutes with Google's App Engine. Let me explain.

A bit of background first: The Google App Engine is a newly-launched service from Google, that for a change, seems to be well thought out. The service offers a Python-only environment (for now) to build applications locally and host them on Google's vast infrastructure. The idea here is that you don't have to worry about scaling your application to handle massive traffic and let the App Engine running on Google's servers deal with it. The Engine comes with lots of goodies like handling database stuff, user logins (and what a boon that will be for Google accounts), and others. All in all, a nice comfy environment for rapid application development and reliable hosting.

But from all the buzz on the net, I think there is something missing that I just hinted at above:

to build applications locally and host them on Google's vast infrastructure

App Engine comes with its own development setup that runs off your computer (available for Windows, OSX, and Linux). You develop the application on your computer, run it, test it, add features, and then upload it to Google's computers. My question is this: What's stopping Google from turning the local development code into a full desktop-based runtime for web applications? Why keep it as a development-only environment?

Let's look at this from another angle: the desktop-webapp integration market. Adobe recently released their oddly-named AIR (Adobe Integrated Runtime). In the AIR-world, you can write applications in HTML/CSS/JS or Actionscript and package them into desktop applications that run within AIR or within the Flash player in the browser. The AIR environment is available for Windows and Macs, and Linux support is on the way. Brilliant move: one code base, both browser and desktop functionality.

Microsoft also has a similar play in the form of .Net, and more specifically Silverlight. The .Net runtime is available for many devices and platforms (mobile, desktop, and I think even the XBox). With Silverlight, Microsoft's play is to give developers a platform to use .Net in the browser; this is coming in Silverlight 2.0 this summer. So with this, again, one code base can be used on the web and on the desktop to give true multi-platform programming.

There are other entries in this market, Mozilla Prism being a prominent example. They all promise the same thing: one code, many places to run it with varying details.

Now back to App Engine and to the question I posed: imagine Google comes out with a desktop runtime/environment that turns App Engine webapps into desktop-based apps. This will be directly parallel to Adobe's AIR but with a big difference: the same code will also be easily deployable on a reliable and scalable infrastructure - Adobe doesn't have that.

There is another difference: because of the way App Engine works, you could easily imagine it talking to Google Apps like Google Docs etc. A desktop App Engine will bring Google's applications onto the desktop and open up a market-disrupting war: direct office productivity competition with Microsoft. To rephrase, App Engine could be Google's way to enter Microsoft's turf on the desktop.

So any evidence for this? Nothing solid, so it's all speculation, but I'll point to three hints:

• The name. It's not App Server or App Service but App Engine. Google understands branding well enough (it's arguably the main source of their traffic) so their choice of words here is intriguing. And I can't help but think that Google's App Engine will drive some sort of Google Gears. Nudge, nudge, wink, wink.
• When creating an application, you can specify that only users of a certain Google Apps domain can use the app. This integration with Google Apps is perhaps hinting at bigger things to come.
• The APIs available in App Engine: already App Engine supports dealing with mail, and given the point above, you can imagine an API for the other Google Apps. This would enable a go for the desktop market.

What do you think? I think this is the best move out of Google yet and as disruptive as AdWords was.