Branch and the Pillars of Social Orthodoxy


Stowe Boyd posted some thoughts on Medium this morning, which included this:

I submit that this early version of Medium is a speculative design intended to challenge us to consider implications of the deep philosophy lurking within, rather than the test of a fully fleshed minimally-viable-product.

It’s interesting to consider the philisophical implications of a product, but I think it’s more interesting to consider the implications of the existence of a product that’s intended to make us consider the philosophical implications of that product. [My theory: it’s early adopters, all the way down.]

But the actual point is that Mr. Boyd reminded me that I have recently been thinking about the philosophical implications of a product: Branch.

I haven’t yet gotten my Branch invitation so take my opinion for what it’s worth, but from what I can see it looks like Branch is breaking with the mainstream philosophy of the “social” web in some interesting ways.

When you look at the social web that has developed in the past five or so years, a rough orthodoxy has been established.

First, in the context of a given service, you “follow” other users that service. There’s a bit of a schism around asymetric vs. symetric following (Twitter or Foursquare model?), but the overarching concept of following — which was relatively new and still a little weird in 2007, mind — is the standard. Even services that started without it (think Disqus, Kickstarter) have moved towards accepting the follow as a core social mechanism.

The second pillar of orthodoxy is the completeness of these follow relationships. When you follow another user of the service, you get everything they put into it. You can’t get just the graffiti pictures that I post to Instagram and not the ones of my kids, nor can you see my music posts in your Tumblr dashboard and not all the other crap: you get the whole person, all the time.

And the final pillar (closely related to the second) is persistence: once you have followed another user of the service they stay followed until you actively remove them. While you are establishing relationships in the context of the service, they are not relationships that require active maintenance. I may never like, heart, star, or otherwise validate your presence on the service, but that doesn’t matter: having stated my interest in you once, I need do nothing else.

So how does this relate to Branch?

Well, Branch is obviously a very social service: you’re asking a group of people to have a discussion on a particular topic. You’re indicating to those people that you’re interested in them and that you value their opinions, which is a key part of most healthy relationships, on or offline. And the discussion itself is visible to a much larger universe: because invitation is required, participation in a Branch discussion is making your relationships visible.

But to accomplish this very social undertaking, Branch is almost completely ignoring the established conventions of the social game. The conversations themselves are put at the center, rather than the participants.

You don’t follow other users, you ask them (or are asked) to participate in a specific discussion. The relationship being created is very focused and explicitly bounded. You don’t have to read the other Branch discussions that someone has participated in, nor they yours. And the relationship has no persistence at all: each new conversation requires a new set of invitations, an explicit renewal.

It’s difficult for me to come up with a more contrarian approach to a social service, but it could actually work. For all the people complaining about social overload and trying to build tools to manage it, very few are doing anything that’s really different. Path limits the number of people involved, but adheres to the social orthodoxy. People build tools to filter, mine, timeshift, spindle, fold, and mutilate your social streams, but they rarely question the principles underlying the construction of those streams.

I could be wrong, but I think that the Branch folks are building something that’s legitimately a part of the social web, but proposing an alternative to the current model. Branch seems very different from Tumblr, or Quora, or Twitter, but I’m not sure that’s a problem. This could get very interesting.

By Request: Flickr and the Instagram That Wasn’t


I recently asked on Tumblr whether there were any topics that people would like me to write about, and I received a number of interesting suggestions. Here’s the first:

highleverageinning said:

Flickr next. No joke. How to fix etc.

I’m taking this one on first both because it’s timely and because it’s relatively easy for me to address:

I’m the wrong person to ask.

Despite being a longtime Flickr Pro user, and (probably) holding the distinction of having the oldest unopened Flickr welcome message in existence [see below, unopened since December 16, 2004], I’m not really much of a Flickr user. I’m not a photographer, and I basically use Flickr as a convenient dumping ground that lets me visually scan my own pictures easily. While community is key to many people’s experience of Flickr, I’ve never felt part of a community there.

I genuinely have no idea what Flickr should do.

See? Short, easy answer.

But the catch, of course, is that I have some thoughts on what Flickr shouldn’t do. Or to be more precise, I have one thought on what Flickr shouldn’t do: Flickr shouldn’t try to build a better Instagram.

Yes, Flickr probably should have built Instagram before Instagram built Instagram. But it didn’t happen. Don’t try to play catch up. Flickr needs to  focus on fixing the problems that kept them from building the last Instagram before they have a shot at building the next one.

I note this because I read Mat Honan’s Flickr’s Engagement Problem May Be Too Big for Even Marissa Mayer. Which you should go read now, especially if you want to be able to judge whether I’m accurately representing Honan’s post. Which you should.

It an excellent piece and I’m nitpicking here, but I was bothered by this sentence regarding Honan’s test of the activity levels around Flickr vs. other services: “Perhaps more damning than the poor showing in terms of up votes was how ignored it was in real-time. It was only even viewed a total of five times on Flickr in that first hour.”

While I don’t think Honan is suggesting that Flickr build a better Instagram, exactly, it does feel like he’s suggesting that a viable Flickr is one that’s focused on a real-time, mobile, social photo experience as soon as possible, and that sounds to me a bit like trying to take Instagram head on rather than building a better Flickr.

It’s odd to say in these mobile-first, social-always days, but maybe Flickr would be better off building from their strengths. As Honan points out, Flickr “has great privacy controls, excellent display and sharing tools, makes a wonderful archive, and, despite years of neglect, enjoys tremendous good will.” What if Flickr stays focused on the web for a little while, and accepts (or embraces) a “slow photo” mindset against Instagram’s stream of consciousness, and Facebooks stream of…well, every-fucking-thing?

Could work. As I said: I really don’t know.

But I do know that Flickr shouldn’t try to build a better Instagram.

Identity : Anonymity :: Community : Network (?)


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


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.”


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


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:

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)

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


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.