{"resolved":true,"match_type":"uuid","source_type":"original_book","book_id":"24410bf1-91f1-4e6b-9613-e64f0132d341","title":"The Stack On Software and Sovereignty","author":null,"edition":null,"publisher":null,"year":null,"isbn":"9780262029575","requested_by":"printed_page","book":{"source_type":"original_book","book_id":"24410bf1-91f1-4e6b-9613-e64f0132d341","id":"24410bf1-91f1-4e6b-9613-e64f0132d341","uuid":"24410bf1-91f1-4e6b-9613-e64f0132d341","title":"The Stack On Software and Sovereignty","normalized_title":"thestackonsoftwareandsovereignty","author":null,"edition":null,"publisher":null,"year":null,"isbn":"9780262029575","isbns":["9780262029575"],"parsed":true,"ai_readable":true,"document_type":"book","page_count":517,"navigation_url":"https://workshop.closeclaw.top/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341","title_url":"https://workshop.closeclaw.top/ai/title/The%20Stack%20On%20Software%20and%20Sovereignty","fixed_page_url_template":"https://workshop.closeclaw.top/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341/page/{printed_page}","path_api_url_template":"https://workshop.closeclaw.top/api/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341/page/{printed_page}","read_url":"https://workshop.closeclaw.top/api/ai/read/24410bf1-91f1-4e6b-9613-e64f0132d341","page_url":"https://workshop.closeclaw.top/api/ai/books/24410bf1-91f1-4e6b-9613-e64f0132d341/page","search_url":"https://workshop.closeclaw.top/api/ai/books/24410bf1-91f1-4e6b-9613-e64f0132d341/search"},"page":{"printed_page":169,"pdf_page":185,"physical_index":185,"physical_index_base":0,"printed_page_status":"recognized","page_sha256":"715b5bfb11156c6d0ee0f62397ebd2b213d8a1af87b98712d60595930c85fe58"},"chapter":"Fheck The Stack |On Software and Sovereignty Benjamin H. Bratton","content":"The City, as seen through the medium of that face, oozes with living data to be touched and rewritten all over again. It doesn ’ t only represent its world, but affects it as well; interaction is recursive, as a single User action is itself also new information aggregated into a living whole, informing what everyone else sees as their map. This recursion can cause one person to change his path and decisions in accordance with the actions of another User as indexed by the App, which is itself read as a real physical event, happening as part of the urban fabric, not floating “ on top of it. ” In this way, the virtual envelope of the mobile apparatus is, as much as the architectural envelope, a real circuit of movement primary to the City layer. But that equivalence also complicates programming strategies. Architectural programs and interfaces can be fixed or unfixed and can be designed into permanent structure or as shifting furniture; the same is true for software programs, which can be immobile site-specific installations or mobile applications in the urban wild. <sup>34</sup> For both architectural and urban projects, “ program ” provides material support to social activities that repeat themselves within predictable zones and partitioned locations, but as that material support is provided by software, the spatial “ program ” becomes itself as mobile as the handset device, which, for one or many Users at once, transposes that support into different locations at different times. As the functional organization of people across location and duration is coordinated by software as much as by walls and zones, urban functions are translated into applications, and as those are activated at a moment ’ s notice by different Users, each application provides a different interface to the same location for each of them, and so also a different urban program for each of the Users who happens to be in the same spot at the same time. Unlike the architectural envelope that coheres a polity by arranging its place just so, for the virtual envelope of the mobile apparatus, program becomes less of a fixed posture rendered in plan than a setting of parameters of access, improvisation, and opportunity. In other words, for mixed physical and virtual urban envelopes, the program itself becomes the platform.\n\nSurely, however, the most interesting design questions are not to be drawn by the artificial separation of physical and virtual envelopes (such as my proposed experiment) but by reorienting software and urban programming to mix and merge in more clever ways and, through this, to express emergent sovereignties more explicitly. The two are drawn together as architecture becomes a staging plane for software programs, just as software envelopes organize how urban space can be framed and activated. Whose assignment is this? Computer science is not nearly ready to take this on alone (perhaps someday), and architecture ’ s critical expertise in composing, replicating, condensing, and mobilizing the small and large interfaces of social space is woefully underused and underfinanced. A properly interdisciplinary design of the City layer would be both mechanical and dramaturgical; it would systematize the possibility of particular events occurring, both on schedule and off, and would draw the scenarios by which those events become richly woven languages. As the channels of the City are compressed and revealed by the handset ’ s interfaces, the virtual envelope ’ s augmentation might dissolve the gravity of architectural programs, or it may harden it. Either way, for architectural representation, the sectional stacking or planimetric allotment of discrete zones for spatial-social behavior to take place within a single envelope, gives way to interior and exterior encounters that can be activated in any number of different ways by different people using different software in hand, and so from minute to minute, as different Apps augment given spatial programs for different Users, any single architectural envelope is, to that extent, relieved of some of its programmatic responsibility and specific purpose. The same is true (more so) at the urban scale, where multiple architectural envelopes combine and compete, and where the distribution of formal programs is also finally bound to formally restricted legal-spatial zones (e.g., residential, manufacturing commercial zones). But at this scale as well, when multiple Users interact with a section of the City differently depending on what software they are running, zoning in the traditional sense becomes a much more problematic urban design trick; it becomes a less enforceable and perhaps also self-defeating sort of rule making. For the User, “ use ” is always mixed use, and so the design of the City layer requires a new way to represent program, not one that resembles an OMA (Office of Metropolitan Architecture) sectional diagram or the iPhone deck, but instead some kind of image that can trace the interdependent contingencies of hard and soft envelopes across lived network time. <sup>35</sup>\n\nCity Layer\n\n169","previous_page":168,"next_page":170}