3 ms·

Where does stuff get saved in this read-write web you imagine? You mention fixing Apache -- does that mean every Apache server must accept edits from every anon

Where does stuff get saved in this read-write web you imagine? You mention fixing Apache -- does that mean every Apache server must accept edits from every anonymous contributor? You also mention a 'distributed filesystem' provided by Apache servers. Interested in knowing how that could work. Seems odd to blame the browser if it's really the server side that is what needs to be overhauled, to revive the open web.

hhas01 6y ago
“You mention fixing Apache” I used Apache as an example because 1. it is ancient, and as such rudimentary remains of early write support (e.g. PUT, DELETE) might still be found in its architecture, like leg bones in a whale; and 2. because it is nearly ubiquitous on the web. That said, Apache is a horrific bloated mess in general UX terms and end-user usability in particular, so wouldn’t be my first choice on which to refound a modern open web. Lessons can be learnt, the whole lot can be done better. “does that mean every Apache server must accept edits from every anonymous contributor?” I assume this is a rhetorical flourish and not actually a serious question. Even Apache, awful as its UI is, knows how to mediate read and/or write access for both individuals and groups. Look at how Dropbox manages access permissions and sharing. Now imagine achieving the same without Dropbox as middleman. “Seems odd to blame the browser if it's really the server side that is what needs to be overhauled, to revive the open web.” It has to be both. Done together. Because if they don’t talk fluently and seamlessly with each other, ordinary people are not going to use it and then we’re back to an elite technocracy and a mass pool of everyone else; precisely the conditions that gave rise to FANG(T) in the first place. .. But perhaps instead of describing an Open Web in terms of its technology, we should try to describe it in terms of its people? Model how its users both want and need to interact with one another, and then describe the technology to fit and facilitate that.
- aethertron 6y ago
  Oh, so Apache will handle user management. Fair enough. I was serious, didn't realise you'd go as far as to move away from the stateless state of HTTP.

hhas01 6y ago

“You mention fixing Apache” I used Apache as an example because 1. it is ancient, and as such rudimentary remains of early write support (e.g. PUT, DELETE) might still be found in its architecture, like leg bones in a whale; and 2. because it is nearly ubiquitous on the web. That said, Apache is a horrific bloated mess in general UX terms and end-user usability in particular, so wouldn’t be my first choice on which to refound a modern open web. Lessons can be learnt, the whole lot can be done better. “does that mean every Apache server must accept edits from every anonymous contributor?” I assume this is a rhetorical flourish and not actually a serious question. Even Apache, awful as its UI is, knows how to mediate read and/or write access for both individuals and groups. Look at how Dropbox manages access permissions and sharing. Now imagine achieving the same without Dropbox as middleman. “Seems odd to blame the browser if it's really the server side that is what needs to be overhauled, to revive the open web.” It has to be both. Done together. Because if they don’t talk fluently and seamlessly with each other, ordinary people are not going to use it and then we’re back to an elite technocracy and a mass pool of everyone else; precisely the conditions that gave rise to FANG(T) in the first place. .. But perhaps instead of describing an Open Web in terms of its technology, we should try to describe it in terms of its people? Model how its users both want and need to interact with one another, and then describe the technology to fit and facilitate that.

aethertron 6y ago
Oh, so Apache will handle user management. Fair enough. I was serious, didn't realise you'd go as far as to move away from the stateless state of HTTP.