Dodgeball founder pegs Google in the face with Foursquare

Each year, around the time of the SXSW festival people start wondering out loud what the “next Twitter” will be. You see, the quickly spreading micro-messaging service really got its start at the Austin,Texas-based festival two years ago, and has been growing ever since. Of course, last year’s Twitter was, well, Twitter. But this year there may be another service that catches on — if it can get approval in Apple’s App Store.

The service, called Foursquare, may be very familiar to you if you used the service Dodgeball in the past. Dodgeball, was an early location-based social service made popular among the tech elite in the San Francisco Bay Area, that Google bought in 2005. By 2007, its founders became fed up with Google’s neglect of the service they had created and left the company with middle-fingers wagging.

Now, one of those founders, Dennis Crowley, is back with Foursquare. I’ve been testing it out in closed beta for the past week, and I’m happy to report that it’s solid, and has the potential to be addicting.

As I said, it’s very similar to Dodgeball, but with a few key differences. The first is that it has a nice web UI. Dodgeball was mainly used via text-messaging — remember, it was made before smartphones with nice graphics — and so, the web interface didn’t matter much for the service. But now, the mobile web has changed, and so has Crowley’s apparent approach towards it. Not only does the site look nice on a desktop or notebook web browser, its mobile web page looks pretty nice as well.

That said, text messaging is still the preferred means to interact with the service. If you’ve used Dodgeball in the past, you’ll know the syntax, but for Twitter users is may be a little complicated. You see, to “check-in” at a location, you use an “@” symbol, then a space, then the name of the location. If you want to leave a message, after the name of the place, you put in a “!” symbol, followed by a space, then your message.

The “@” is not used to reply to someone as it is on Twitter. And Twitter never intended that to become the standard — the users came up with that — because really it makes no sense. You’re not “at” someone, you’re “at” a place, which is how Dodgeball/Foursquare use it.

The second big difference-maker for Foursquare will be an iPhone application. That’s why I noted that this service could be a surprise hit at SXSW if the app is approved in time. The app is currently waiting for approval, and that could happen “literally any minute,” Crowley tells me. Of course, it has already been rejected by Apple once, because it apparently contained something that Apple didn’t like. Crowley has since corrected and re-submitted.

(As we all know by now, Apple can be pretty picky when it comes to App Store approvals.)

A third difference involves the feature side of the service. While both Foursquare and Dodgeball are about checking in places, Foursquare adds a bit more of a social element by incorporating two features called “Top 12″ and “To Do.” Basically, Top 12 allows each users to list their 12 favorite things to do at various places around their home city. To Do allows users to save items from other users’ Top 12 lists to make sure they do them later. When you do them, you can check them off on the site.

Foursquare keeps track of all of this information, and gives you awards based on doing tasks like completing To Do items, and checking in places. That element is what could lead to this service being a viral hit. And the fact that it’s not trying to displace Twitter, but rather utilize it to help you spread the word about what you’re doing, should definitely help as well.

The reason why this service could be big at SXSW is that first of all, all of the tech early adopters will be there. Many of them used and loved Dodgeball up until Google officially killed it last week. Another reason is that like Dodgeball, Foursquare is based around cities, and yes, Austin is one of them (as is San Francisco, New York and other hot spots).

Let’s say I go somewhere in Austin next week and I want to see who else is at the same place. Sure, I could do a Twitter search, but Foursquare can be set up to automatically ping you when a person you are following checks in somewhere. And with the iPhone app (again, if approved), it will be even easier to see which of your friends are around you and to check in places with the use of GPS.

With the moves Google is attempting to make in becoming more social — especially its recent emphasis on location-based social aspects with services like Latitude — it was never really clear why Google bought Dodgeball only to let it die. You’d think it could have been a great centerpiece of Android, instead, it became yet another neglected Google acquisition.

Crowley asked that I not use any screenshots of the service until the iPhone app goes live, and it officially launches. As I said, this should be any second now depending on how picky Apple is going to be.

I hope to see some of you in Austin on Foursquare.

UpdateThe Foursquare iPhone app just became available tonight. I have been using it a bit, seems very solid.

SSH-Agent Forwarding and GNU Screen

GNU Screen and OpenSSH are two incredibly useful tools. In this tutorial, I hope to help users to work around a small, but annoying, problem that can arise when using SSH-Agent forwarding and Screen. This tutorial assumes you have knowledge of SSH, SSH-Agent, SSH-Agent-forwarding and GNU Screen. I also assume you’re using a shell that can handle Bourne shell variable syntax.

The Problem

SSH-Agent forwarding breaks when screen is re-attached on a different host.


The problem involves three hosts*, A, B, and S. All of these hosts have Agent-Forwarding enabled in their SSH configuration.

I log into host A and run ssh-agent, authenticating to my key. I connect from machine A to machine S using my agent/key to authenticate. On machine S, I start screen. I open several screen windows, all running shells. These shells inherit the ssh-agent variables from the parent shell that spawned the screen. (This is where the problem starts.)

I notice that it’s time for work, so I drive to work and log into machine B, starting ssh-agent and authenticate to my key. I connect from machine B to machine S using my agent/key to authenticate. I resume the running screen that I started when logged in from machine A. Naturally, all of the ssh environment variables are still set the way they were prior to the screen de/re-attach. So now, despite having ssh-agent forwarding turned on and having an active agent, I can’t connect to remote hosts via host S without some kind of magic.

*This problem could also involve two connections from the same host (which will be on different client ports,) to a second host. I think the above example is clearer.

SSH Environment Variables

When you connect, using ssh-agent for authentication, to a host that has ssh-agent forwarding enabled, the following shell variables will be set:

SSH_CLIENT= 4671 22

The SSH_CLIENT variable contains three space-separated pieces of information. The IP address of the client making the connection, the client’s port number, and the server’s port number.

The SSH_TTY variable is set to the path to the tty device used for the shell opened when the SSH connection was created.

The SSH_AUTH_SOCK variable identifies the path of a unix-domain socket used to communicate with the agent. In other words, this variable sets up a “path” back to the host that is actually running the agent, so that future ssh connections can talk to/use that agent.

The SSH_CONNECTION variable contains four space-separated pieces of information. The IP address of the client, the port number of the client, the IP address of the server and the port number of the
server. This variable is necessary to prevent agent hijacking.

So, now that I’ve reiterated the ssh(1) man page, we can see why, when we connect from A to S, and then from B to S, ssh-agent forwarding fails. In the initial connection, S defines the SSH environment variables to point to host A. When screen starts its shells, they inherit those variables. When host B connects and grabs that instance of screen, the sub-shells have no idea that anything has changed, so the variables now point to the “wrong” machine.

The Solution

The environment variables listed above are set correctly when host B connects to host S, so we need a way to get them propagated to the shells running inside screen. I wrote a small script to cull them out and stick them in a file. The script also re-formats them so that they will be easily integrated into the shell’s environment. I called this script “grabssh.”


for x in ${SSHV} ; do
    (eval echo $x=\$$x) | sed  's/=/="/
                                s/^/export /'
done 1>$HOME/bin/fixssh

The output of this script looks something like this:

export SSH_CLIENT=" 4685 22"
export SSH_TTY="/dev/pts/22"
export SSH_AUTH_SOCK="/tmp/ssh-jtF17289/agent.17289"
export SSH_CONNECTION=" 4685 22"

Rather than having to type in “grabssh” before resuming any screen, I created an alias:

alias Attach='grabssh ; screen -d -R'

So now every time I resume my screen, the correct ssh-agent variables will be written to ${HOME}/bin/fixssh. I wrote another alias to source that file:

alias fixssh='source $HOME/bin/fixssh'

Now, when I’m in a screen-spawned shell and I want to take advantage of ssh-agent forwarding, I run “fixssh” and everything just works. You might even go so far as to create an alias for ssh like this:

alias ssh='fixssh; ssh'

However, that alias might someday drive you insane if you’re troubleshooting some ssh problem and you forget that it is there.

If you’re an EMACS user, you’ll likely find Mike Prentice’s addendum to this article helpful. Thanks, Mike!

Special thanks to Sam Rowe for the original article.