4 ms·

"centralised web" was a poor choice of words. And I thought about that but let it go. You caught it. You're paying attention. That's good. But the point is

"centralised web" was a poor choice of words. And I thought about that but let it go. You caught it. You're paying attention. That's good. But the point is the same - the control is concentrated in middlemen (e.g. DNS, Hosting - why do I need them?[1]) - and you articulated this correctly: client-server. Calf-cow. Not peer-to-peer. That's what I'm keen to get past. 1. That's my point about Tor's hidden services. You need Tor's help of course but those services are free from the need for DNS and Hosting - free from the middlemen that control "the web" (not to mention controlling email- does anyone send email using IP numbers anymore? the spam fighting fanatics think every revolves aroudn DNS and domain names- your mail might well get rejected because you lack a "domain name"). I must confess I've never actually used the hidden services. I only read the docs and source code. "Using the web doesn't mean using a web browser" Not sure what you mean here. You need to use HTTP. So you need an http client. Chances are you'll be fed heaps of html and other garbage. Parsing it is a PITA. And eventually, if you want to view tables and such, you'll be using a "browser". Then there's the matter of state. So you're saying HTTP but not in a RESTful way? You just like HTTP headers, chunking and what not? HTTP is popular but it is not exactly unique. There are hundreds of other protocols in the RFC's, all of which would probably work just as well. HTTP is aimed at the client-server concept. That's fine. But it's a limited use for a network with so much potential. Something like a telephone conversation is not "client-server". I'm talking about making connections that are application agnostic. Like Ethernet. If you're suggesting tunneling everything in HTTP I think that's unnecessary. There are ways to deal with firewalls. HTTP tunneling is a last resort. So why HTTP? Why does it have to be at that layer? Why something that tied to specific applications that presume so much about what I want to do? I want freedom from applications. I can write my own apps, thanks. I want freedom to create new protocols, just for me and my friends. I want my own network, that we control. [This is possible using stuff that's been around for many years, and I have a working prototype. You folks are a bit too cynical to be beta testers, it's command line driven. Maybe someday.] I've tried nearly all those "browser" options you mentioned, believe it or not. All except for one suck. And if I had my way I'd extract the html table parser from it and have that as a standalone filter. I'd make it a UNIX utility. The whole "browser" concept is outdated. People want to watch video, listen to audio, look at photos and read plain TEXT (with great fonts of course). I don't need html to do any of those things. And I don't need html or other HTTP junk to do search to find video, audio or images. I need a tcp (or other) connection and a video player/audio player/image viewer/typesetter, as the task requires. All that said, hypertext is neat. But it's not world-changing. I can still do great research without "hyperlinks". Hypertext is the great benefit of HTTP. But at this stage, it is so weighed down with cruft and used in so many silly ways, making everything dependent on a monstrous abomination of a program called a "browser" (Firefox is freakin HUGE), it has become more of a burden than a benefit. It is a limitation, not a path to the future.

icebraining 14y ago
But the point is the same - the control is concentrated in a small number of points (e.g. DNS, Hosting) - and you articulated this correctly: client-server. Calf-cow. Not peer-to-peer. That's what I'm keen to get past. But the client-server is only for a single request, it's not a static property of a node. You can be both a client and a server simultaneously, making and accepting requests at all times. Not sure what you mean here. You need to use HTTP. So you need an http client. Yes. Chances are you'll be fed heaps of html and other garbage. No, HTML is definitively not necessary. Think of what it's commonly called "Web Services"; they're often only available using structured data encoding formats like JSON and they serve a whole lot of applications that are not web browsers: native mobile apps, for example. HTML is just one of the many formats that can be transported by HTTP, nothing forces anyone to use it in order to use the web. Then there's the matter of state. So you're saying HTTP but not in a RESTful way? REST doesn't prevent state. It just prevents session/context state from being stored on the server. You can still store it on the client (which, again, would just be one of the roles of a node) and permanent state on both. If you're suggesting tunneling everything in HTTP I think that's unnecessary. If you mean tunneling as in SOAP, definitively not. I suggesting using HTTP as it's supposed to be used. Something similar would have to be reimplemented anyway, and HTTP is already there and supported by plenty of tools, services, etc. Why does it have to be at that layer? Why applications? (...) I want freedom from applications. I don't get what you're saying. And if I had my way I'd extract the html table parser from it and have that as a standalone filter. The whole "browser" concept is outdated. People want to watch video, listen to audio, look at photos and read TEXT. I don't need html to do any of those things. And I don't need html or other HTTP junk to do search to find video. I need a tcp (or other) connection and a video player. Again, no HTML is needed. And no, a TCP connection and a video player is definitively not enough. You need some way to identify the video you want to watch, to decide what part of the video you want (e.g. if you already watched the first half), of knowing if that video still exists on the server, possibly some way to authenticate yourself (I don't want to share my personal videos with the world), and it would be nice if the video player could tell what formats it supports so that the server could send it the right version or say that none exists without having to download it. HTTP is well known, ubiquitous, provides all that and it certainly doesn't need HTML for it.

icebraining 14y ago

But the point is the same - the control is concentrated in a small number of points (e.g. DNS, Hosting) - and you articulated this correctly: client-server. Calf-cow. Not peer-to-peer. That's what I'm keen to get past. But the client-server is only for a single request, it's not a static property of a node. You can be both a client and a server simultaneously, making and accepting requests at all times. Not sure what you mean here. You need to use HTTP. So you need an http client. Yes. Chances are you'll be fed heaps of html and other garbage. No, HTML is definitively not necessary. Think of what it's commonly called "Web Services"; they're often only available using structured data encoding formats like JSON and they serve a whole lot of applications that are not web browsers: native mobile apps, for example. HTML is just one of the many formats that can be transported by HTTP, nothing forces anyone to use it in order to use the web. Then there's the matter of state. So you're saying HTTP but not in a RESTful way? REST doesn't prevent state. It just prevents session/context state from being stored on the server. You can still store it on the client (which, again, would just be one of the roles of a node) and permanent state on both. If you're suggesting tunneling everything in HTTP I think that's unnecessary. If you mean tunneling as in SOAP, definitively not. I suggesting using HTTP as it's supposed to be used. Something similar would have to be reimplemented anyway, and HTTP is already there and supported by plenty of tools, services, etc. Why does it have to be at that layer? Why applications? (...) I want freedom from applications. I don't get what you're saying. And if I had my way I'd extract the html table parser from it and have that as a standalone filter. The whole "browser" concept is outdated. People want to watch video, listen to audio, look at photos and read TEXT. I don't need html to do any of those things. And I don't need html or other HTTP junk to do search to find video. I need a tcp (or other) connection and a video player. Again, no HTML is needed. And no, a TCP connection and a video player is definitively not enough. You need some way to identify the video you want to watch, to decide what part of the video you want (e.g. if you already watched the first half), of knowing if that video still exists on the server, possibly some way to authenticate yourself (I don't want to share my personal videos with the world), and it would be nice if the video player could tell what formats it supports so that the server could send it the right version or say that none exists without having to download it. HTTP is well known, ubiquitous, provides all that and it certainly doesn't need HTML for it.