Hacker News Reader

Thanks for the thoughtful questions. Here are my thoughts on your questions

1. The incentive for a developer is to get better exposure. This is working with the assumption that the metabot has a larger userbase than individual chatbots. In general, the incentive is similar to what causes an online store to setup a 'store' on amazon's market place or retail sites to list on a price comparison engine.

2. As regards the second point, my thoughts when writing the was that it will infact be a direct pass through i.e. the metabot will not need to bother about the structure or nature of the requests/response but will instead focus on knowing about the bots and their capabilities. If it does this effectively, it theoretically pipes all requests for a specific task to the same bot to complete. This comes with it's own complexities as well.

3. To rank bots in the same doamin, an option is to guage the satisfaction of multiple users of the bots. For instance if a bot is faster to complete a flight reservation and the 'user' confirms to the metabot that it is satisfied with the service, that's a positive signal. This can be compared across multiple bots to measure the effectiveness of each bot.

4. Indeed, I agree it will be challenging. But I think the challenge is less of structuring the queries. If the meta-bot acts primarily as a pipe, its most important task is to identify who handles what and know the state of the conversation.

There are a lot of kinks to be worked out though...

Thanks for responding to my questions. I like this discussion so I hope you won't mind me continuing it a bit further 1. Your response is valid for a developer/team creating a bot once standards are in place. This is not the case right now so any bots created right now will need to be refactored.

3. Your response is valid when a meta-bot is tracking bot usage and user feedback on bots. That's what I would call a warm ranking. However cold ranking is when a meta-bot is just starting up and has no usage data about the bots.

4. Even working as a pipe the meta-bot would need to figure out how to pipe the query to a bot especially consider this scenario: The user has asked "Book me 2 tickets and a hotel in San Diego for May 15th". The meta-bot has determined this is a travel query and found that Bot A is highest ranked for travel queries. It pipes the query to Bot A. However Bot A does not understand how to process this query because it excels at processing queries like "Book me 2 economy tickets and a 3 to 4 star hotel for 3 nights in San Diego" and it received high satisfaction ratings when it was queried like that. However in this vague query scenario Bot B does a much better job but the meta-bot won't know about it.

This is fascinating. I have an Amazon Echo and ever since I got it when it was not widely available I've been fascinated with the potential of it and Amazon went in the direction that I predicted it would with that. However Amazon Echo still uses APIs to interact with services and provides a nice NLP interface to it. This is a friction point for getting new things in the Echo and I have been wondering how to remove this friction.

I think you may be overthinking 3 a bit. You only need to use the new bot enough to get enough info for the normal ranking method to work. Some simple solutions:

1. When a new bot is added, always use that bot first. This assumes that the user added it intentionally despite already having bots for that function.

2. If bots are ranked too closely, pick one at random.

3. If bots are ranked too closely, ask the user which to use. Have an option for setting that as default. If you have an Android phone this should feel familiar. This is how Android handles different apps that handle the same function (i.e. what app should open when you click the mailto link).

1. The idea of a meta-bot that the OP puts forward doesn't require user to add any bot. If user had to add every bot manually then it takes away a key advantage of a meta-bot. One bot to rule them all.

From what I (mis)understood, a meta-bot would internally have "friended" other bots and user only adds the meta-bot and interacts with the meta-bot which then sends the queries to its friended bots. Though now that I think about it I probably did misunderstand it. :)

Your description is what I had in mind. The user won't be the one to add the bots, the meta-bot has a strong knowledge of the 'chatbot community' and knows who is good at solving problems in different categories.

The proposition of allowing the user 'add' bots is also quite interesting but I've not given much thoughts to that.

If user is allowed to add bots then you take away one thing from the meta-bot. The task of Discovering relevant bots. At the same time you limit the meta-bot from helping you out with a task if a bot for that task has not been installed by the user.

The meta-bot could technically suggest what bots to install if it does not find an installed bot to perform a task. In the current world of bots I think this would be a more optimal approach rather than a true meta-bot to bot transparent communication.

Also take into consideration that a meta-bot should provide proper attribution to whichever bot it chooses to perform the task otherwise you open yourself up to copyright infringement or equivalent.

If you want to take this offline I've updated my email address in my profile. Don't know if you can see it.

Yeah, we should indeed take this offline. I can't see your email, you can reach me on lumzor [at] gmail [dot] com.

That's interesting. I guess I just assumed the user would have to add the bots. Otherwise how would they know what the meta-bot is capable of doing? Also, discovery of bots, especially ones that aren't "mainstream" (I'm thinking less utilitarian and more art/fun, here) or part of specific bot networks/marketplaces, would be harder. Allowing users to at least also add their own seems like it would be a useful feature.

I guess the meta-bot would use the NLP interface of the other bots. (You need natural language processing and generation anyhow, so you may as well use it as a bot-2-bot interface.)

I think your 4th point is more problematic, when you have a meta bot and the actual interface interacting, then you will get false positives, which in this case means bought/not-bought tickets.