Web Post Examples that Use Unconventional Clients

created Apr 18, 2019

Omnibear browser extension

I created this post by using the Omnibear web browser extension, installed in the Chrome web browser. It also works with Firefox. Omnibear uses IndieWeb concepts.

I logged into the extension, using IndieAuth, which relies on my domain name. Omnibear is a Micropub client. My sawv.org server code supports Micropub on the server.

Omnibear can be used to create new posts, and it can be used to send Webmention replies to other websites that receive Webmentions.

I can use Omnibear to send a reply to the site that I'm reading. Omnibear tells my server code that the new post is a reply, and then my code sends the Webmention to the other website.

elinks web browser

I use Termux on my Chromebook.

Termux is an Android terminal emulator and Linux environment app that works directly with no rooting or setup required. A minimal base system is installed automatically - additional packages are available using the APT package manager.

Termux creates a limited Linux setup. I have Lua installed, along with other programs, including the ELinks web browser, which is a text-based browser. It's a fork of the Links browser, which is different from the Lynx text-based browser.

I used the ELinks web browser within Termux on my Chromebook to create this post.


On my old, Linux desktop computer that runs Ubuntu with Linux Mint, I used the NetSurf web browser to create this post.

Lynx, Links, ELinks, and w3m are text-based web browsers. I like NetSurf because it's a limited graphical web browser. It does NOT support JavaScript. It supports a smattering of HTML5 and maybe a smidgen of CSS3. It's enough. It's fast, and it can display simply-designed websites well.

links2 -g

Links is a text-based web browser, but a graphical option exists too. On my Linux desktop computer, I can launch the browser from the command line by typing links2 -g.

I created this post by using the links2 -g browser.

The graphical links does not support CSS. It does, however, provide a few simple typographical options that don't exist in modern web browsers.

All websites look the same, regarding font, colors, spacing, etc. But the browser is stunningly fast. It loads and renders pages literally in the blink of an eye because it only processes HTML.

Obviously, it supports cookies because that's how I logged into my website and maintained my login session.

At times, I like this browser better than NetSurf. I wish that NetSurf had a menu option to disable styling, like Firefox offers.

My two favorite alternative web browsers are both the graphical browsers NetSurf and links2 -g.

Even though ELinks running under Termux on my Chromebook is a text-based browser, it supports the mouse, including the mouse wheel, and it displays colors, such as the background colors mentioned within CSS.

I have Lynx installed too within Termux, but I use ELinks more.


I created this post by using the Opera Mini web browser on an old Blackberry phone that I got working last year.


I created my own web-based static site generator that I call Wren, which has an API. Wren's "client" code and API code are separate. It doesn't need to be, but that's how I've created several other CMS apps.

My web pub app called Sora works similar to Wren, except that Sora was written in Lua, while Wren was written in Perl.

From the command line, using cURL, I used Wren's API to request a login activation link, but the link was sent to the email addresses that I list in my Wren server's code file.

Within Termux on my Chromebook, I have the mutt email client installed. mutt is connected to my riseup.net email account.

I launched mutt to read the login activation email and to get the info attached to the link. I exited mutt.

Back on the command line, I used cURL to activate my login account. The Wren API code sent back the login session information.

Then I used cURL to create this post by sending all the required info to create the post.

My Wren API code receives JSON and returns JSON.

From my Wren API documentation:

Request Login Session Link

curl -X POST -H "Content-Type: application/json" --data '{ "email" : "author.email.address", "url" : "http://website/nopwdlogin"}' http://website/api/v1/users/login

The returned JSON:

  "user_message":"Creating New Login Link",
  "system_message":"A new login link has been created and sent."

Then I used the mutt email client to copy the info attached to the login activation link that I used in the next step.

Activate Login Session

curl http://website/api/v1/users/login/?rev=hHggOD2q

Returned JSON:


Create a New Post

curl -X POST -H "Content-Type: application/json" --data '{"author": "NickAdams", "session_id": "kPavt87rPj49cvGZY8YHnQ", "rev":"hHggOD2q", "submit_type": "Create", "markup": "# Test Post 8Apr2016 1113\n\nHello World"}' http://website/api/v1/posts

Returned JSON:

  "title":"Test Post 8Apr2016 1113",
  "created_date":"Fri, 08 Apr 2016",
  "created_time":"15:17:06 Z",
  "html":"<p>Hello World</p>\n\n","toc":0,"slug":"test-post-8apr2016-1113"


In addition to Omnibear, I can use any other Micropub-supported client to create and update content at sawv.org. I have used these web-based Micropub clients in the past to create content at sawv.org.

Those web apps support logging in via IndieAuth.

IndieWeb-compatible feed readers exist, such as https://alltogethernow.io that support Micropub.

alltogethernow.io is also a Microsub client.

I used All Together Now to create a test reply post for this post. I created the content within the feed reader.

Email posting

I made this test post by sending an email.

The first time that I used IndieAuth to log into quill.p3k.io, the web app also provided me with an email address that I can use to create posts on my website.

I email my post to my quill.p3k.io email address. Quill then uses Micropub to create the post on my website.

In theory, if I had internet access, and for some reason, I had no web access, then I could use an email client native app, such as the command line utility called mutt, to create new content on my website.

Currently, mutt that I use within Termux on my Chromebook points to my riseup.net email account.

I would either have to point mutt to my Fastmail account that hosts jr@sawv.org, or I could change one line in the homepage of my website.

<a rel="me" href="mailto:jr@sawv.org">jr@sawv.org</a>

That's what the IndieAuth login process looks for after entering my website, during the login process. I enter http://sawv.org and the IndieAuth process fetches my homepage and parses the content for `rel="me" instances.

I have a rel="me" pointing to my micro.blog account, which is used for something at micro.blog, such as connecting my RSS or JSON feed to my micro.blog account.

IndieAuth does not support micro.blog, but it supports logging in with email. If I changed the rel="me" line for the mailto to point to my riseup.net account, then I could use my current mutt in Termux setup.

Simple, old and new tech

With my Wren web pub app, I can create and update content by either using the simple HTML textarea box, which works on all limited browsers, or I can use my JavaScript editor named Tanager in a "modern" web browser, which is what I'm doing now to edit this page.

I can also use email to create new content on my website. Email has been around since the early 1970s.

When I spend a long time editing a post, then I typically use Tanager, but sometimes, I stick with the textarea box, which is always risky, since content could be lost if something happens to the computer.

Supporting the HTML textarea box and not using or requiring JavaScript outside of my Tanager editor allows me to create and update content with old, limited hardware and software.

I don't need anything more, regardless of the modernity of the hardware and software. Since 2001 when I started my first blog, I have created many thousands of web posts, small and large, mostly by typing within the HTML textarea box. It works.

On the server side, I continue to use old, boring tech, such as the Common Gateway Interface. More specifically, I rely on FastCGI.

As mentioned above, Wren is written in Perl, which is a scripting language that was first released in 1987. I test my Lua version at http://sora.soupmode.com. Lua was first released in 1993.

To get work done, it's still easy to create a web app by using CGI-like code in a scripting language. Not every website nor every web app needs to scale to the size of Reddit or Pinterest, let alone the super giant websites.

With the complexity that many developers and designers use today to create web apps and wesites, I wonder if we would have had as many new sites and apps back in the early aughts if that kind of complexity was required.

Back in the early aughts, a new web app/site could be created on a shared hosting server by building the server-side web program with PHP and MySQL.

I did that back in the fall of 2002 when I built the first version of my code that powered my toledotalk.com message board. I used a shared server, hosted at Hurricane Electric. I built the TT server code by using CGI, Perl, and MySQL. That can still be done today.

But now it seems that web developers are building every piddly website and web app with the belief that the site needs to scale to the size of Facebook.

With my Wren web pub app, I make heavy use of the HTML textarea box on the client side and CGI on the server side, creating simple HTML files with no JavaScript and a small amount of CSS. Wren also creates an RSS file.

That's all old, boring tech, but I also consider it to be easy-to-use, sturdy tech.

The modern aspects of Wren involve supporting IndieWeb concepts, such as IndieAuth, Micropub on the server, sending and receiving Webmentions, Microformats, and h-feed.

I have a test Twitter account. My Wren code can syndicate content to Twitter via brid.gy, which is an IndieWeb project. My Wren code can receive Twitter interactions via brid.gy too. Working with brid.gy relies on the Webmention.

Microformats are oldish, dating back to the early to mid aughts, but the IndieWeb community has promoted its usage. Microformats are not required, but it makes using Webmentions a bit easier and more expansive.