Identity : Anonymity :: Community : Network (?)

Standard

There’s been a fair amount of discussion around Google’s “real names” policy on Google+ in certain circles. Most recently in my stream, Fred Wilson pointed to Corey Doctorow’s post on the topic, and the discussion around that post crystallized some of what I’ve been thinking on the issue. To be specific, the crystal is:

The “anonymity vs. real names” debate is in large part a discussion of a very different issue: community vs. network.

Ages ago, in the days before Google+, the discussion tended to revolve around Facebook comments outside of Facebook. “If we implement Facebook comments,” the corporate presentation went, “it will improve the quality of the UGC on our site, because comments will be tied to users’ real identities. If people’s comments are linked to their Facebook profile, they will be respectful of both our content and other’s contributions, because a meaningful degree of accountability has been added to the system.”

The next slide of the powerpoint was inevitably the real money, though, pointing to the awesome traffic potential that came with hitching one’s buggy to the Facebook rocket: “because users can easily share their comments to their Facebook friends,” the presentation would continue, “we make better use of users’ existing social networks in our efforts to build traffic to the site.”

And there’s the rub.

Requiring a fixed external identity online addresses a very real concern, but it’s reactive. It is, in many cases and possibly at best, a response to the ease with which users can find a new-to-them site or service these days. It is, in an unfortunate number of cases, an attempt to shortcut the process of building a community in favor of importing networks, and then trying to preemptively create some order out of the mess that almost inevitably results from that import.

In Google’s case the network import in question was…well, Google’s, but I don’t think that changes the formulation to any meaningful degree: my Google+ circles are just as far removed from my gmail “contacts” list as the squares, lists, scenes, or cadres dreamed up by any unfunded Brooklyn startup.

The issue, in my view, isn’t whether giving users of a service the ability to be “anonymous” to other users of that service is harmful to that service — I maintain that UrbanBaby settled that question nearly a decade ago, in favor of anonymity — but whether an external identity requirement does anything positive at all.

Because so many people now have established identities and communities online, the idea that you can just tap into that pre-existing structure is incredibly seductive: you find one person who’s right for your new service and they bring a whole community with them.

The problem is that the network effect can help expand an established community, but it can’t build one. Drive-by visitors are generally more trouble than they’re worth, as many Dugg and Slashdotted sites will report.

Until people have a reason to take (credit || responsibility) for their activity on your site, you’ll have a real problem with bad apples, anonymous or otherwise. Once people do care, the community will make an effort to take care of problems whether or not they know the “real name” associated with that problem.

My “network” is made up of many different communities, and some of those communities don’t like one another very much. Assuming that pulling that entire, extended network into one central location is a good idea is…well, just not a good idea.

Bonus: any commenters who provide an explication of the “bartender” label that appears on Fred’s AVC comments get a free beer from me at the time and of their choosing (within reason). Bonus points for offering a (probably inaccurate) derivation of the term “86″.

On Making Stuff

Standard

For the past couple of weeks I’ve been spending whatever time I can spare on a little project: building kisttr, a Kickstarter Backer Tracker. It’s a pretty straightforward hack that allows you to “track” (or “follow”, if you prefer) a group of Kickstarter users and see what new projects they’re backing without having to visit each of their profile pages on the site.

As I was putting it together, a part of me couldn’t help but play out a little dialogue:

“So this thing just sends you a daily email that lists the new projects some people are backing on Kickstarter?”

“Yes. Though it does show them on a Web page, too.”

“And you spent two weeks building it?”

“Correct. Late in the evening, mostly.”

“It kind of sounds like a feature, not a product.”

“True. Very true.”

“And it actually kind of sounds like a feature that Kickstarter is likely to release themselves at some point.”

“Agreed.”

All of the points raised above are entirely valid. I fully expect that Kickstarter will sooner or later release an update that makes kisttr obsolete, it’s definitely a feature rather than a product, and it took me an awfully long time to build something that a competent developer could have banged out in a matter of a couple of days.

But to me, all of that is missing the real point.

Kickstarter may well release an equivalent feature, they don’t offer it right now, and I want this right now. Kisttr isn’t as elegant as I’d really like, but it works — and it’s a lot better than not having anything at all.

And while I’m a slow and clumsy programmer, after spending some focused hours designing and building this, I’ve remembered a bunch of tricks that I’d forgotten and learned a few new things, as well. [Amazon's Simple Email Service is kind of neat, I'm an idiot for not making better use of CSS frameworks before, and so on.]

Today I have a better understanding of a few design and development issues than I did two weeks ago, and even though (or maybe because) I’m more of a “product” guy, that’s incredibly valuable.

When it comes down to it, it’s just fun – and wonderfully satisfying — to take a project from a barely articulated idea to reality. Making something that didn’t exist before is a real pleasure — even if what you’re making isn’t that big a deal in the grand scheme of things.

The further I get into this process (it’s still underway, since there are still a number of holes to be patched), the more strongly I believe that I get the real benefit from the process of building kisttr — the end product is just a little bonus.

Anatomy of a Better Twitter Bot

Standard

So you may recall that I put together a Twitter bot for the lyric of the day club a few months ago. You may also recall that I mentioned that my co-conspirator Daryn Nakhuda has the ability to write code that doesn’t, you know, “fail mysteriously and silently” and such.

Well while it’s taken us a while to get there, but Daryn has now rewritten the LOTD bot. While I was on vacation and virtually inaccessible, Twitter disabled the “replies” API call, which meant that the LOTD bot couldn’t access the lyrics that people were posting. And since I was without internet access and had intermittent cell phone coverage, the bot went down and stayed down until Daryn managed to contact me.

After an amusing little incident where I accidentally sent the admin password for the server to hundreds of people, Daryn got coding and wrote LOTD Bot, Mark II. In addition to general improvements, Daryn added one completely awesome feature: now, if the bot can’t get replies from the Twitter API it fails over to do a search on Summize to find new replies to post. Sweet, no? Here are the (slightly updated) requirements and info for LOTD Bot, Mark II:

Requirements
To run a variation of this @lotd script, you must be able to understand Perl well enough to make some basic modifications to the script, and must be able to set up a simple database table (phpMyAdmin is your friend). In addition, you need a server or account at a Web hosting service that:

  • Allows you to set up a (small) database.
  • Allows you to run perl.
  • Has the XML::Simple and LWP::UserAgent perl modules installed, or will allow you to install them.
  • Allows you to run scheduled jobs (i.e. cronjobs)

Overview
It’s a very simple setup: there’s a single perl script running on my server that gets the replies posted to @lotd via the Twitter API (or via a Summize search, if the API call fails), loads them into a database table, and then republishes the posts in the lotd account (again via the API). It’s scheduled to run once every 15 minutes, around the clock. The script uses the XML::Simple and DBI modules, but doesn’t have any other dependencies.

To run your own bot using this script, you’ll need to:

  1. Create the Twitter account that will be the repost bot.
  2. Create a database table as described in the next section.
  3. Update the script below:
    • The DB connect information for your database. (Line 14)
    • The Twitter username/password information for your Twitterbot account (there are “read from” and “write to” values, but they’ll point to the same Twitter account in most cases). (Lines 16 – 20)
    • The regex to remove @YourTwitterBot from replies before it reposts them. (Line 40)
  4. Upload the finished script to your server.
  5. Set up a cron job to periodically run your script (@lotd runs every 15 minutes).

…and that’s pretty much it.

Get the Database Table Structure (MySQL CREATE)
Click the link above, copy and paste, and change the table or field names as seems appropriate.

Get the Example Script
Click the link above, copy and paste, and make the updates noted in the post above. If you change the database table or field names, make sure that you also update the script appropriately.

Gedankenexperiment: Here is the Internet

Standard

A digital native is a person who has grown up with digital technology such as computers, the Internet, mobile phones and MP3. A digital immigrant is an individual who grew up without digital technology and adopted it later. A digital native might refer to their new “camera;” a digital immigrant might refer to their new “digital camera.”

Description of “digital natives,” coinage generally credited to Mark Prensky

The idea of building competitors to Twitter on the same platform, or redistributing Twitter to multiple players reminds me of the idea that New York City should be rebuilt in Ohio because it would be cheaper. Or perhaps we could distribute a little of New York City in every state of the Union. New York City is what it is because of the people who live and visit there. Building another New York City in Las Vegas doesn’t result in the phenomenon that is New York City.

Echovar on decentralizing Twitter

There are roughly three New Yorks. There is, first, the New York of the man or woman who was born here, who takes the city for granted and accepts its size and its turbulence as natural and inevitable. Second, there is the New York of the commuter—the city that is devoured by locusts each day and spat out each night. Third, there is the New York of the person who was born somewhere else and came to New York in quest of something. [...] Commuters give the city its tidal restlessness; natives give it solidity and continuity; but the settlers give it passion.*

E.B. White, Here is New York (1948)

It took a week or so for these three things to snap together in my head, but when they did I was surprised how beautifully and accurately E.B. White described the population of the Internet.

I consider myself, and many of the people that I know, settlers: we have chosen to live a part of our lives online, and building online is important to us. Commuters have long since arrived—people who come online for work, or to do a little shopping, or in search of entertainment, but for whom the Internet is simply an interesting, useful, nice place to visit.

I’m not certain that there are yet many, if any, true natives, but I’m looking forward to seeing the (to me) strange changes engendered by people who can take the physical and metaphorical connectedness of the Internet for granted as a part of their daily lives.

* Personal note: my parents (both originally from the Midwest) moved to New York in 1968, and I was born in 1971. When I first read this passage, years ago now, I finally started to understand how my parents’ New York was different from my own—and that New York was important to them in a way that I think I can never entirely understand.