The platform should hide the dynamic updates behind a static view, navigable through common controls. Navigation triggers availability of new content, but does not trigger update of viewed content. This is the original model of the web. The server serves static html to the browser, and the user navigates between them. This is where the back button originated. In this context, it made sense.
Now, where 'back' has new meaning in the context of a single app because that app is dynamic, the back button can not be consistent because every context is different. Are you closing the app? Are you closing one thing in the app? Are you just hiding the keyboard? No consistency.
But the original model of the web allowed the server to do whatever it wanted before sending you data. You didn't keep the data. A client side database was not part of the model.
The original model could be updated by having common controls (including 'back') manage and navigate the client side database only. Actions of the user in their personal database send events over channels that the user is 'on'. These channels the user sees as 'web apps' and replace the concept of being 'on a page'. The web app listening on the channel generates new data in response to events, and sends that data to the user's database, providing new options for the user to browse. The web app may not be hosted remotely, but may in fact be hosted in the user's database as well.
This is the model of Spaciousness.
And I lied in the title. This can be done without content addressability. But without content addressability it gets a lot harder, because you need ids for all the local data, and you need to merge data from machines the user moves between. And... and... it's just so much easier if the content is immutable. Trust me. You FP folks get it.
This is more of a brain dump than a white paper. Please prod me for clarification.