Frameworks for citizen responsiveness, enhanced: Toward a read/write urbanism

We’ve been talking a little bit about what we might gain if we begin to conceive of cities, for some limited purposes anyway, as software under active development. So far, we’ve largely positioned such tools as a backstop against the inevitable defaults, breakdowns and ruptures that municipal services are heir to: a way to ensure that when failures arise, they’ll get identified as quickly as possible, assessed as to severity, brought to the attention of the relevant agencies, and flagged for follow-up.

And as useful, and even inspiring, as this might be, to my mind it doesn’t go nearly far enough. It’s essentially the lamination together of some entirely conventional systems, provisions and practices — something that already exists in its component pieces, something, as Bruce points out here, that’s “not even impossible.”

But what if we did take a single step further out? What if we imagined that the citizen-responsiveness system we’ve designed lives in a dense mesh of active, communicating public objects? Then the framework we’ve already deployed becomes something very different. To use another metaphor from the world of information technology, it begins to look a whole lot like an operating system for cities.

Provided that, we can treat the things we encounter in urban environments as system resources, rather than a mute collection of disarticulated buildings, vehicles, sewers and sidewalks. One prospect that seems fairly straightforward is letting these resources report on their own status. Information about failures would propagate not merely to other objects on the network but reach you and me as well, in terms we can relate to, via the provisions we’ve made for issue-tracking.

And because our own human senses are still so much better at spotting emergent situations than their machinic counterparts, and will probably be for quite some time yet to come, there’s no reason to leave this all up to automation. The interface would have to be thoughtfully and carefully designed to account for the inevitable bored teenagers, drunks, and randomly questing fingers of four-year-olds, but what I have in mind is something like, “Tap here to report a problem with this bus shelter.”

In order for anything like this scheme to work, public objects would need to have a few core qualities, qualities I’ve often described as making them “addressable, queryable, and even potentially scriptable.” What does this mean?

Addressability. In order to bring urban environments fully into the networked fold, we would first need to endow each of the discrete things we’ve defined as public objects with its own unique identifier, or address. It’s an ideal application for IPv6, the next-generation Internet Protocol, which I described in Everyware as opening up truly abyssal reaches of address space. Despite the necessity of reserving nigh-endless blocks of potentially valid addresses for housekeeping, IPv6 still offers us a ludicrous freedom in this regard; we could quite literally assign every cobblestone, traffic light and street sign on the planet a few million addresses.

It’s true that this is overkill if all you need is a unique identifier. If all you’re looking to do is specify the east-facing traffic signal at the northeast corner of 34th Street and Lexington Avenue, you can do that right now, with barcodes or RFID tags or what-have-you. You only need to resort to IPv6 addressability if your intention is to turn such objects into active network nodes. But as I’ve argued in other contexts, the cost of doing this is so low that any potential future ROI whatsoever justifies the effort.

Queryability. Once you’ve got some method of reliably identifying things and distinguishing them from others, a sensitively-designed API allows us to pull information off of them in a meaningful, structured way, either making use of that information ourselves or passing it on to other systems and services.

We’ve so far confined our discussion to things in the public domain, but by defining open interoperability standards (and mandating the creation of a critical mass of compliant objects), the hope is that people will add resources they own and control to the network, too. This would offer incredibly finely-grained, near-realtime reads on the state of a city and the events unfolding there. Not merely, in other words, to report that this restaurant is open, but which seats at which tables are occupied, and for how long this has been the case; not merely where a private vehicle charging station is, but how long the current waits are.

Mark my words: given only the proper tools, and especially a well-designed software development kit, people will build the most incredible ecology of bespoke services on data like this. If you’re impressed by the sudden blossoming of iPhone apps, wait until you see what people come up with when they can query stadium parking lots and weather stations and bike racks and reservoir levels and wait times at the TKTS stand. You get the idea. (Some of these tools already exist: take a look at Pachube, for example.)

– And finally scriptability, by which I mean the ability to push instructions back to connected resources. This is obviously a delicate matter: depending on the object in question, it’s not always going to be appropriate or desirable to offer open scriptability. You probably want to give emergency-services vehicles the ability to override traffic signals, in other words, but not the spotty kid in the riced-out WRX. It’s also undeniable that connecting pieces of critical infrastructure to an open network increases the system’s overall vulnerability — what hackers call its “attack surface” — many, many times. If every exit is an entrance somewhere else, every aperture through which the network speaks itself is also a way in.

We should all be very clear, right up front, that this is a nontrivial risk. I’ll make it explicit: any such scheme as the one sketched out here presents the specter of warfare by cybersabotage, stealthy infrastructure attrition or subversion, and the depredations of random Saturday-night griefers. It’s also true that connected systems are vulnerable to cascading failures in ways non-coupled systems cannot ever be. Yes, yes and yes. It’s my argument that over anything but the very shortest term, the advantages to be derived from so doing will outweigh the drawbacks and occasional catastrophes — even fatal ones. But as my architect friends say, this is above all something that must be “verified in field,” validated empirically and held up to the most rigorous standards.

What do we get in return for embracing this nontrivial risk? We get a supple, adaptive interface to the urban fabric itself, something that allows us not just to nail down problems, but to identify and exploit opportunities. Armed with that, I can see no upward limit on how creative, vibrant, imaginative and productive twenty-first century urban life can be, even under the horrendous constraints I believe we’re going to face, and are perhaps already beginning to get a taste of.

Stolidly useful, “sustainable,” justifiable on the most gimlet-eyed considerations of ROI, environmental benefit and TCO? Sure. But I think we should be buckling ourselves in, because first and foremost, read/write urbanism is going to be a blast.

31 responses to “Frameworks for citizen responsiveness, enhanced: Toward a read/write urbanism”

  1. dave says :

    I’ve proposed the “Tap here to report a problem with this bus shelter” as a mobile AR usecase with some actual utility before. Coming from an AR perspective, I’m inclined to solve “addressability” with world-coordinate geo-positioning rather than with unique identifiers or internet-space addressing schemes. In order to solve or visualize the problems, an identifier-to-location mapping would have to be made in any case. I think the barcodes/RFID etc has a place, but I’d prefer reserving those for mobile or indoor elements. The nice bonus with MAR is you can identify who made the report, you have a modality for clearly visualizing the authority’s response (or lack), and all users can instantly see the status of an object (so less dupes), progress etc.

    Whatever the technical solution, I want something like this. It feels like it would promote the kind of active and engaged citizenship a good city should foster.

  2. AG says :

    Whatever the technical solution, I want something like this. It feels like it would promote the kind of active and engaged citizenship a good city should foster.

    Did you see the first part of this series, Dave? : . )

    Yeah, I totally agree, clearly. The only place I differ from your perspective is in seeing AR as, essentially, a display layer. (For one thing, in the world I’m imagining, there are simply way too many mobile assets for geopositioning to be a robust solution.)

    I’m delighted, though, that somebody with your background can read this and not have it raise any immediate red flags. I’m always acutely aware that I come to technology as a second or third language, and getting these details right takes a little effort for me.

  3. egoodman says :

    Hey, Adam — get in touch with me and we’ll talk about the services framework I’ve been talking about for urban places that essentially mashes up the language of land ownership and the language of online service development.

  4. Noah Raford says :

    I can’t wait until my Microsoft Certified UrbanCityWare starts spewing boiling sewage into my face because of some botched security update…

    Or FaceCity decides I’ve violated its user policies and locks me out of my own damn house…

    The LOLZ are going to be awesome once the Russian hackers get access to the Mayor’s Office…

  5. Noah Raford says :

    Oops, that came off sounding more sarcastic than I meant, but more on this in a future blog post. :-)

  6. Jim Fleming says :

    1. IPv3 has been designed for Metropolitan Area Networks (MANs).

    2. IPv3 uses FREE 64-bit Addressing unlike expensive 128-bit IPv6 addressing.

    3. If you work with Objects you will find that a 128-bit Handle (OID) is too small.
    The 480-bit DHT Key size is
    a better fit for your City
    of Objects. put(Key,Data,Time)

  7. Matt says :

    You might be interested in It’s a UK site for reporting broken public infrastructure. You can report stuff through a web browser, but there are also smart phone apps that use GPS and a photograph to aid identification of the problem.

  8. AG says :

    Follow the very first link on this page, Matt. ; . )

  9. Matt says :

    Ah, sorry, I didn’t realise the bold bits were links!

  10. Chris says :

    I think this is really interesting stuff Adam, but the “non trivial risk” you speak of is, to put it a lot more bluntly, a huge risk. If you set up street-lights, gas mains, trash collection and so on, up to be “scriptable,” not only to municipal workers, but to the public, it’s going to get hacked,vandalized and abused on a regular basis. You obviously recognize this, but you don’t seem to lay out the amazing “opportunities” that outweigh these risks. Also what fun is city where everything is knowable and predictable?

  11. AG says :

    Chris, elsewhere in my work I’ve gone into great detail about the downsides and potential hazards of ubiquitous computing, whether those hazards be psychological, emotional, social or physical.

    Since they’re what I’m best known for, I guess I just don’t feel the need to reiterate those arguments here. What I do feel is that, if we don’t like the ubicomp/urbcomp we’re being offered, it’s time for those of us who are non-technodeterminist and non-technoutopian to articulate some positive vision of what a more densely networked world might look like. This is my attempt.

    As for knowability and predictability, I’m not sure where you get the idea that I think these qualities would be particularly desirable or important. Just the opposite, in fact.

  12. GreenfieldTrafficLaw says :

    You guys are talking way over my head. I was just searching around for some blogs about Greenfield, NY and look where I ended up lol.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: