It's Eric Woodward (dotcom)

Inspired by both this toot and my recent dabblings in the Fediverse, I just wanted to take a moment and collect some thoughts about what I would like to see next in the #SocialMedia / #web space.

• I like the idea of using a hub-and-spoke model, where each actual edge device (phone / tablet / etc.) connects to some kind of always-on server (either a cheap virtual machine or a home-based server), which would be run by a tech-enabling friend, like BBSes used to be.
• All content creation and such would occur on the edge device, probably via a progressive web app hosted on the hub (to enable #offline creating), and which would connect to its hub when convenient to upload any newly created content.
  • Here, “content” means basically anything that you can create on a social media site - text, photos, replies, whatnot.
• The content would be marked up with IndieWeb microformats-2 tags, enabling easy consumption / sharing.
• Since the content creation / editing would occur on the spoke devices, the hub would be used primarily for caching and speedy connectivity (to prevent issues with asymmetric connection speeds that would prevent direct sharing between the edge devices).
• The hub would collect incoming messages for the user and cache them until the user’s device can connect to the hub to pull them down into their edge device(s).
• The hub would also support webmentions (both in and out), webfinger, and any other useful protocols (ActivityPub, to enable more clients?).
• Ideally, each user of this kind of system would have a subdomain of their own (https://eric.example.com), which has their public info, profile pic, and public posts, and which could serve as a Web sign-in endpoint via the presence of an h-card (listing their OAuth2-compatible accounts).

I freely admit that this idea still has some issues, since it is both incredibly hand-wavy and would still require tech-smart gatekeepers to run the hubs, but eventually even that second issue could be mitigated somewhat by turning the software into a single-click install option for a Pi or similar device (or pre-installed on such a device, with a plug-and-play setup of some kind, or pre-built images for VPS hosting).

I’m open to thoughts / suggestions / comments.

Lately, there seems to have been a up-tick in the never-ending debate about the web, advertising, and content-blocking. While Apple’s recent introduction of content-blockers in iOS9 is the most proximate reason for this discussion, it isn’t a new battle, and has been raging for quite some time. The basic argument is that many sites rely on advertising revenue to cover not just their costs, but also to turn a profit. And these web-based companies are (justifiably) concerned that ad-blocking could reduce (or destroy) that revenue stream, which might force them to shutdown.

To which I say, “so what?”

I’m not trying to be mean, but the fact is that lots and lots of businesses are forced to close every year, and many (most?) of them close because they have what some might call a “flawed business model”. Like some others, I believe that’s exactly what the “web advertising” model is, because if it wasn’t, no one would be blocking the ads, there would be no heated discussion about it, and blog posts like this one would never exist. I mean, some may liken ad-blocking to stealing, but others see it for what it actually is - disruption.

Look, I’ve been online long enough to remember the early attempts at monetizing the web: first came the embedded banner ads, which paid-per-view, but were easily ignored by end users; then came the pop-up (and pop-under) ads, which were still pay-per-view, but which couldn’t be ignored (unless you turned them off, since they relied on JavaScript); then came embedded banners with a “pay-per-click” model, which didn’t work because nobody wanted to actually click the links. And as each one rose to prominence, there were always those crying for people to engage with their ads (“If you don’t click on one of my ads, I’ll be forced to shut my site down!”). But the web remains.

And that’s part of why I titled this the way I did. Even if the commercial web went away (which, let’s be honest, it probably won’t), it wouldn’t be the end of the world: many sites which rely on donations or subscriptions would remain, as would storefronts and sites that support physical things. Plus, there are still many sites which are run more-or-less as hobbies, paid for by the people who run them. And, despite what the anti-blockers would say, there are other successful revenue models out there.

So, if you are a blogger or news site who is concerned about how this change will affect your bottom line, you have my sympathy: not because I block your ads (which I do), but because you put your faith in a fundamentally flawed business model (and believe me, you aren’t the only one). If, however, you think I’m wrong, then I encourage you to take the next obvious step and start blocking (or Comic Sans-ing) users who run ad blockers. If your content is worth viewing ads for, then people who run blockers will turn them off just so they can see it. But be prepared for the horrifying truth: when people have to actually pay for something (either with their eyeballs and “unblock” buttons, or with cold-hard cash), your site may not be good/interesting/original enough to actually generate revenue. Again, you have my sympathy… but not my cooperation.

It has recently been asked what the web might have looked like if the ad-based model had never taken off. Since we can’t rewind the clock, we can’t know for sure what course history may have taken in that instance. But if we keep running ad-blockers long enough, we may yet find out.

Baldur Bjarnason thinks he knows why RSS and Atom have come back into vogue, powering both Apple News and Facebook Instant Articles after years of disuse:

There’s one thing that’s very different this time around for RSS and Atom and it’s the reason why this time it might be different. Back then ‘just the HTML, no CSS, JS, or Flash’ meant nothing more than rich text with images.

Now, ‘just the HTML’ means rich text, video, audio, SVG, and more. While at the same time ‘HTML with CSS and JS’ has come to mean slow loading websites full of annoying ads and broken functionality (i.e. scroll-jacking).

It’s that last point (again) that’s the most important, IMHO, but it’s also the one that seems to be falling on deaf ears.

Christopher Sprigman takes another look at Richard Prince’s Instagram Exhibit, and makes some bold conclusions:

Prince’s body of appropriation art is provoking a reassessment of the meaning of authorship at a time when ownership of creative works in our digital world is tenuous. Anyone with access to the Internet can take something made by others, copy it, change it, and distribute it at the click of a mouse. In this context, we can see that authorship is not a stable concept, but rather that it shifts as technology weakens the link between an “originator” and his work. You may like that or hate that; Prince is pointing it out, in the direct way that only art can.

As a would-be artist whose done some “appropriation art” myself (as well as a longtime fan of perpetual copyright-trolls, Negativland), I find this whole discussion fascinating. However, I have to admit that I’m more than a bit surprised at the sums he’s been able to get for his “re”-work, and the implication that one man’s copyright infringement is another man’s high-brow art.

In browsing through some of the fallout from the arrival of Facebook’s Instant Articles, I stumbled across a couple of great pieces by Baldur Bjarnason (@fakebaldur) that go a long way to explain how we got into the situation we’re in, and why it’s us web developers who are responsible.

In the first, he takes on the ongoing debate about apps vs. the web, and makes the assertion that it isn’t “the web” that’s broken, it’s how (we) web developers are using it that’s broken (emphasis his):

Here’s an absolute fact that all of these reporters, columnists, and media pundits need to get into their heads:

The web doesn’t suck. Your websites suck.

All of your websites suck.

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.

The lousy performance of your websites becomes a defensive moat around Facebook.

In other words, if the mobile web is dead, it’s because we developers killed it.

On a side note, I wonder if this isn’t alot of the reason that millennials have increasingly preferred using apps to browsers - because mobile browsing is, for many, a needlessly painful experience.

In the second piece, he even goes so far as to explain why people can’t seem to get on the same page about how “the web” should be: Because they’re all talking about different versions of it:

Instead of viewing the web as a single platform, it’s more productive to consider it to be a group of competing platforms with competing needs. The mix is becoming messy.

1. Services (e.g. forms and ecommerce, requires accessibility, reach, and security)
2. Web Publishing (requires typography, responsive design, and reach)
3. Media (requires rich design, involved interactivity, and DRM)
4. Apps (requires modularity in design, code, and data as well as heavy OS integration)

Just to drive this point home, he makes reference to the Apple Pointer issue from earlier this year:

This is just one facet of the core problem with the web as an application platform: we will never have a unified web app platform.

What Apple, Google, Microsoft, and Mozilla want from web applications is simply too divergent for them to settle on one unified platform. That’s the reason why we’re always going to get Google apps that only work in Chrome, Apple Touch APIs that are modelled on iOS’s native touch model, and Microsoft Pointer APIs that reflect their need to support both touch and mouse events on a single device at the same time. There really isn’t an easy way to solve this because standardisation hinges on a common set of needs and use cases which these organisations just don’t share.

A more conspiracy-minded individual might even believe most of the major vendors would be better off if the standards never really do work out, since it would prevent “native-esque” web apps from cutting into their bottom-lines in their respective app stores. But I digress.

Speaking for myself, I know that I had never really considered this point when talking / ranting about “the web”. What’s more, I wonder if half of our inability to come to agreement on some of these issues is simply a matter of terminology getting in the way of having meaningful conversations. I mean, apps aren’t “better” than “the web”, because they are essentially part of (one form of) it: they use the same web protocols (HTTP / HTML) as the rest of the “browsable” web, they just use them on the back-end before glossing it over with a pretty “native” front end.

In fact, one might argue that this is the reason that the one area of web standards that has actually seen some progress in the past few months is the HTTP2 spec - an update to how data is transmitted on-the-wire, which should bring notable speed and security improvements to anyone that uses HTTP (including all of those native apps I mentioned earlier). After all, improving this part of “the web” is the one thing that all of the players involved can agree on.