What I did Sep1 - Sep7
Indieweb-stuff:
-
Tried to federate my indiewebsite so that I could interact with mastodon through it (unsuccessfully)
-
Hacked together a websub hub which passes all of the websub.rocks tests.
-
Rebuilt large chunks of my site---particularly the back-end---so that the posting interface is nicer and easier to test.
-
Factored out my markdown albums, webmentioning, and hashtag extensions into separate repos which I can independently maintain.
-
Hooked up webmentions again so that I can see webmentions as part of an ongoing effort to improve usability of federation.
-
Hooked up
in_reply_toagain, so that I can send webmentions. This also lets me reply-tweet using brid.gy -
Started posting albums and articles I'd held off on posting.
Reading:
-
Research proposals from different disciplines to figure out how I want to structure my candidacy document.
-
Bickhard's interactivism and process metaphysics
-
Anthony Chemero's take on representationalism
Other stuff
- Karaoke đ¤
- Symphony under the sky
- Knitting an aran sweater I designed
- Yoga đ§
dev indieweb what i did symphony epistemology grad-school music
- Download the audio.
- Download the slides.
Web standards donât exist.
At least, they donât physically exist. They are intangible.
Theyâre in good company.
Feelings are intangible, but real. Hope. Despair.
Ideas are intangible: liberty, justice, socialism, capitalism.
The economy. Currency. All intangible. Iâm sure weâve all had those âcollege thoughtsâ:
Money isnât real, man! Theyâre just bits of metal and pieces of paper ! Wake up, sheeple!
Nations are intangible. Geographically, France is a tangible, physical place. But France, the Republic, is an idea. Geographically, North America is a real, tangible, physical land mass. But ideas like âCanadaâ and âThe United Statesâ only exist in our minds.
Faithâthe feelingâis intangible.
Godâthe ideaâis intangible.
Artâthe conceptâis intangible.
A piece of art is an insantiation of the intangible concept of what art is.
Incidentally, I quite like Brian Enoâs working definition of what art is. Art is anything we donât have to do. We donât have to make paintings, or sculptures, or films, or music. We have to clothe ourselves for practical reasons, but we donât have to make clothes beautiful. We have to prepare food to eat it, but donât have to make it a joyous event.
By this definition, sports are also art. We donât have to play football. Sports are also intangible.
A game of football is an instantiation of the intangible idea of what football is.
Football, chess, rugby, quiditch and rollerball are equally (in)tangible. But football, chess and rugby have more consensus.
(Christianity, Islam, Judaism, and The Force are equally intangible, but Christianity, Islam, and Judaism have a bit more consensus than The Force).
HTML is intangible.
A web page is an instantiation of the intangible idea of what HTML is.
But we can document our shared consensus.
A rule book for football is like a web standard specification. A documentation of consensus.
By the way, economics, religions, sports and laws are all examples of intangibles that canât be proven, because they all rely on their own internal logicâthere is no outside data that can prove football or Hinduism or capitalism to be âtrueâ. Thatâs very different to ideas like gravity, evolution, relativity, or germ theoryâthey are all intangible but provable. They are discovered, rather than created. They are part of objective reality.
Consensus reality is the collection of intangibles that we collectively agree to be true: economy, religion, law, web standards.
We treat consensus reality much the same as we treat objective reality: in our minds, football, capitalism, and Christianity are just as real as buildings, trees, and stars.
Sometimes consensus reality and objective reality get into fights.
Some people have tried to make a consensus reality around the accuracy of astrology or the efficacy of homeopathy, or ideas like the Earth being flat, 9-11 being an inside job, the moon landings being faked, the holocaust never having happened, or vaccines causing autism. These people are unfazed by objective reality, which disproves each one of these ideas.
For a long time, the consensus reality was that the sun revolved around the Earth. Copernicus and Galileo demonstrated that the objective reality was that the Earth (and all the other planets in our solar system) revolve around the sun. After the dust settled on that particular punch-up, we switched up our consensus reality. We changed the story.
Thatâs another way of thinking about consensus reality: our currencies, our religions, our sports and our laws are stories that we collectively choose to believe.
Web standards are a collection of intangibles that we collectively agree to be true. Theyâre our stories. Theyâre our collective consensus reality. They are what web browsers agree to implement, and what we agree to use.
The web is agreement.
For human beings to collaborate together, they need a shared purpose. They must have a shared consensus realityâa shared story.
Once a group of people share a purpose, they can work together to establish principles.
Design principles are points of agreement. There are design principles underlying every human endeavour. Sometimes they are tacit. Sometimes they are written down.
Patterns emerge from principles.
Hereâs an example of a human endeavour: the creation of a nation state, like the United States of America.
- The purpose is agreed in the declaration of independence.
- The principles are documented in the constitution.
- The patterns emerge in the form of laws.
HTML elements, CSS features, and JavaScript APIs are all patterns (that we agree upon). Those patterns are informed by design principles.
Iâve been collecting design principles of varying quality at principles.adactio.com.
Hereâs one of the design principles behind HTML5. Itâs my personal favouriteâthe priority of constituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
âIn case of conflictââthatâs exactly what a good design principle does! It establishes the boundaries of agreement. If you disagree with the design principles of a project, there probably isnât much point contributing to that project.
Also, itâs reversible. You could imagine a different project that favoured theoretical purity above all else. In fact, thatâs pretty much what XHTML 2 was all about.
XHTML 1 was simply HTML reformulated with the syntax of XML: lowercase tags, lowercase attributes, always quoting attribute values.
Remember HTML doesnât care whether tags and attributes are uppercase or lowercase, or whether you put quotes around your attribute values. You can even leave out some closing tags.
So XHTML 1 was actually kind of a nice bit of agreement: professional web developers agreed on using lowercase tags and attributes, and we agreed to quote our attributes. Browsers didnât care one way or the other.
But XHTML 2 was going to take the error-handling model of XML and apply it to HTML. This is the error handling model of XML: if the parser encounters a single error, donât render the document.
Of course nobody agreed to this. Browsers didnât agree to implement XHTML 2. Developers didnât agree to use it. It ceased to exist.
It turns out that creating a format is relatively straightforward. But how do you turn something into a standard? The really hard part is getting agreement.
Sturgeonâs Law states:
90% of everything is crap.
Coincidentally, 90% is also the percentage of the worldâs crap that gets transported by ocean. Your clothes, your food, your furniture, your electronics âŚchances are that at some point they were transported within an intermodal container.
These shipping containers are probably the most visibleâand certainly one of the most importantâstandards in the physical world. Before the use of intermodal containers, loading and unloading cargo from ships was a long, laborious, and dangerous task.
Along came Malcom McLean who realised that the whole process could be made an order of magnitude more efficient if the cargo were stored in containers that could be moved from ship to truck to train.
But he wasnât the only one. The movement towards containerisation was already happening independently around the world. But everyone was using different sized containers with different kinds of fittings. If this continued, the result would be a tower of Babel instead of smoothly running global logistics.
Malcolm McLean and his engineer Keith Tantlinger designed two crate sizesâ20ft and 40ftâthat would work for ships, trucks, and trains. Their design also incorporated an ingenious twistlock mechanism to secure containers together. But the extra step that would ensure that their design would win out was this: Tantlinger convinced McLean to give up the patent rights.
This wasnât done out of any hippy-dippy ideology. These were hard-nosed businessmen. But they understood that a rising tide raises all boats, and they wanted all boats to be carrying the same kind of containers.
Without the threat of a patent lurking beneath the surface, ready to torpedo the potential benefits, the intermodal container went on to change the world economy. (The world economy is very large and intangible.)
The World Wide Web also ended up changing the world economy, and much more besides. And like the intermodal container, the World Wide Web is patent-free.
Again, this was a pragmatic choice to help foster adoption. When Tim Berners-Lee and his colleague Robert Cailleau were trying to get people to use their World Wide Web project they faced some stiff competition. Lots of people were already using Gopher. Anyone remember Gopher?
The seemingly unstoppable growth of the Gopher protocol was somewhat hobbled in the early â90s when the University of Minnesota announced that it was going to start charging fees for using it. This was a cautionary lesson for Berners-Lee and Cailleau. They wanted to make sure that CERN didnât make the same mistake.
On April 30th, 1993, the code for the World Wide Project was made freely available.
This is for everyone.
If youâre trying to get people to adopt a standard or use a new hypertext system, the biggest obstacle youâre going to face is inertia. As the brilliant computer scientist Grace Hopper used to say:
The most dangerous phrase in the English language is âWeâve always done it this way.â
Rear Admiral Grace Hopper waged war on business as usual. She was well aware how abritrary business as usual is. Business as usual is simply the current state of our consensus reality. She said:
Humans are allergic to change.
I try to fight that.
Thatâs why I have a clock on my wall that runs counterâclockwise.
Our clocks are a perfect example of a ubiquitous but arbitrary convention. Why should clocks run clockwise rather than counter-clockwise?
One neat explanation is that clocks are mimicing the movement of a shadow across the face of a sundial âŚin the Northern hemisphere. Had clocks been invented in the Southern hemisphere, they would indeed run counter-clockwise.
But on the clock face itself, why do we carve up time into 24 hours? Why are there 60 minutes in an hour? Why are there are 60 seconds in a minute?
It probably all goes back to Babylonian accountants. Early cuneiform tablets show that they used a sexagecimal system for countingâthatâs because 60 is the lowest number that can be divided evenly by 6, 5, 4, 3, 2, and 1.
But we donât count in base 60; we count in base 10. That in itself is arbitraryâwe just happen to have a total of ten digits on our hands.
So if the sexagesimal system of telling time is an accident of accounting, and base ten is more widespread, why donât we switch to a decimal timekeeping system?
It has been tried. The French revolution introduced not just a new decimal calendarâmuch neater than our base 12 calendarâbut also decimal time. Each day had ten hours. Each hour had 100 minutes. Each minute had 100 seconds. So much better!
It didnât take. Humans are allergic to change. Sexagesimal time may be arbitrary and messy but âŚweâve always done it this way.
Incidentally, this is also why Iâm not holding my breath in anticipation of the USA ever switching to the metric system.
Instead of trying to completely change peopleâs behaviour, youâre likely to have more success by incrementally and subtly altering what people are used to.
That was certainly the case with the World Wide Web.
The Hypertext Transfer Protocol sits on top of the existing TCP/IP stack.
The key building block of the web is the URL. But instead of creating an entirely new addressing scheme, the web uses the existing Domain Name System.
Then thereâs the lingua franca of the World Wide Web. These elements probably look familiar to you:
<body> <title> <p> <h1> <h2> <h3> <ol> <ul> <li> <dl> <dt> <dd>
You recognise this language, right? Thatâs rightâitâs SGML. Standard Generalised Markup Language.
Specifically, itâs CERN SGMLâa flavour of SGML that was already popular at CERN when Tim Berners-Lee was working on the World Wide Project. He used this vocabulary as the basis for the HyperText Markup Language.
Because this vocabulary was already familiar to people at CERN, convincing them to use HTML wasnât too much of a hard sell. They could take an existing SGML document, change the file extension to .htm and it would work in one of those new fangled web browsers.
In fact, HTML worked better than expected. The initial idea was that HTML pages would be little more than indices that pointed to other files containing the real meat and potatoes of contentâspreadsheets, word processing documents, whatever. But to everyoneâs surprise, people started writing and publishing content in HTML.
Was HTML the best format? Far from it. But it was just good enough and easy enough to get the job done.
It has since changed, but that change has happened according to another design principle:
Evolution, not revolution
From its humble beginnings with the handful of elements borrowed from CERN SGML, HTML has grown to encompass an additional 100 elements over its lifespan. And yet, itâs still technically the same format!
This is a classic example of the paradox called the Ship Of Theseus, also known as Triggerâs Broom.
You can take an HTML document written over two decades ago, and open it in a browser today.
Even more astonishing, you can take an HTML document written today and open it in a browser from two decades ago. Thatâs because the error-handling model of HTML has always been to simply ignore any tags it doesnât recognise and render the content inside them.
That pattern of behaviour is a direct result of the design principle:
Degrade Gracefully
âŚdocument conformance requirements should be designed so that Web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.
Hereâs a picture from 2006.
Thatâs me in the cowboy hatâthe picture was taken in Austin, Texas. This is an impromptu gathering of people involved in the microformats community.
Microformats, like any other standards, are sets of agreements. In this case, theyâre agreements on which class values to use to mark up some of the missing elements from HTMLâpeople, places, and events. Thatâs pretty much it.
And yes, they do have design principlesâsome very good onesâbut thatâs not why Iâm showing this picture.
Some of the people in this pictureâTantek Ăelik, Ryan King, and Chris Messinaâwere involved in the creation of BarCamp, a series of grassroots geek gatherings.
BarCamps sound like they shouldnât work, but they do. The schedule for the event is arrived at collectively at the beginning of the gathering. Itâs kind of amazing how the agreement emergesârough consensus and running events.
In the run-up to a BarCamp in 2007, Chris Messina posted this message to the fledgeling social networking site, twitter.com:
how do you feel about using # (pound) for groups. As in #barcamp [msg]?
This was when tagging was all the rage. We were all about folksonomies back then. Chris proposed that we would call this a âhashtagâ.
I wasnât a fan:
Thinking that hashtags disrupt the reading flow of natural language. Sorry @factoryjoe
But it didnât matter what I thought. People agreed to this convention, and after a while Twitter began turning the hashtagged words into links.
In doing so, they were following another HTML design principle:
Pave the cowpaths
It sounds like advice for agrarian architects, but its meaning is clarified:
When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
Twitter had previously paved a cowpath when people started prefacing usernames with the @ symbol. That convention didnât come from Twitter, but they didnât try to stop it. They rolled with it, and turned any username prefaced with an @ symbol into a link.
The @ symbol made sense because people were used to using it from email. The choice to use that symbol in email addresses was made by Ray Tomlinson. He needed a symbol to separate the person and the domain, looked down at his keyboard, saw the @ symbol, and thought âthatâll do.â
Perhaps Chris followed a similar process when he proposed the symbol for the hashtag.
It could have just as easily been called a ânumber tagâ or âoctothorpe tagâ or âpound tagâ.
This symbol started life as a shortcut for âpoundâ, or more specifically âlibra pondoâ, meaning a pound in weight. Libra pondo was abbreviated to lb when written. That got turned into a ligature â when written hastily. That shape was the common ancestor of two symbols we use today: ÂŁ and #.
The eight-pointed symbol was (perhaps jokingly) renamed the octothorpe in the 1960s when it was added to telephone keypads. Itâs still there on the digital keypad of your mobile phone. If you were to ask someone born in this millenium what that key is called, they would probably tell you itâs the hashtag key. And if theyâre learning to read sheet music, Iâve heard tell that they refer to the sharp notes as hashtag notes.
If this upsets you, you might be the kind of person who rages at the word âliterallyâ being used to mean âfigurativelyâ or supermarkets with aisles for â10 items or lessâ instead of â10 items or fewerâ.
Tough luck. The English language is agreement. Thatâs why English dictionaries exist not to dictate usage of the language, but to document usage.
Itâs much the same with web standards bodies. They donât carve the standards into tablets of stone and then come down the mountain to distribute them amongst the browsers. No, itâs what the browsers implement that gets carved in stone. Thatâs why itâs so important that browsers are in agreement. In the bad old days of the browser wars of the late 90s, we saw what happened when browsers implemented their own proprietary features.
Standards require interoperability.
Interoperability requires agreement.
So what we can learn from the history of standardisation?
Well, there are some direct lessons from the HTML design principles.
The priority of constituencies
Consider users over authorsâŚ
Listen, I want developer convenience as much as the next developer. But never at the expense of user needs.
Iâve often said that if I have the choice between making something my problem, and making it the userâs problem, Iâll make it my problem every time. Thatâs the job.
I worry that these days developer convenience is sometimes prized more highly than user needs. I think we could all use a priority of constituencies on every project we work on, and I would hope that we would prioritise users over authors.
Degrade gracefully
Web content can degrade gracefully in older or less capable user agentsâŚ
I know that I go on about progressive enhancement a lot. Sometimes I make it sound like a silver bullet. Well, it kinda is.
I mean, you canât just buy a bullet made of silverâyou have to make it yourself. If youâre not used to crafting bullets from silver, it will take some getting used to.
Again, if developer convenience is your priority, silver bullets are hard to justify. But if youâre prioritising users over authors, progressive enhancement is the logical methodology to use.
Evolution, not revolution
Itâs a testament to the power and flexibility of the web that we donât have to build with progressive enhancement. We donât have to build with a separation of concerns like structure, presentation, and behaviour.
We donât have to use what the browser gives us: buttons, dropdowns, hyperlinks. If we want to, we can make these things from scratch using JavaScript, divs and ARIA attributes.
But why do that? Is it because those native buttons and dropdowns might be inconsistent from browser to browser.
Consistency is not the purpose of the world wide web.
Universality is the key principle underlying the web.
Our patterns should reflect the intent of the medium.
Use what the browser gives youâbuild on top of those agreements. Because thatâs the bigger lesson to be learned from the history of web standards, clocks, containers, and hashtags.
Our world is made up of incremental improvements to what has come before. And thatâs how we will push forward to a better tomorrow: By building on top of what we already have instead of trying to create something entirely from scratch. And by working together to get agreement instead of going it alone.
The future can be a frightening prospect, and I often get people asking me for advice on how they should prepare for the webâs future. Usually theyâre thinking about which programming language or framework or library they should be investing their time in. But these specific patterns matter much less than the broader principles of working together, collaborating and coming to agreement. Itâs kind of insulting that we refer to these as âsoft skillsââthey couldnât be more important.
Working on the web, itâs easy to get downhearted by the seemingly ephemeral nature of what we build. None of it is ârealâ; none of it is tangible. And yet, looking at the history of civilisation, itâs the intangibles that survive: ideas, philosophies, culture and concepts.
The future can be frightening because it is intangible and unknown. But like all the intangible pieces of our consensus reality, the future is something we construct âŚthrough agreement.
Now letâs agree to go forward together to build the future web!
Two meetups to check out today if youâre in Portland! IndieWeb (10-noon at Cup & Bar) and our Micro Meetup (5-7pm at Von Ebert Brewing â @macgenie and @cheesemaker will be there at 3:30pm). Everyoneâs welcome!
10-12:00 Cup & Bar, 118 NE Martin Luther King Jr Blvd
Join us for coffee & chat about independent websites, like how to replace #socialmedia use with your personal site!
#openweb #dweb #fediverse
https://aaronparecki.com/2018/09/05/5/
Weaknotes 1
I really like Aliceâs updates.
I think Iâll do weaknotes. Some collections of notes. Sometimes. Not very well written probably. Generally written with the urgency of someone who is waiting for a baby wake up.
Very cool! Iâve been playing around with AWS Lambda as well and have my own hopes for getting my Micropub and other endpoints onto it!
Homebrew Website Club this evening in Austin. Join us at Mozartâs Coffee (6:30pm - 7:30pm) to chat about the IndieWeb. Also a good time to work on your own web site or ask questions about Micro.blog.
Daring Fireball: Medium Deprecates Custom Domains Service
I know many people love Mediumâs editing interface, but I just canât believe that so many writers and publications have turned toward a single centralized commercial entity as a proposed solution to what ails the publishing industry. There is tremendous strength in independence and decentralization.
