Excursions avatar

Essays

Are humans really blind to the gorilla on the basketball court?

A wonderful essay on what’s obvious” to human and how the fallacy that obviousness is driven by human bias”, which in itself is error prone, can lead to ungrounded, optimistic euphoria, especially around AI.

Knowing what to observe, what might be relevant and what data to gather in the first place is not a computational task — it’s a human one. The present AI orthodoxy neglects the question- and theory-driven nature of observation and perception. The scientific method illustrates this well. And so does the history of science. After all, many of the most significant scientific discoveries resulted not from reams of data or large amounts of computational power, but from a question or theory. (…)

Computers can be programmed to recognise and attend to certain features of the world — which need to be clearly specified and programmed a priori. But they cannot be programmed to make new observations, to ask novel questions or to meaningfully adjust to changing circumstances. The human ability to ask new questions, to generate hypotheses, and to identify and find novelty is unique and not programmable. No statistical procedure allows one to somehow see a mundane, taken-for-granted observation in a radically different and new way. That’s where humans come in.

The essay is loaded with astute observations and arguments, made me thing. A must read.

User Discovery with Micro.threads

I had recently started working on updating Micro.threads application to focus on discovery, specifically user discovery. My social interactions on the internet have never been dull or frustrated since I joined Micro.blog. And it can largely be attributed to the extremely fine community of users that exists on the platform.

However, I had also realised that there were a lot many threads, many interactions that I was missing on, because finding new users was still not easy. Discover section exists, but it helped primarily to get new, interesting posts. There was a major section of the platform which could assist me to ease this problem. And that is people I follow and their posts in my stream.

Manton had recently updated the default behaviour of a user profile’s Following” section to display only a list of who someone is following that you aren’t following already. That itself is a huge improvement in identifying new users. But, for me, that too was a bit troublesome. I wanted to focus not just on the follow status, but the interactions; not just focus on whom someone I already follow, follows, but rather whom they interact with frequently.

So it was only just to build a system, first of all for myself that will discover more amazing users that I can follow, that I can interact with and learn from. And so I did.

Micro.threads User Discovery

I have been playing around with the user discovery section of Micro.threads. And I think it will help others too. Just head over to the Micro.threads -> Discover section and give the application a try. You may find it helpful. You may not. But I think the feedback you share would be useful for me, and hopefully to the community too.

I believe this just acts as a placeholder until such discovery features are available in the official app itself. Till then, this would be a playground to identify more ways to discover interesting profiles and threads on Micro.blog.


I have made some key considerations at this point while developing and rolling this out.

  1. You will have to sign in with your Micro.blog user id and an app token, which is discarded the moment you log out. I have no intention to maintain any accounts or credentials. I plan to use the /account/signin API from micro.blog in future; for now, app token is the quickest, officially supported way to get going.
  2. I haven’t optimised the performance of discover algorithm to the fullest. I plan to get that done that gradually.
  3. I am inclined to keep the information shown itself improving, and also add more ways to unearth user profiles and threads.This is just a first version that I was satisfied with and could roll out. I am already working on the threads parsing and discovery which I think will get done this weekend itself.
  4. I do not think I can get this perfect or can stay focused without the feedback from you all. So, any and every feedback is welcome.

State of Microsub Servers and Client

I had recently expressed an excited opinion on Microsub, the new” Indieweb spec. I could then see the potential of the standard and also the available solutions, the server and the clients, around it.

I have seen Monocle in action now and realise the power of Microsub standard. I do not think I can read feeds in any other manner now. This is fantastic!

The fact that there exists a hosted Microsub server in Aperture is a great start, it has given a chance to many to get started knowing the standard early. And I know people like Aaron Parecki are hard at work to continue improving the clients like Monocle. However, I think my excitement was premature.

No doubt, the core technology behind Microsub is solid and it can eventually redefine the way feeds are subscribed to and consumed. And bundled with Micropub to post actions of the type like, reply, repost directly to your website right from your reading view makes it absolutely magical.

So I don’t blame myself that I got excited about the standard seeing the potential of what can be achieved when all these Indieweb standards work seamlessly together. Seamless is the key though. For the last few days, I have been trying to use Monocle as my primary feed reader. Unfortunately, the whole system has some way to go before I actually can. I am just noting down the frustrations I encountered using the system.

  1. Keeping the read status of the posts in sync is flaky. Many of the posts I have read already are shown again. Some of the posts that should have already popped up are not available for some time. When they finally are, they are available in bulk. If I understand the standard correctly, it is the server at fault here. And it is only a single client involved at this point.
  2. Subscribing to feeds with the server is not easy. Not user experience wise, but again in terms of the unreliability of the posts appearing in the stream. At times, there are 0 posts fetched; at other times, there is a bulk of hundreds of posts. It poses a challenge for the client.
  3. And to the client. I think we can learn from the available feed readers and focus on the must-have features - which are primarily around showing available posts. Monocle currently cannot be configured to show only the new posts. Filter options are limited. Sorting options are limited. Marking read/unread is unavailable. Subscribing to new feeds is not possible (even though spec has a follow API which I hope Aperture exposes). Few of these might be nitpicking, but they are important when the reference for most new users would be existing feed readers.
  4. The concept of Microsub server and client, former for maintaining the feeds and the later for displaying them, sounds great. However, to get people on board, we will need at least one application that does the job of both. Wish Monocle and Aperture were two components of a single application.

I know the standard is still a work in progress, especially the server and client applications. So no doubt there would be some kinks in the working. The intention of this post is in no way to demean the people involved or pinpoint at the failures. My intention is to capture my thoughts on why, even though I want to, I cannot yet use the current applications in place. The standard is making significant headway and I hope I would soon be able to benefit from the system. As Aaron says in his introductory post I referenced above -

My goal with this is to use this as my primary online dashboard to follow all kinds of content, as well as being able to interact with the content without leaving the interface.

Amen to that. Unfortunately, now is not the right time. So I am back to my search for that perfect feed reading service.

Update on Micro.threads

I had recently realised the project I had much plan for wasn’t updated since sometime back. So much that for an observer it very well looks to be potentially defunct. There are many reasons why I couldn’t push regular updates to this. Priorities at home and at work just didn’t allow me enough time.

However, deep down I knew I just wasn’t satisfied with what I had achieved. I had a huge list of things that I needed to implement and the effort required I thought was huge. But I just couldn’t look at the stagnant progress of this service. I found it useful at multiple times and I know it can be improved so that others do too. So, I have decided to take up the project, small improvements at a time.

To start with, all the threads, mainly from posts featured in discover section and Emoji collections, are up to date. Well, @mantons hard at work and has already grown the list of Emoji collections. Well, all the Emoji Collections from Micro.blog are available at Micro.threads now. So I (and others) can now get all the recommendations for that one 🍕 parlour or one’s 🗺️ogue.

But there’s more. The huge list of limitations I talked about at the top? Yeah, I have decided to start addressing them small updates at a time. Firstly just by noting them down.

  • Threads concept itself is limited. Currently it takes a post id, fetches the conversation (thread) and then pull out all the links and only show these links as a thread.
  • Creating thread is a mess and so is updating it.
  • No way for external users to generate threads. Keeping threads updated is a chore at this point.

So, I have been back to drawing board, working on the ways I want to address these and present what I have in mind. I have a clear objective with this service. What’s to come has already found its place on the homepage, just as a placeholder for now. I wish I manage to deliver it to my satisfaction, first and fore most. If along the way, it helps the community, well and good.

Back to work.

Micropub endpoint from the ground up

The recent experiments with blot.im has given the perfect opportunity to explore if I can get a Micropub endpoint created specifically for my needs. Till now, I have been using a custom fork of a endpoint from Pelle Wessman for my Hugo site. It has served me well.

However, I always wished if I could get one written specifically for my simple needs. One that I know and understand every part of. Given that I have no endpoint yet for the blot site, this is clear opportunity to create one geared for making this site micropub enabled. Hugo site will address my third-party-posting needs till then. So here’s the start. I will capture this journey, of course, here and will keep this updated with progress (I hope). Below are the things at this point that I need to get started.

I want to explore python first as an option to get this implemented. I have come to realise that I do not like Javascript as a language. I can get work with it, but at times the inconsistencies and the constructs get in my hair.

Update on Blot Open Questions

Update: I had sent these questions to David, the developer behind Blot, on the support email address. And of course, given how gem of a person he is, he did address all of them quickly. I am updating the original post with his responses. This dedication of David makes me love this service even more!


I have some questions I need to explore and find answers for some issues in using Blot. Just jotting them down for reference. The list may continuously grow and shrink as I find the answers.

  1. What’s going on with \{\{Summary\}\}? I do not think it generates what it says it does - first line”. It ignores lines with links, it ignores codes in the line. So what’s outputted is something inaccurate.

[David]: You can override summary in the metadata at the start of a file. If you know a little javascript, you can read the rules for how the summary property is generated automatically.

  1. Can we override the behaviour of \{\{title\}\}? It is especially important for title-less posts as currently, the file name gets used by default. You need to explicitly set Title: to blank.

[David]: You can also override title in the metadata. However, based on what you are trying to do, I’d make use of the property. This refers to a markdown or HTML title tag in the file itself. For example:

  1. Point 2 is also important for posts via just the image files. As of now, it adds the image name as the title. I would prefer not the post to have any title at all.

[David]: I think I have solved this point in #2, please let me know if not.

  1. Can we override the behaviour of \{\{\{body\}\}\}? Just want to explore possibility to modify behaviour of URLs of image sources. Currently, relative URLs to blotcdn without scheme are added.

[David]: No, it is not possible to modify body. Please can you explain what you are trying to do? Would you like Blot to stop uploading your images to blotcdn? You can disable this behaviour on the settings page under Images > Cache and optimize images

  1. How can we make reference to any Post parameter in a post? If we include the parameter (for example , it gets converted to the title on build? Can we escape the { and }?

[David]: This is not possible right now, it is a bug, I will fix it. Sorry!

Book Review: Murder in the Mystery Suite

A mystery of murders during a Murder and Mayhem week”, amid some role-playing and fantasy crime solving”. Now that’s one juicy premise. Alas, a juicy premise is necessary, but never sufficient after all to make a compelling read.

A widower Jane Stewart works as a manager at her ageing great-aunt and -uncle’s storybook resort. Things go awry for her when during her planned Murder and Mayhem week, one of her guests is murdered and the book he had won as part of a scavenger hunt is missing. It is now Jane’s responsibility - not just as the resort manager, but as a guardian to the treasure the book was part of - to find the real-killer and the missing book.

This is such a simple plot that could very well have been penned into a riveting mystery. But it wasn’t. I was so close to give up on this books at one moment - actually that was right at the moment it stopped being a murder mystery and veered into at attempted thriller around a treasure trove. Plot is thin. Writing is barely passable. Mystery is poorly narrated. There just isn’t enough suspense and urgency to hold the reader’s attention. A straight forward story, narrated in an extremely amateurish manner.

A word on the writing first, I think the way the book started was pretty promising. Author Ellery Adams did have a nice plot at her hands. However, the way she chose to present it is so unlike a murder mystery typically is. I wasn’t involved enough to care for anyone who was dead because the characters just weren’t built well. Add to that, a reader was informed, told, that a person was murdered — never shown. For that matter, every thing that happens is told to the reader, not shown. And that’s where lies the biggest fault of the novel.

An inclination from the author to kick start a series by making this much bigger than a simple, cozy murder mystery didn’t help either. All it does is introduce a string of unnecessary subplots and a meandering ending that attempts to set ground for books to come.

A murder mystery needs a meaty plot, strong characters and succinct narration. Unfortunately, this books fails on all count for me. Jane, the protagonist, doubts at multiple points in the book if she is worthy to be the guardian of a family secret; wishes if she had just been a Resort Manager. I, as a reader, wished the same.

My rating: 2 of 5 stars

Thoughts on The Rule of Links

Every post I write oftentimes has a link to an external post, either as a reference or as a recommendation. And every single time, I go through this struggle of deciding which word should carry the link. It was so naive of me to think Dave Winer won’t have written about it. Of course, Dave had.

He recently linked to his post on The Rule of Links.

Linking is an art. It’s a choice. You don’t link from every word or even every noun, or from the subject of every sentence. But when a reader reasonably would want to know more about the subject, the Rule of Links says you should link to it.

It has to be the word that makes the reader curious with any of the 5 Ws on the topic. But something that is always pestering me at the back of my mind is what does this link communicate to the search engines. Isn’t this link also one of the signals for Google to decide what the outgoing link (the page) is about?

So I believe the first link of this post is correct as per Dave’s rules of links. However, I don’t think that helps a search engine understand the linked page better.

It won’t be a stretch to think Dave believes a writer shouldn’t worry how a search engine reads a post. But given the reality of today’s web, one just cannot ignore how a search engine sees your page.

Also, I am a bit torn on the below perspective.

In the Web, after having visited a link, you can just hit the Back button to regain your context. (An aside, that’s why links that open in new windows are non-web-like.)

On this site, I do adhere to this principle for all the regular posts. However, for link-posts, I do open the post linked from the title in a new window. I do not create such posts just to share the link — for that, I would, well, just share the link on whichever platform. I generally have some comment to make on the post or the section of the post.

So in such cases, I assume the reader visiting my site wants to read my commentary. And I do not want to lose her attention by forcing her out to the linked post. If she has already read the post, great. If she hasn’t, she can do so in a new tab and then come back to the commentary.

Is it really appropriate to open a new tab on a reader’s machine just to not lose that reader? No. Shouldn’t I trust my writing to pull the reader back even if she gets redirected? Of course, yes. However, given our diminishing attention span amid the growing distracting portals all around, how practical is it to assume she will be back?

Slippery slope that is win-at-all-costs

Recent drama, being termed #SandpaperGate, around Australian cricketers admited to tampering with the ball has raised so many questions. We play our cricket hard but fair has been a pretty common response every time fingers have been pointed at Australian cricketers. And I sided with them more often than not. It is ok to wear aggression on your sleeves —that is till you plain start cheating. All because you think you need to, you have to win. That just doesn’t make any sense.

This win-at-all-cost approach is risky — once you start walking down this path, you eventually lose the sight of what the game is all about. Spirit of the game” then are just some hollow words you utter every now and then to keep yourself entertained.

As has been so rightly said by Sambit Bal - this is Australia’s moment of truth”.

It was desperation, Smith said, that drove them to this. But this was about saving a match, not lives. How far elite sportsmen stretch their bodies and mind in search of victory forms part of sports’ intrinsic appeal, but the attendant danger of the win-at-all-costs approach is that it thins the line between ultra-competitiveness and sharp practice.

I still do not understand what desperation Smith was talking about. The series was level 1-1. Australia still has one of the best new ball attacks there is. They have been playing some good cricket in recent times. So what’s there to be so desperate towards a win?

And how stupid was this leadership group” to think and agree on such brainfart, given there are cameras all around? I really doubt these players are this naive.

Open Web and Your Social Signature

I had recently expressed my hope for more people to own their identities online.

There is nothing wrong with attempting to control what you post online, to make sure it stays online till you want it to. I do also realise that it is naive to think no one getting online will find this process irksome. Even though well defined, the (open web) principles are not for all. The simplicity of using and posting on social media services will continue to attract regular users. However, here’s wishing that at least a part of these users are inspired to get their own personal domain.

An innate wish there is that more people would leave the silos behind and get online as themselves, express thoughts that are their own, not mindless reposts and shares, and at the site they control - their blogs1. At the same time, the hope is the hosting platforms make it simpler to book such places online and get them up and running easily.

I think there has already been a huge improvement on this front. There are numerous platforms, like Wordpress, Ghost and others2, that are making it simpler to get your own blogs up and running. They also allow you to link these blogs to your domain without fussing over hosting/maintenance. The promise is simple. Jump in with a free tier — if you are happy and if you want to, just switch to a paid account.

But then comes the million dollars question? What’s the point if what I write reaches no one? If no one reads it or talks about it? If everyone keeps shouting in the void without anyone listening, one better not spend the energy. After all, we are sociable. We like interactions, we want feedback.

RSS is a powerful protocol that could have solved this problem. Unfortunately, that’s what it remained, a protocol3. It needed a system to be built on top to gain any traction amongst masses. That’s where I believe lies an opportunity for Micro.blog. It brings in that social layer to the thoughts you pen on your blog.

You can either host your content there or get your posts from existing blog to the micro.blog timeline. You write on your blog, it’s visible for others on their timeline, just as a tweet or a Facebook post will on their respective siloed timelines.

But it doesn’t allow repost. It does not glorify numbers of likes and comments and followers.

Such behaviours and numbers are the signals for bots to game the machine curation systems. Tristan Harris put this very well during one of his podcasts appearances.

Outrage just spreads faster than something that’s not outrage.

When you open up the blue Facebook icon, you’re activating the AI, which tries to figure out the perfect thing it can show you that’ll engage you. It doesn’t have any intelligence, except figuring out what gets the most clicks. The outrage stuff gets the most clicks, so it puts that at the top.

So what do we do then? As Don MacDonald pondered in one of his posts, is sharing a problem? Shall we just stop sharing?

I doubt that will be effective. It will work when we make it work. We need to take control of what gets presented to us to consume. It cannot be done by a corporate inclined primarily first to maximise its margins. It cannot be done by an algorithm that’s designed to gallop every signal and spit a feed to maximise engagement.

Once we start consuming, reading, healthy, we will think healthy. And we should think. And share, and respond we should. Let’s just make sure it is a space that represents us. A space that one can point to and say that’s my thoughts in there. My social presence, a signature. Let open web be that space.


  1. I use blog and site interchangeably throughout this article. I do not want to get into the technicalities. And I am just focused on individuals, not companies.

  2. A lot many for professional sites too — SqaureSpace, Wix etc. Again, the idea is focusing primarily on individuals.

  3. Of course, I am intentionally jumping over a phase when RSS was the buzz word. In Reader, Google had upped everyone’s hopes from the platform. And in Reader, it dealt RSS a dull shrug.