{"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":298,"pdf_page":312,"physical_index":312,"physical_index_base":0,"printed_page_status":"recognized","page_sha256":"b94a480ea61cacf108bb0152f4337280c542999b7f760e4874692872aa00ca08"},"chapter":"Fheck The Stack |On Software and Sovereignty Benjamin H. Bratton","content":"This is The Stack-we-have. We can see it as one image and so perhaps can also see how it might be recomposed as a whole. Our most lucid attention now needs to be on the Stacks-to-come. The fissiparous geopolitics of Stacks includes the adjustments noted above as well as strategic Stack-versus-Stack warfare ( “ destroying a society one controller at a time ” ). Any of the possible Stacks-to-come can each be imagined as a whole, linking some User down to Earth, or they may intersect layer by layer, producing heterogeneous mixtures. Any relationship with or between infrastructural technologies might converge or diverge according to plan, or despite the plan, but can also be undone by Users driving columns into and out of other Stacks ’ layers. In the Cloud layer chapter, I outlined some of the logics of four existing platforms as Cloud Polis models (Google, Apple, Amazon, and Facebook) in order to demonstrate that their particular strategic combinations are not inevitable, and so just as we can imagine new combinations of these four, all the possible Stacks-to-come will be (as Stacks are now) made useful by real Users in dynamic amalgamations. The User layer of one model links to the Interface layer of another to the Address layer of a third, all perhaps situated in a City layer unreferenced by any of these three but drawing on the Cloud Polis of the second and the Earth layer of the first. The agnostic generosity of universal resolvers enables overlapping jurisdictions, and as a User moves from Stack to Stack to Stack, moment by moment, it also enables multiple and simultaneous sovereign positions.\n\nThese intersections are the normal condition with which and against which design must work, and there are at least four ways that adjustment between layers and between Stacks can be anticipated. They can be adjusted by the overlapping of one layer from one Stack by a column through a layer of another (as described above). There is also an adjustment in space, whereby two layers and two Stacks are situated adjacent to one another, like two cities. If a single User is in location X, then he can access Interface layer X, but if he is in location Y, then he will access Interface layer Y. A User traveling to another country who has to access another “ foreign ” wireless network is a familiar example of how two Interface layers may relate to one another by their adjacency in physical space. There is also an adjustment of sequentiality and of the relation between layers and Stacks over time. A User may access two different relatively homogeneous Stacks, one after the other, such that the use of the first makes possible the use of the second, or the use of one layer within one Stack may be a prerequisite for the use of another layer within the same Stack (which it usually is) or within another. It ’ s not hard to imagine different security scenarios that require a very specific sequence of actions to precede others. There are also adjustments in scale, both between Stacks and between layers. As discussed in the Interface chapter, an interface can be as small as an icon on a screen or as large as a security barrier between two countries. A User could be as “ small ” as an algorithm executed on a particular server or as “ large ” as the human population of a City combined over the span of a year. A Stack will work just as well with a tight scalar fit between what is situated at different layers (i.e., a human User and a standard keyboard Interface) or a loose scalar fit (i.e., a tiny algorithm and a distant megastructure, such as for Stuxnet). The Stack, and therefore also the design of The Stack, is qualified by these kinds of simultaneities, correspondences, parallels, desynchronizations, mismatches, and phase shifts.\n\n298\n\nThe Stack to Come","previous_page":297,"next_page":299}