Live data from Hacker News

A plan to rescue the Web from the Internet

staltz.com

151–160 of 220 posts

Re: A plan to rescue the Web from the Internet

#151

What makes people use centralized services is their utility. People will pick up new tools and repurpose them if they find them useful. In theory the web is supposed to be about communication and connection. I think the emphasis on building a local network is a good idea. P2P mesh is cool but until it provides opportunities that don't exist otherwise it is unlikely to surpass. The notion of building this for places w…

> The notion of building this for places without internet access is a positive angle but also tricky. Charity is seldom as successful or scalable as user driven initiatives.

Scuttlebutt's founder lives on a boat. There's no need for charity. We're all “us”.

> converting a 3 year old smartphone into a mesh 1st device seems challenging from a wifi driver and power consumption and app perspective.

Yeah, actually engineering the bloody thing is always the tricky bit.

> This is the challenge though, figuring out how to build utility that is superior to the walled gardens and is in the hands of the users to control.

Yeah, actually designing the bloody thing is always the tricky bit.

Re: A plan to rescue the Web from the Internet

#152
post #56
post #24

Earlier quoted context omitted.

Sorry, but I wouldn't like to lose the ability to build fully custom solutions. I don't want to rely on defaults. One person's sensible default is another's insane one. JavaScript is what it is today because it serves a purpose and frankly, I think it does it well enough for now. And without CSS we'll end up with Beige boxed web, all looking the same, behaving the same, and stuck in someone's idea of a sensible defau…

without CSS we'll end up with Beige boxed web, all looking the same, behaving the same Designers generally vastly overestimate how much users actually want "design".

Engineers generally vastly underestimate how much "design" affects purchasing decisions.

Re: A plan to rescue the Web from the Internet

#153

Earlier quoted context omitted.

> It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. [...] He was talking about the lack of protocol-level solutions for resilience of the Web. That's completely at odds with what Kay actually advocates for. His position is strongly aligned with the "mechanism, not policy" philosophy. That is, what he advocates for is less of what yo…

Having watched nearly every talk/interview of Kay I could find on YouTube (which includes the OOPSLA keynote) and having read some of his writings I think I have a reasonably good understanding of what he is advocating for. Here is Kay talking about Internet's resilience in a bit more detail: https://youtu.be/NdSD07U5uBs?t=1472 >His position is strongly aligned with the "mechanism, not policy" philosophy. I don't see…

>and having read some of his writings I think I have a reasonably good understanding of what he is advocating for.

In the Dr Dobbs interview[1] that you pulled the quote from, Alan Kay is not talking about protocols for web resilience. Actually, there is no mention of "protocols" in that article at all.

Even outside of that particular article, AK doesn't talk much about "protocols" other than the protocol of "message passing" in Smalltalk which is a different meaning from "internet protocols".

Tim Berners-Lee is a figure that speaks of new protocols for decentralization, etc. That's not Alan Kay's angle. If you think AK is imploring the tech community for new internet protocols, you need to cite another AK source other than that Dr Dobbs interview.

>[Alan Kay] was talking about the lack of protocol-level solutions for resilience of the Web.

That's not what he's talking about. He's complaining that the "web" did not make it easy for people to do computing. One example in that interview was Wikipedia page on Logo programming language not being able to execute Logo programs.

Kay's criticism of the "web done by amateurs" looks to be the same train of thought about his ideal Dynabook enabling people to participate in computing rather than something like the Apple iPad where people just read news or watch videos.

[1] http://www.drdobbs.com/article/print?articleId=240003442&sit...

Re: A plan to rescue the Web from the Internet

#154
post #80

Earlier quoted context omitted.

>How did IPv4 and NAT play any role in the dominance of Facebook, Airbnb et cetera? Very directly, I would say, by making the barrier to running your own low-traffic website too high. Modern social media is all about hosting content - microblogs, photos, etc. Geocities was an early workaround to an inability to host things, and it's worth remembering that MySpace was originally positioned as a kind of evolution of th…

The barrier is from the tools, not NAT. Maintaining your own server is prohibitively difficult for pretty much anyone besides niche technology enthusiasts or IT professionals. > Were it not for NAT, I would have expected an explosion in tiny self-hosted personal sites around the time that dialup was replaced by always-on cable connections NAT never stopped you from port forwarding 80 to your local server and many peo…

Maintaining your own server might be hard because there's no incentive to make it easy for technophobes to do. If there were software that was dead easy to use, there'd still be roadblocks: NAT, $ for a domain, ISPs blocking port 80, etc.

Re: A plan to rescue the Web from the Internet

#155

Earlier quoted context omitted.

You'd have way no indicate that your upvote succeeded with a 204 status code. Going back to my original point, and what you're arguing for me here, is that do this properly you'd have to imagine and implement every possible use case. In 1993, nobody envisioned web pages like Reddit. And yes, without JavaScript the web would be much faster and much safer but also much less interesting and powerful. It's hard to imagin…

> You'd have way no indicate that your upvote succeeded Sure you do. 204 No Content for success, 4xx for an error that you (or your browser) can fix, and 5xx for an error that only the server can fix.

Still horrible usability; you've taken me away from what I was doing to show me an error page.

Re: A plan to rescue the Web from the Internet

#156
post #80
post #53

Here’s the problem with IP addresses: there aren’t enough of them.... As a consequence, the Internet has allowed intermediate computers to rule. These are like parasites that have grown too large to remove without killing the host. The technical flaw that favored intermediate computers prefigured a world where middlemen business models thrive. The handwave is the word "prefigure". How did IPv4 and NAT play any role i…

>How did IPv4 and NAT play any role in the dominance of Facebook, Airbnb et cetera? Very directly, I would say, by making the barrier to running your own low-traffic website too high. Modern social media is all about hosting content - microblogs, photos, etc. Geocities was an early workaround to an inability to host things, and it's worth remembering that MySpace was originally positioned as a kind of evolution of th…

The last thing you want is to host things out of your home computer[1], especially when nowadays you can run a VPS for $2.50 a month [2].

If anything, fifteen years ago (when VPSs where prohibitively expensive) we had a much more open internet than now.

[1]. For security reasons (if someone breaks into your wordpress blog they won't get access to your main computer) and uptime reasons (do you want to keep your computer on all the time? Does your home ISP have an SLA?)

[2]. If you're fine with a static blog, a few cents for AWS/Google/Azure plus CloudFlare should be enough.

Re: A plan to rescue the Web from the Internet

#157
post #10

The reason the Web needs rescuing is because it's not a particularly well-designed system that has been patched over and over again for the last quarter century. And now it has been degraded to a delivery layer for JavaScript apps, a poor RPC protocol and an overly complex UI rendering toolkit. It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and…

The web is heavily abused because many developers are not aware of its misguided history or even what the web is for.

To be extremely clear the web is a document (markup) delivery/rendering application. The design goal of the web is to deliver documents that contain hyperlinks, where those hyperlinks address content extension. The web had no intention to be anything else.

That said the web was hijacked, for lack of a better term, by early web browsers that intended to do things that the web was never intended to do. This is how we got JavaScript. Fortunately, it also resulted in a universally standard architecture (the DOM), and additional technologies, that extended the web's original vision.

To be completely fair the Internet was not a spontaneous miracle, but went through similar growing pains. https://en.wikipedia.org/wiki/History_of_the_Internet

The problem today is that most developers have no idea what the web is or really how it works. Now, if you ask a developer about this they will claim otherwise and will work really hard to down play their ignorance. If you are not deeply aware of coding for the DOM, lexical scope, accessibility, asynchronicity, presentation separation, and so forth you are ignorant of how these things work. These are not expert qualities, these are the basics. This largely explains why so many people think HTML is the easiest thing to learn and then written really shitty HTML.

Re: A plan to rescue the Web from the Internet

#158
post #24
post #8

Earlier quoted context omitted.

HTML with great default styles and better built-in form and interactive elements (date picker, sortable tables) would be ideal. Screw CSS, it slows everything down, just have good defaults and don't let pages mess with them much. If we must have CSS at least jettison the complex parts with animation and such. Make it very, very simple and weak. No Javascript. Can't be trusted if it has the ability to initiate connect…

Sorry, but I wouldn't like to lose the ability to build fully custom solutions. I don't want to rely on defaults. One person's sensible default is another's insane one. JavaScript is what it is today because it serves a purpose and frankly, I think it does it well enough for now. And without CSS we'll end up with Beige boxed web, all looking the same, behaving the same, and stuck in someone's idea of a sensible defau…

The client would be the one customizing the appearance. You pick the client you like, or pick one which is themable as you wish.

You know, like for e-mail, or newsgroups, and so on.

Re: A plan to rescue the Web from the Internet

#159
post #10

The reason the Web needs rescuing is because it's not a particularly well-designed system that has been patched over and over again for the last quarter century. And now it has been degraded to a delivery layer for JavaScript apps, a poor RPC protocol and an overly complex UI rendering toolkit. It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and…

The web needs rescuing not because of technical issues, but because businesspeople and nontechnicals have twisted it far from its original intent and then captured everything that could as 'added value'. "Digital colonialism" is an incredibly apt term for this, and now with NN no longer governing traffic flow, the web needs a reboot away from those that would stick their grubby mitts in the stream.

Re: A plan to rescue the Web from the Internet

#160

Earlier quoted context omitted.

> You'd have way no indicate that your upvote succeeded Sure you do. 204 No Content for success, 4xx for an error that you (or your browser) can fix, and 5xx for an error that only the server can fix.

Still horrible usability; you've taken me away from what I was doing to show me an error page.

There is no rule in HTTP that mandates the user-agent must navigate away from what it's currently displaying to show you the payload of an HTTP error. It simply says [1] that the error "SHOULD" (in the RFC 2219 meaning of SHOULD [2]) be displayed to the user. Because of this, most browsers display the payload, but some show a built-in "friendly" error page if the payload is under a certain size.

Because of the language in the spec, the server can't rely on any particular behavior. If it reliably knew that user-agents always display the payload, the body of the 4xx or 5xx response could contain the exact HTML of the page you were just on, with the details of the error spliced in. Understandably, few people do this.

In late 1990s, early 2000s browsers, a status bar was commonplace which tended to show parsing errors, script errors, and other errors the user probably couldn't fix; nowadays these notifications have been moved to the console or log and are hidden from non-power users. A HTML form property could be used to signify that the form be submitted out-of-band, and have the results logged instead of updating the document view. With HTML5, they introduced the 'async' tag to allow linked assets to load without blocking rendering, so conceivably the same mechanism could be used to mark forms, if any user-agent were interested in supporting it.

The point is, extremely minor changes could improve usability in this particular case, using semantics that aren't breaking new ground at all, but quite simply no one has done it.

[1] https://tools.ietf.org/html/rfc7231#section-6.5 [2] https://tools.ietf.org/html/rfc2119

Post reply on HN