Tags: protocols

21

sparkline

Tuesday, August 16th, 2022

No code

When I wrote about democratising dev, I made brief mention of the growing “no code” movement:

Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.

But I didn’t describe what no-code is, as I understand it.

I’m taking the term at face value to mean a mechanism for creating a website—preferably on a domain you control—without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.

By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:

Create any kind of website. No code, no manuals, no limits.

I’d also put Squarespace in the same category:

Start with a flexible template, then customize to fit your style and professional needs with our website builder.

And its competitor, Wix:

Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.

Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:

Your website should be a marketing asset, not an engineering challenge.

Bubble is trying to cover a broader base:

Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.

Wheras Carrd opts for a minimalist one-page approach:

Simple, free, fully responsive one-page sites for pretty much anything.

All of those tools emphasise that don’t need to need to know how to code in order to have a professional-looking website. But there’s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.

neocities.org:

Create your own free website. Unlimited creativity, zero ads.

mmm.page:

Make a website in 5 minutes. Messy encouraged.

hotglue.me:

unique tool for web publishing & internet samizdat

I’m kind of fascinated by these two different approaches: professional vs. expressionist.

I’ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)

Robin Sloan recently published his ideas—and specs—for a new internet protocol called Spring ’83:

Spring ‘83 is a protocol for the transmission and display of something I am calling a “board”, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.

It’s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it’s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.

It feels like something might be in the air. With Spring ’83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.

The Real Novelty of the ARPANET

Setting the scene:

The Washington Hilton stands near the top of a small rise about a mile and a half northeast of the National Mall. Its two white-painted modern facades sweep out in broad semicircles like the wings of a bird. The New York Times, reporting on the hotel’s completion in 1965, remarked that the building looks “like a sea gull perched on a hilltop nest.”

The hotel hides its most famous feature below ground. Underneath the driveway roundabout is an enormous ovoid event space known as the International Ballroom, which was for many years the largest pillar-less ballroom in DC. In 1967, the Doors played a concert there. In 1968, Jimi Hendrix also played a concert there. In 1972, a somewhat more sedate act took over the ballroom to put on the inaugural International Conference on Computing Communication, where a promising research project known as the ARPANET was demonstrated publicly for the first time.

It turns out that the most important innovation of the ARPANET isn’t obvious in hindsight:

So what I’m trying to drive home here is that there is an important distinction between statement A, “the ARPANET connected people in different locations via computers for the first time,” and statement B, “the ARPANET connected computer systems to each other for the first time.” That might seem like splitting hairs, but statement A elides some illuminating history in a way that statement B does not.

Thursday, May 5th, 2022

Notes from a gopher:// site - daverupert.com

The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern: selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.

Tuesday, August 10th, 2021

HTTP/3 From A To Z: Core Concepts (Part 1) — Smashing Magazine

I spend most of my time in the application layers—HTML, CSS, and JavaScript—so I fascinating to dive below the surface and learn about the upcoming HTTP/3. Sounds like it’s really more of a change to how things have always worked with the TCP protocol, still chugging away since it was created by Bob Kahn and Vint Cerf.

Sunday, August 8th, 2021

Chromium Blog: Increasing HTTPS adoption

At some point, you won’t be able to visit the first web page ever published without first clicking through a full-page warning injected by your web browser:

Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future.

Monday, March 29th, 2021

Chromium Blog: A safer default for navigation: HTTPS

Just over a year ago, I pondered some default browser behaviours and how they might be updated.

The first one is happening: Chrome is going to assume https before checking for http.

Now what about the other default behaviour that’s almost 15 years old now? When might a viewport width value of device-width become the default?

Sunday, August 30th, 2020

The land before modern APIs – Increment: APIs

This is a wonderful tale of spelunking into standards from Darius Kazemi—I had no idea that HTTP status codes have their origin in a hastily made decision in the days of ARPANET.

20 people got together at MIT in 1972 for a weekend workshop. On the second day, a handful of people in a breakout session decided it would be a good idea to standardize error messages between two services for transferring data, even though those two services had not necessarily planned to speak to one another. One thing led to another, and now 404 is synonymous with “I can’t find the thing.”

This story is exactly the kind of layering of technologies that I was getting at in the first chapter of Resilient Web Design.

HTTP status codes are largely an accident of history. The people who came up with them didn’t plan on defining a numerical namespace that would last half a century or work its way into popular culture. You see this pattern over and over in the history of technology.

Wednesday, August 5th, 2020

The Resiliency of the Internet | Jim Nielsen’s Weblog

An ode to the network architecture of the internet:

I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:

That simplicity, almost an intentional brainlessness…is a key to its adaptability.

It’s not a bug. It’s a feature.

Yes! I wish more web developers would take cues from the very medium they’re building atop of.

Wednesday, March 11th, 2020

The History of the URL

This is a wonderful deep dive into all the parts of a URL:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

There’s a lot of great DNS stuff about the host part:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Wednesday, January 22nd, 2020

28c3: The Science of Insecurity - YouTube

I understand less than half of this great talk by Meredith L. Patterson, but it ticks all my boxes: Leibniz, Turing, Borges, and Postel’s Law.

(via Tim Berners-Lee)

28c3: The Science of Insecurity

Monday, January 6th, 2020

Browser defaults

I’ve been thinking about some of the default behaviours that are built into web browsers.

First off, there’s the decision that a browser makes if you enter a web address without a protocol. Let’s say you type in example.com without specifying whether you’re looking for http://example.com or https://example.com.

Browsers default to HTTP rather than HTTPS. Given that HTTP is older than HTTPS that makes sense. But given that there’s been such a push for TLS on the web, and the huge increase in sites served over HTTPS, I wonder if it’s time to reconsider that default?

Most websites that are served over HTTPS have an automatic redirect from HTTP to HTTPS (enforced with HSTS). There’s an ever so slight performance hit from that, at least for the very first visit. If, when no protocol is specified, browsers were to attempt to reach the HTTPS port first, we’d get a little bit of a speed improvement.

But would that break any existing behaviour? I don’t know. I guess there would be a bit of a performance hit in the other direction. That is, the browser would try HTTPS first, and when that doesn’t exist, go for HTTP. Sites served only over HTTP would suffer that little bit of lag.

Whatever the default behaviour, some sites are going to pay that performance penalty. Right now it’s being paid by sites that are served over HTTPS.

Here’s another browser default that Rob mentioned recently: the viewport meta tag:

I thought I might be able to get away with omitting meta name="viewport". Apparently not! Maybe someday.

This all goes back to the default behaviour of Mobile Safari when the iPhone was first released. Most sites wouldn’t display correctly if one pixel were treated as one pixel. That’s because most sites were built with the assumption that they would be viewed on monitors rather than phones. Only weirdos like me were building sites without that assumption.

So the default behaviour in Mobile Safari is assume a page width of 1024 pixels, and then shrink that down to fit on the screen …unless the developer over-rides that behaviour with a viewport meta tag. That default behaviour was adopted by other mobile browsers. I think it’s a universal default.

But the web has changed since the iPhone was released in 2007. Responsive design has swept the web. What would happen if mobile browsers were to assume width=device-width?

The viewport meta element always felt like a (proprietary) band-aid rather than a long-term solution—for one thing, it’s the kind of presentational information that belongs in CSS rather than HTML. It would be nice if we could bid it farewell.

Friday, October 21st, 2016

Fermat’s Library | Why the Internet only just works annotated/explained version.

A ten-year old paper that looks at the history of the ARAPNET and internet to see how they dealt with necessary changes.

Changing a large network is very difficult. It is much easier to deploy a novel new protocol that fills a void than it is to replace an existing protocol that more or less works.

Friday, July 15th, 2016

The History of the URL: Domain, Protocol, and Port - Eager Blog

From the ARPANET to the internet, this is a great history of the Domain Name System:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Wednesday, June 22nd, 2016

Standardizing the Social Web

The slides from Aaron’s talk at OS Bridge in Portland, looking at the formats and protocols powering the indie web.

Wednesday, December 2nd, 2015

The System of the World Wide Web

A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.

And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.

URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.

Wednesday, September 9th, 2015

The CompuServe of Things

We need the Internet of Things to be the next step in the series that began with the general purpose PC and continued with the Internet and general purpose protocols—systems that support personal autonomy and choice. The coming Internet of Things envisions computing devices that will intermediate every aspect of our lives. I strongly believe that this will only provide the envisioned benefits or even be tolerable if we build an Internet of Things rather than a CompuServe of Things.

Wednesday, June 10th, 2015

The real story of how the Internet became so vulnerable | The Washington Post

The first in a series of articles about the architecture of the internet and its security issues, this is a great history lesson of how our network came to be.

What began as an online community for a few dozen researchers now is accessible to an estimated 3 billion people. That’s roughly the population of the entire planet in the early 1960s, when talk began of building a revolutionary new computer network.

Monday, December 9th, 2013

Toward A People Focused Mobile Communication Experience - Tantek

Some good brainstorming from Tantek that follows on nicely from Anne’s recent manifesto.

Saturday, June 15th, 2013

What’s Holding Up The Internet Of Things

This echoes what Scott Jenson has been saying: the current trend with connected devices is far too reliant on individual proprietary silos instead of communicating with open standards.

So instead of talking directly to one another, devices on today’s nascent Internet of Things now communicate primarily with centralized servers controlled by a related developer or vendor. That works, after a fashion, but it also leads to a bunch of balkanized subnetworks in which devices can communicate perfectly well with each other - but can’t actually talk to devices on any other balkanized subnetwork.

Sunday, December 9th, 2012

On Open Platforms, Wifi, Home Automation, and Kitty Litter | John Battelle’s Search BlogJohn Battelle’s Search Blog

This echoes Scott Jenson’s call for more open standards when it comes to networked devices. We’ll need it if we want “If This, Then That” for an internet of things.