The web literally exists to share content. The first web browser was also a web editor. And ever since then, programmers have been working on ways to make publishing easier and better. As such, there’s no shortage of existing technologies that a new platform can build off of.
A brief aside about the nature of technology and its place as a part of a whole
It’s easy to think that the right technology will change everything. That somehow, the right code will make all the problems with Old Blue go away and we will live happily ever after in our new paradise.
It’s easy to forget that Posterous existed around the time of Old Blue’s ascendency. It was blessed with better technology, including a dedicated URL shortener and the ability to post via email. Old Blue arguably had inferior technology. But it won. The right technology came together with the right design and the right people at the right time, and the lightning in a bottle struck.
It takes more than good technology to change things. It takes good design, good timing, and a good understanding of the problems being solved. But the right technology can enable change. And as we talk about the technologies that can enable a new platform, it’s important to remember this.
The Interface Is Hot
So, for this essay, let’s look at some interfaces. These are also called “protocols” or “standards.” The general idea here is a group of people have written down, in technical language, how a thing should be accomplished. The most obvious of these would be the HTTP standard that governs how web browsers and servers talk to each other.
We’re not talking about code yet, just the ways we can use it.
This is what turns
https://www.youtube.com/watch?v=dQw4w9WgXcQ into the embed code that makes all your friends hate you. It involves a few steps:
- Blog gets URL from user.
- Blog looks up oEmbed endpoint for the URL, either
- Matching the URL to a list of known endpoints, or
- Looking for a particular
linktag in the page’s
- Blog hits the oEmbed endpoint and gets back the code required to embed the content from the URL into a page.
While this was likely originally intended for video websites, it has since grown to encompass all manner of sites, including Old Blue herself. The maintainers of the standard have a (non-comprehensive) list of sites using oEmbed on their website.
The takeaway: Reblogs worked on Old Blue because everything was still happening within the platform. Old Blue was able to enforce attribution and keep social information flowing back to the original poster of the content, no matter how far from the original it traveled. On the open internet, however, the distinction between “reblogging” and simple plagiarism can be hard to see. The ability to embed posts from other blogs, however, can re-create the idea of reblogging while maintaining attribution and social information.
RSS / JSON Feed
RSS has been used for nearly 20 years to allow other sites and programs to read updates from blogs and other regularly-updated websites. It’s evolved slowly, but its simplicity has allowed it to remain relevant even as most internet users don’t realize they’re using it.
Today, though Google Reader has shut down, RSS readers can still be found in services like Feedly and Feed Wrangler. It’s also used to populate stories in the Apple News app. Most prevalently, though, it’s used to deliver every podcast episode to their many listeners.
JSON Feed takes the same principle as RSS but uses the more JSON instead of XML as its primary syntax. This makes the format easier to understand at a glance, and it helps make the format more resilient in some edge cases.
The takeaway: Old Blue’s dashboard allowed you to follow other blogs on the platform. A decentralized platform would need a standard way to follow other blogs, and it already exists in this.
This is the authentication flow that allows external, third-party apps to tie back into a platform. By now, it’s hard to exist on the internet without using this to connect one app or website to another. Whether it’s signing into a mobile game with Facebook, or connecting Old Blue to Twitter, everyone’s familiar with “An app would like permission to connect.”
The takeaway: No social network can exist in a vacuum, at least not anymore. Any new platform is going to need to exploit connections to other networks, even if only for cross-publishing posts.
Webmention is a new standard that allows posts that are responses to others to link to each other automatically. It is patterned after the similar functionality found on social networks.
The takeaway: Once again, getting the same social information normally found on a monolithic platform would be key for making a decentralized platform feel like a “normal” social network. This is a relatively new standard, and care would have to be taken to make sure that spam and harassment wouldn’t overwhelm they system.
When a Plan Comes Together
None of these technologies alone will make a new platform successful. Even all of them together doesn’t guarantee success; in fact, if the different parts are not integrated well, the end result will be worse. Much worse.
Many of these technologies are in use by the IndieWeb, and all of them have open-source code that can be used by any platform. There is work being done to make these technologies more accessible and usable. And I am particularly impressed by the Micro.blog platform that has taken many of these technologies and others and made them into a plausible alternative to Twitter.
A new platform has to be aware of how these technologies interact. As I mentioned earlier, Old Blue won not on the strength of its technology but in how it used that technology to meet the goals of its users. Any potential replacement for Old Blue will need to take the same path: choosing the right technology and presenting it in the best way to allow people to understand it and use it effectively.
Design is a hard problem.
One reply on “Technology Cannot Make a Platform, But It Does Help”
Around the end of last year, I wrote an essay about what made Tumblr unique in the blogging world, followed by another essay about different technologies that can be used by a blog platform. And then I did nothing.
Well, not nothing. I went and got a new job. I also started sketching out some more concrete ideas. And while I want to be farther along in the actual development of things, I also want to start getting feedback on the ideas themselves.
Full disclosure: I’m great at talking about ideas, but I’m still learning to actually execute on them. Which is kinda disappointing, since the execution is where so many ideas go from “good” to “awesome.” So, bear in mind, this is an idea. It may not get very far, it may not get very good, it may crash and burn spectacularly. But these are problems I have wanted to solve for myself, and if I can help solve them for others, then I feel that I must try. So with that, let me announce…
The name was carefully considered and chosen for the following reasons:
“Smol” is one of my favorite “internet words.” It’s small, but more adorable. More comfortable. “Small” isn’t big enough, but “Smol” is just right.
It’s a blogging platform.
It’s for the space in between a micro-sized blog and a medium-sized blog.
Most importantly, smolblog.com was available.
Side note: it’s honestly ridiculous how hard it is to get a good dot-com these days.
“Smol” blogging is something I want to emphasize with this platform. Blogging on platforms like WordPress and Medium can feel intimidating. You have a blank page and a site that encourages posting about “big” ideas. What Tumblr excelled at was encouraging small posts of just a picture. Just a sentence. Just a link.
It’s no coincidence that I’ve probably posted more on my Tumblr blog in a year than I did on my WordPress blog in five. While Medium has become a home for presenting big ideas, Tumblr was a home for just… being yourself. That’s the kind of atmosphere I want to build on Smolblog.
A project needs to have guiding principles, a central problem to solve. Focus on these can help determine what features need to be built and which ones can wait for later. They can also help set the tone for interactions between people within and around the project.
Keep the gates open
Anyone should be able to set up a technically identical server. While some design elements and trademarks may be reserved for the ”canonical” site, there should be almost no difference using sites hosted on different servers.
Individual blogs should be easily moved (import/export) between servers or saved offline
Use open protocols for interactions
The end result is something like Mastodon: you don’t need to be on the same server as someone in order to interact with them.
Play well with others
Allow synchronization from and syndication to other social networks
Use oEmbed instead of copying others’ posts
I’m going to be much more willing to try something new if it means I don’t lose the social connections I’ve made on existing services. I’m shooting for Twitter and Tumblr crossposting for phase one as these are the services I use most.
Allow multiple blogs on multiple domains
Allow user-installed themes
Make it easy to post small posts and reblogs
There is a time and a place for standardized, beautiful web design. Your personal site should only be that if you want it to be.
Spoiler alert: it’s WordPress. It’s always been WordPress. Why?
It’s easily deployable on inexpensive web servers.
It’s well-supported and actively maintained.
It comes with several key features for Smolblog out of the box, including but not limited to
Image management and manipulation
oEmbed provider and consumer support
Standard format for import/export
Lots of people are invested in extending WordPress for custom purposes. I work with some of them.
So while I talk about Smolblog as its own thing, the first phase (at least) will be delivered as a WordPress plugin. If the project ever outgrows WordPress, then it will need to be at least as easy-to-deploy as vanilla WordPress is currently.
Building on top of WordPress, I plan on adding Tumblr and Twitter crossposting. I’ve already worked on a large part of the logic through a previous project of mine. By the end of phase one, I’m hoping to have the following features in addition to a standard WordPress Multisite install:
Import a full Twitter archive
Authorize against Twitter as a single account
Pull tweets from that account on a regular basis if they do not already exist on the site
Pull Retweets and Retweet-with-comments as embedded tweets to clearly deliniate original and reposted content
Push new posts to Twitter, either in full or as links back to site
Authorize against Tumblr as an account and indicate a blog
Pull posts from that blog, both historical and on a regular basis if they do not already exist on the site
Pull reblogs as embedded posts to clearly deliniate original and reposted content
Push new posts to Tumblr in as native a format as possible
This should lay the groundwork for adding more services as time and available methods allow.
Some other ideas that will have to come later, after the basic version is working:
Posting natively with ActivityPub
Cross-posting to Facebook Pages (depends on API support from Facebook)
Cross-posting to Instagram (currently being privately tested by Facebook, will depend on Facebook being kind and benevolent and honestly I don’t expect this to ever be possible)
Cross-posting to YouTube/Vimeo
Cross-posting to DeviantArt
Dashboard for following other sites/people (use RSS/ActivityPub to “follow anyone”)
Supporting Micropub APIs well
Native post editor for when Gutenberg is too much
Allow end-user editable custom theme
There’s a lot here. I’m not going to be able to do this myself. But I’m going to try. If you want to follow along, the best place to do that is here on this blog (see email widget at the bottom of the page). If you want to see or contribute code, check out the GitHub repo for the plugin.
I have lots of hope and plans. I hope to have more. Thanks for reading, everyone.