Forem: Francois Falala-Sechet

Language Playgrounds are Cool

Francois Falala-Sechet — Wed, 28 Apr 2021 08:59:35 +0000

A few years ago, we've built an open-source programming language called CSML, that makes it super easy to build powerful chatbots. It's a complete programming language, with loops, conditions, variables etc., and it is super easy to learn as it is close to human language (say stuff, remember stuff, do stuff). It helps handling the conversation state, the user's memory, connexions with 3rd-party APIs...

However, to test it, you need to download a package from Github, find out how to install it, setup your machine and local environment developments... all of which make it hard to simply get started with the language.

So we decided to create an open, browser-based, no-install, no-login IDE. You get the kind of immediate WYSIWYG experience: code something, build, run, see what works (and what doesn't). It's a great place to learn and test your ideas.

Many languages have one, even the hard ones: Rust has https://play.rust-lang.org/, Go has https://play.golang.org/, etc. Then there are the obvious ones, like Codepen or Glitch, for the more common languages. In my opinion, all languages should have one. It makes learning the language a breeze!

If you want to try out CSML, you can do so on our brand new Playground: https://play.csml.dev.

And if you want, you can also support us and leave a review on our Product Hunt launch: https://www.producthunt.com/posts/csml-playground

Hope you enjoy programming languages as much as I do 🤓!

Solving Chatbot-Based User Authentication 🔑: Introducing NoPass.me

Francois Falala-Sechet — Sat, 20 Mar 2021 18:25:38 +0000

Making sure that a user is who they say they are is a very common problem that almost all applications have to solve at one point or another. In the case of a chatbot, you sometimes need to perform actions on behalf of a user, who doesn't necessarily have an account they can authenticate with in the chatbot. How do you verify their identity?

Short answer: with NoPass.me! 🤯

What is NoPass.me?

NoPass.me is an open-source, accountless, identity verification service, dedicated to chatbots. It was created by Clevy.io, the team behind the open-source chatbot-oriented CSML programming language. It lets you easily verify that a user is the rightful owner of an email address (or a phone number, via SMS), by generating and sending a one-time password and validating it on your behalf.

Privacy is at the heart of this service, which you can also host on your own servers, as it is fully open source. For example, while other similar services usually force you to create an identity in their system for each user you want to verify, NoPass.me lets you simply verify any email address without storing any user information.

It is also completely secure. Each email address (or phone number) and authentication code is irreversibly hashed with a state-of-the-art encryption process before it is stored in the database, making it impossible to decode even with privileged access to the data. As no personal information is ever stored in clear text by the service, there is no risk of leaking user information even in worst-case scenarios. The data is also automatically removed either when the authentication code expires or when a code is entered for the user, right or wrong.

Last but not least: NoPass.me is free for up to 5000 email and 200 phone number identity verification API calls. This is perfect for startups and indie devs!

The source code of NoPass.me is entirely open source. I encourage you to go and read it, which is also always a good idea when using a security product.

Using NoPass.me in a Chatbot

To get started with NoPass.me, request a free API key on the website (or install the open-source version), then continue reading this article. I'll wait! 😉

The process for verifying a user with NoPass.me is quite straightforward. There are only 2 easy steps:

Generate an authentication code for the user you want to verify
Get the user to enter the code they received and verify it with NoPass.me

Here is a simple flow diagram of how this usually comes together:

To demonstrate the process, I have created a simple example chatbot on [CSML Playground](https://playground.csml.dev that you can use as a starting point (obviously, you will need to set your own API keys): https://playground.csml.dev/bot/aa958f0d-8fb8-4ead-8905-b17551919eda. Let's break it down and see how it works!

First, we retrieve our target user's email address. In this case, we are simply going to ask for the information but we could also retrieve it from an external API or another part of the conversation.

/**
 * This CSML Chatbot demonstrates how NoPass.me works
 * when used in a CSML chatbot. The same principles apply
 * with every other programming language, as long as there
 * is a HTTP client library!
 */
start:
  say "Hello! 👋"
  say "Before I can give you access to this service, let me verify your identity"
  goto getEmail

getEmail:
  say "What's your email address?"
  hold

  if (!event.is_email()) {
    say "This is not a valid email address"
    goto getEmail
  }

  remember userEmail = event

  goto verifInit

Then, we can initiate the verification process by calling the /verify/init endpoint of the NoPass.me API, using our API key. You can check the full documentation of this endpoint on this address.

/**
 * Initiate the verification process:
 * Let NoPass.me send them an email with an authentication code
 * 
 * The only mandatory parameter is the target email address to verify,
 * all other parameters have sensible defaults.
 *
 * Check the docs on https://nopass.me/docs
 */
verifInit:
  do params = {
    "target": userEmail,
    "target_type": "email",
    "subject": "Your Verification Code",
    "content": "<h1>Hi!</h1><br><br>Your verification code is %code%.",
    "expires_in": 900 // 15 minutes
  }
  do res = HTTP("https://api.nopass.me/v1/verify/init")
    .set({"X-Api-Key": "YOUR_API_KEY"})
    .post(params)
    .send()

  if (!res.success) {
    say "There was an issue with your request. Please verify your parameters"
    goto getEmail
  }

  goto verifCode

After a few seconds, our user receives an email with a random authentication code (more precisely, a one-time password). Let's verify it with the following process, as documented on this page:

/**
 * Finish the verification process:
 * Let NoPass.me check if the given authentication code is valid
 * 
 * Check the docs on https://nopass.me/docs
 */
verifCode:
  say "OK, please check your email and enter the verification code:"
  hold

  do params = {
    "target": userEmail,
    "target_type": "email",
    "code": event,
  }
  do res = HTTP("https://api.nopass.me/v1/verify/validate")
    .set({"X-Api-Key": "YOUR_API_KEY"})
    .post(params)
    .send()

  if (!res.success) {
    say "There was an issue with your request. Please verify your parameters"
    goto getEmail
  }

  say "The code is valid! Welcome!"

Here is the end result of this exact code, when run with a working API key:

As you can see, this process is extremely easy to implement in your own code. This service is particularly helpful in situations where you can not authenticate the user otherwise (using an OAuth or SAMLv2 identity provider for instance) but still need a high degree of confidence that the visitor is who they say they are.

We're extremely happy to launch this very powerful service today and hope that you will use it for your own projects!

👉 Support us by starring the repo on Github: https://github.com/Clevyio/nopass.me

👉 Request your free NoPass.me API key: https://nopass.me

What's New in CSML v1.5.0

Francois Falala-Sechet — Sat, 20 Mar 2021 18:12:30 +0000

We just released CSML v1.5.0! 🎉 Let's have a quick look together at some of the highlights of this release...

Crypto Utils

Most systems nowadays require some sort of specific authentication or encoding to communicate securely. In this release, we introduced support for Base64 and Hex encoding/decoding, creating and validating JWTs, as well as hashing and HMAC functions.

Here are some examples of what you can do with the new Crypto utils:

say Crypto("Hello World 😆").create_hash("sha256").digest("hex")

do JWT(jwt).verify(claims, "HS256", "SECRET_KEY")

do auth = Base64("user:password").encode()
do HTTP("https://example.com")
  .set({ "Authorization": "Basic {{auth}}" })
  .send()

👉 Link to the documentation

Dynamic Steps and Flows

Dynamically navigating to other steps and flows was quite hard and cumbersome to achieve until today. It usually required a long list of if (x) goto y in your code, similar to this example.

Now, you can use the new $ syntax used for referencing variables in flow and step names instead: goto $stepname@$flowname. This helps make code much more concise and reusable!

Using dynamic steps and flows, the example from above can easily be refactored like so:

// redirect to a random flow in a list of possible targets
do flows = ["flowA", "flowB", "flowC"]
do targetFlow = OneOf(flows)

goto flow $targetFlow

👉 Link to the documentation

Bot Environment Variables

Efficiently and securely storing and accessing bot-wide variables (such as API keys, default configuration values, etc.) was quite difficult to do until now in CSML, since it usually required either writing these variables in clear text in many places in your bot, or replicating them in each user's memory.

With the new _env global read-only variable, you can access bot-wide environment variables everywhere in your bot, without ever needing to remember them or replicating the value written in clear text anywhere in the bot.

For instance, if the bot communicates with a 3rd-party API, you can store this value under MY_API_KEY and use it anywhere in the bot with _env.MY_API_KEY.

👉 Link to the documentation

CSML Studio Updates

CSML Studio also received some love with the latest update. Here are some of our favorite new features!

Introducing: Bot Snapshots

It is a good practice to never work directly on your production code, in order to avoid impacting your end users when updating your code. This is why we just introduced Bot Snapshots: you can think of snapshots as git tags or github releases for your chatbot.

Using Snapshots, you can easily create tagged versions of your bot, pin them to your production channels as to not risk any disruption during development, or revert your code to a previous version at any time!

New Bot Sharing Experience

In the latest release of CSML Studio, we changed the way you can share bots with other users. You can now share any individual bot with any user, rather than all of your bots with a group of users who will also share their bots with you in return.

This is especially useful if you are working on bots that you need to share with different sets of users. For instance, if one team is working on a bot and another team is working on a different bot, you can now work on both bots without creating 2 separate accounts or giving access to both bots to both teams.

To invite a user or revoke someone's access to a bot, visit your bot's Settings > Team > Manage team.

In an upcoming release, we will also introduce roles, with differentiated access rights to each bot. Stay tuned!

Other Improvements!

In this latest update, we also released:

a brand new IDE with better support for CSML language, autocompletion and syntax highlighting 👩‍💻
a new "Sign-in with facebook" button to make it easier for facebook users to create a free CSML Studio account 🔑
a standardized experience for NLU-enabled chatbots — check the details here 💬
... and also a lot of little tweaks and bugfixes 🤓

All these new features are already live on CSML Studio. Try them out today and let us know what you think!

How to connect a Google Assistant action with a custom chatbot backend

Francois Falala-Sechet — Wed, 22 Jan 2020 13:24:33 +0000

How easy is it to create a chatbot for Google Actions and Google Assistant-powered devices (Google/Nest Hub, Google Home, etc.)? Let’s find out!

Out of the box, Google does not make it as easy as it seems to connect a voice assistant to a custom chatbot. They are trying very hard to make you use Dialogflow (a Google product since they bought api.ai a few years ago), however there are ways to bypass Dialogflow and connect Actions to your preferred custom chatbot backend, in our case the CSML Studio.

1. Creating the chatbot

For this example, let’s create a simple CSML-powered chatbot that guides users through step by step instructions to fix a printer running out of toner. Not the most fun example, but still very useful as this is one of the most common operations you will have to do on any printer!

As usual creating a chatbot is very easy with CSML: simply describe the steps one by one until you are done with the conversation. One thing to keep in mind is that Google Actions have some specific requirements.
Among the main ones are the following:

No more than two simple text components per step
No more than 640 characters per text component
If you want to display an image, there must be a text before and at least one button after
Same thing with audio files, which will also automatically emit a “FINISHED” event when it is done playing

There are quite a few other rules but these are the main ones that we will be considering today. Here is a link to the documentation so you know what is possible and what are the requirements.

Knowing that, here is the flow we will be using for our Action. It is quite straightforward but of course let me know in the comments if anything is unclear:

start:
  use Button("Yes", accept=["oui", "yes", "y"]) as btny
  use Button("No", accept=["non", "no", "nop", "nope"]) as btnn
  say "Many printer issues come from empty cartridges."
  say Question("Is that your case?", buttons=[btny, btnn])
  hold
  if (event match btnn) goto comments
  say "Let's follow these simple steps to replace your ink cartridge!"
  say "Step 1: Lift up the scanner unit and open the cartridge older."
  say Image("https://cdn.csml.dev/customers/4140eea8-4825-4df6-981d-c1ee239884bc/files/29f64cb9-308b-4ff4-8e7c-ad2dfe20c37b/etape1.jpg")
  say Button("Next")
  hold

  say "Step 2: Remove the yellow tape from the side of the cartridge."
  say Image("https://kb.epson.eu/pf/12/webfiles/Article%20Images/Inkjet%20Printers/yellow_tab.jpg")
  say Button("Next")
  hold

  say "Step 3: Insert the new cartridge into the holder and push it down until it clicks into place."
  say Image("https://kb.epson.eu/pf/12/webfiles/Article%20Images/Inkjet%20Printers/click_in_place.jpg")
  say Button("Next")
  hold

  say "Step 4: Close the lid of the printer."
  say Image("https://kb.epson.eu/pf/12/webfiles/Article%20Images/Inkjet%20Printers/lift_up_lid_old.jpg")
  say Button("Next")
  hold
  goto printerresolved

printerresolved:
  use Button("Yes", accept=["oui", "yes", "y"]) as btny
  use Button("No", accept=["non", "no", "nop", "nope"]) as btnn
  say Question("Did this solve your issue?", buttons=[btny, btnn])
  hold

  if (event match btny) {
    say "Glad I could help!"
    say "Good bye!"
    goto end
  }

  say "I'm sorry I could not help you."
  say "Please open a ticket on Service Now to get additional help!"
  goto end

One more thing to consider is that Google Actions are available on devices with or without a screen. In our scenario we focused on a device with a screen, but remember that some users will not see the images you show them. You might want to provide a different scenario in that case; luckily CSML provides you that information with the _metadata.capabilities.SCREEN_OUTPUT context variable (true or false). You can use it to say different things depending on how your users are using the Action. There are a few other variables available, check them out!

2. Connecting the bot to Actions on Google

Sadly, Google does not make it too easy to connect your action to a custom backend without using Dialogflow — the option to do so is actually quite hidden and not well documented. Most annoyingly, you will need to be able to run a command from your machine, which should not be a problem if you are already familiar with a terminal. Luckily, this is only a one-time setup: once you have done it, you are all set!

Go to the Google Actions console and create a new project:

Select Actions SDK as the type of action you want to build.

This is important to not miss, as other options will not let you connect your own conversational backend to your action!

Actions SDK is not very visible, at the bottom of the screen!

In the next screen, simply copy the project ID from the given command:

gactions update --action package PACKAGE_NAME --project PROJECT_ID

Download and install gactions-cli with the appropriate package for your computer (Mac, Windows, Linux…).
Back to the CSML studio, go to Connectors, then select Create a new Channel, and click on Google Assistant.

Add a name and description for your channel, then paste the Project ID from step 4. In our case, we were assigned project ID fir-csml by Google, as well as the lowercase 2-letter language code for the actions main language (defaults to en if you leave it empty), then click submit.

After submitting, you will be invited to download a gactions package (in JSON format). Download it, then run the provided command after replacing PACKAGE_NAME with the actual path where you saved the gactions package.
The command may ask you to authentify yourself with Google. Go to the provided URL inside your web browser, complete the authentification, copy the provided code and paste it in your terminal where you entered the command before.

Finally, back on the Actions on Google console, go to Develop > Invocation and pick an invocation (how people are going to call your action, for example “Super Demo” — beware, Google has quite a strict naming convention, requiring a 2-word name that does not use one of many forbidden terms).

That's it! You are now all set to test and publish your Google Assistant action made with CSML. I hope this guide was helpful to get started, as Google really does not make life easy with their Actions SDK. Let us know what fun or interesting chatbots you decide to build with CSML!

Managing secrets in CI/CD with AWS Secrets Manager description

Francois Falala-Sechet — Tue, 14 Jan 2020 21:40:11 +0000

Managing API keys, database passwords, and other secret variables in CI has always been a tiny bit painful and often a massive security loophole in most organisations.

Let’s try to see how we can improve the situation with AWS Secrets Manager, this simple wrapper, and your favorite CI provider (in our case, Gitlab CI — but it should work relatively similarly with most providers).

Let’s use AWS Secrets Manager to help you secure your CI stages.

The problem

By definition, secrets are meant to be… secret. But CI should not be a black box, accessible by a few chosen ones, only so that you can protect your precious secrets! CI is basically the last time you get to touch your app before it ships to your customers or users. All developers should be able to inspect the logs of previous builds and run builds on their own.

Let’s start by stating the obvious:

If you can get away in doing what you are doing without using any secrets and just making everything already public, great. But chances are you can’t.
Secrets are obviously meant to be secret, but at least one person will need to know them at some point, and people are weak.
Security through obscurity is not security. Hiding secrets, for example inside CI stages, is not security.

In that case, what’s a good (as in “easy and I can do it without having a whole costly devops team”) way to deal with secrets? Let’s consider your probable situation.

You can setup secrets in the CI provider’s configuration panel. This is great as it enables you to pass any variable to any project very easily. However, when you have hundreds of projects, and quite possibly some shared variables between projects, it can become a little bit difficult to manage. You also need to setup the environment properly before the first build, which means letting someone know of the variable, which means introducing a weak point.

The “Variables” panel inside Gitlab’s CI configuration for a given project.

Secrets usually have a lot of power attached to them (otherwise they wouldn’t be secret). CI stages will often need to retrieve private packages, perform some private task, access a private database, or publish a new release of your app that could ultimately get in the hands of your users. If someone were to get access to a secret used in CI, they usually gain a LOT of power, and it’s not necessarily easy to detect right away.
Perhaps you want to hide your secrets and not make them available to your developers. You can use the “protected” setting above and some security setting in the access rules, but it does not completely prevent developers to log the secret in a hidden part of their code that would miraculously pass all the code reviews (you have code reviews, right?), and there you have your secret available in plain text to anyone with read access to the CI logs — which should be most of your developers, if you ask me.
How hard would it be to replace all your secrets, right now? Let’s say one of your engineers, tasked with setting up these environments, leaves the company. What damage can they do with the keys they know? What if a database password, used in a few different projects, needs to be replaced for some reason — in how many places is it used across all your repositories? Do you really want to spend half a day updating 50 repositories every time somebody leaves the company, or as a routine task every few weeks because your policy says you should rotate all secrets regularly?

So, what can we do?

The only way to make your secrets more secure (given the limitation that you can not get away with not having secrets at all, AND no matter what you do to prevent it, people will be able to access them one way or another at some point) is to make them more volatile. They should be revokable at any given time, without causing much damage, and as often as possible.

You should not care about who knows about what secret at any given time (because people will find out).

The only way you can practically consider revoking your secrets often (and not spend a considerable amount of time manually replacing them everywhere if you have hundreds of them) is to have them managed centrally.

You should not care about having to replace the secret every once in a while (because it’s a painless operation).

The only way you can guarantee that secrets will be revoked often is by automating their rotation. Human is lazy, forgets, goes on vacation, is busy, sleeps…

You should not care about this at all because you have better things to do.

Secrets are meant to be volatile.

I think the problem lies in the word secret. People naturally think that secrets are effectively secret AND rely on them to stay secret. The truth is, secrets do get exposed. It is an unavoidable part of their lifecycle: the longer a secret stays in place, the higher the risk that it gets exposed, and then what?

If your entire business relies on the sole concept of secrets staying secret, I feel sorry for you.

On the other hand, if you actively prepare for your secrets to be exposed at some point, and make it a natural event of your application to just casually change secrets every once in a while without having to even think about, then you solve a much, much large issue: peace of mind. It is very, very comparable to the concept of continuous integration: deploying to production often makes it an absolute non-event.

Consider you are terrible at security. Consider any secret as compromised if it does not get recycled every few hours/days/weeks. Make the rotation of your passwords a non-event. It’s as natural an operation as it gets.

Secrets are a volatile piece of data, nothing more.

Enter AWS Secrets Manager

AWS Secrets Manager is a relatively new service by AWS which is similar to some sort of API-fied, cloud-enabled, 1Password on steroids.

Basically, your main password is as usual with AWS, your AWS credentials (instance role, IAM user, etc.), which gives you access to fine-grained access settings (who can read/update secrets stored in the service). I am not going to go into how to setup an AWS account or the basic IAM concepts here, there are countless great resources about it online! Let’s consider you can access the AWS console, and know how to do so, and have heard about IAM before.

The main features we are interested in here are:

Centralize management of as many secrets as you want without making them directly available to any particular entity. Instead, they are meant to be consumed on-demand, by using regular AWS credentials, and limiting access via standard IAM rules. This is a great example of responsibility separation by design: use IAM for ACL, Secrets Manager for safe secrets management, and combine both on demand. Secrets should not care who has access to them as it should simply be considered as a piece of data, and by defining group or role based ACLs, you can give or revoke access to any secret values at all times.
Automate secrets rotation as often as you like with a Lambda function. Set once and forget. What this buys you is that as soon as you revoke access to Secrets Manager to anyone (or anything), they might still access the current secrets for a little while, but as soon as this rotation script runs… who cares what secret they know?

By making secrets access volatile and identity-based, this service solves a bunch of security problems for all devops engineers who don’t need to reinvent the wheel for secrets management (or put their whole company’s security at risk if they don’t address it properly).

Using AWS Secrets Manager in CI/CD

Since the setup of AWS Secrets Manager takes about 5 minutes, the main complexity is to make this easy to integrate into your CI project. To help you with that, we released https://hub.docker.com/r/clevy/awssecrets, a tool that helps you retrieve secrets to use in your projects’ CI steps. If you prefer to build from source for something this sensitive (you should), you can find them here: https://github.com/Clevyio/docker-awssecrets

The following is our current production setup:

Private gitlab runners on EC2 instances with a GitlabCiInstance IAM role attached. These instances run in a VPC, which means that their access to/from outside is enforced by any security rules we can control.
An IAM policy for limiting read access to Secrets Manager, attached to the GitlabCiInstance role access that looks something like this (you can of course limit what secrets it has access to, but you get the idea):

{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Sid": "GitlabCiPolicy",  
            "Effect": "Allow",  
            "Action": [  
                "secretsmanager:GetSecretValue"  
            ],  
            "Resource": "*"  
        }  
    ]  
}

Some secrets stored in AWS Secrets Manager with auto-rotation enabled, some projects in our gitlab repositories with CI enabled, etc. :-)

The following would resemble a typical .gitlab-ci.yml file defining our CI process, with usually a first step that looks like this:

secrets:
  stage: secrets
  image: clevy/awssecrets
  script:
    - awssecrets --region eu-west-1 --secret my-secrets > .ci-secrets
  artifacts:
    # you want to set this to a value high enough to be used in all your stages,
    # but low enough that it gets invalidated quickly and needs to be regenerated later
    expire_in: 30 min
     paths:
      # this will be available by default in all the next stages
      - .ci-secrets

A few things to note here: there is no need to pass AWS credentials to aws secrets: remember, the instance has a role attached to it that automatically gives access to the service! So all calls are “automatically” authed, and there is no risk of leaking AWS credentials that could give access to your secrets, as this must be used in an instance role in an authorized EC2, which you do not want to grant to just anybody.

This will produce an artifact, which is a fancy word for any file or folder you decide to pass to later stages. In our case, we have simply created a .ci-secrets file. This file looks like this:

SOME_SECRET=poepoe
OTHER_SECRET=tutu
VERY_SECRET=lalala

Because we set a expire\_in value, gitlab will automatically remove the artifact after 30 minutes. If your CI process take longer to run, of course you can adjust this duration. With this feature you can somewhat control the risk of leaking secrets in the long run, but it is not technically a security measure!

Then, in the following steps, you can simply use the .ci-secrets file that was just created:

release:
  stage: deploy
  image: node
  before_script:
    # export the contents of the secrets file in your environment
    - export $(cat .ci-secrets | xargs)
    - echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" >> ~/.npmrc
  script:
    - npm install -q
    - npm publish

This step effectively publishes an image on a npm repository, so this secret contains a NPM_TOKEN with write access to a package— quite sensitive!

Worst case scenario

Let’s consider a few plausible worst case scenarios directly concerning your secrets. (I am not going to consider a scenario like “somebody got access to my gitlab runner instance and can do whatever they want because of the instance role”: this is a completely different security issue, not linked with exposing secrets, and should normally be taken care of at least with VPC and security group access rules.)

Somebody from your organisation that you absolutely trust gets full access to the CI configuration and somehow manages to output all your precious secret variables in clear text in the CI logs, making them visible to anyone else with read access. Shit happens! Now one of your employees saw those, got terminated the following day, returns home and wants to hurt you badly. Since we have setup AWS Secrets Manager for auto-rotation of our keys every day, by the time they get home the token will already have been rotated. They try to use the NPM_TOKEN above, but get a 403 Forbidden error, and move on with their lives.
Somebody outside of your organisation somehow got access to some very secret variable and you urgently need to replace it everywhere: simply run the rotation function once and go back to bed, you deserve it!

Conclusion

My take on this is that we should stop worrying about secrets at once and just make them volatile. Of course you shouldn’t put secrets in clear text in public repositories. But maybe you were drunk one night, tried to do something stupid at 3AM, forgot to update the .gitignore and published them in clear text. You are only human!

What do you think?

Announcing CSML, a new open-source language dedicated to building powerful, enterprise-ready and interoperable chatbots

Francois Falala-Sechet — Tue, 14 Jan 2020 19:40:54 +0000

Chatbots are a powerful tool as a universal UX to solving automation issues at scale. Like the web before, followed by mobile applications, chatbots are very good at providing an easy-to-use interface for end users to effortlessly perform repetitive or complex actions in a natural interface.

However, creating a scalable, enterprise-ready chatbot today is still unnecessarily complex. All chatbots in 2019 are created with one of only two methods: either by using any of the available free or inexpensive drag and drop graphical tools, which enables non-technical people to get started quickly, but scales very poorly, can not be versioned using standard tooling, and does not easily allow for exportation (strong vendor lock-in); or by using a generic programming language (javascript, PHP, python…), which lacks a common standard, requires a lot of unnecessary and repeated boilerplate to achieve even basic features like memory handling, and often induces high development costs and slow goto market.

Market consolidation has already proven that Javascript has won the battle for the web, and most serious iOS applications today are written in Swift, while Java is used for Android applications. As most large companies worldwide are now involved in at least one conversational program, the underlying technology and tooling is outdated and due for a global standardisation.

Introducing CSML, a new programming language for conversational design

The Clevy team is proud to release today a new solution to this long-standing problem in an open beta program: the Conversational Standard Meta Language (CSML), a common language for all chatbots.
CSML’s objective is to make designing conversational experiences as intuitive as possible, drastically reducing the time and costs to create and deploy any chatbot at scale compared to all existing platforms and make it as easy as possible to connect any human with any machine.
Written itself in Rust (a low-level, fast, memory-efficient and safe programming language), and fully Turing-complete, the CSML acts as a linguistic/syntactic abstraction layer, designed for humans who want to let other humans interact with any machine, in any setting. The syntax is designed to be learned in a matter of minutes, but also scales to any complexity of chatbot.

CSML automatically does the heavy-lifting of all conversational concepts without any added complexity for the developer: memory, context, metadata, message formatting for the target channels, conversational logic, interoperability with third-party systems, API-agnostic integrations…

The documentation of the language is publicly available on https://docs.csml.dev. We also provide a free, full-featured development studio (REPL) on https://studio.csml.dev.

All conversations start with a common language

The principle used by CSML is to treat the entire conversation as a series of separate events, linked by the same conversational context, instead of request by request. Each event is a reaction — potentially cumulatively — to the event preceding it; a trigger for an event that must follow it; or totally independent.

Nominally, the language itself is structured like the train of thought of a young child: everything is sequential and consists of descriptions. When asking a child about their day, they would usually answer somewhat like:

I went to school, and then I had lunch, where I ate a steak and fries, then I played with my friend Kevin, and then we had ice cream.

This also means that after this last part, the conversation can end there, continue (“do you like ice cream?”) or a new subject can be picked up (“let’s go to the swimming pool now”). The sequential nature of a child’s reasoning makes a great comparison with how current chatbots can handle conversations: as a stream of individual bits of information, that can either be taken independently, or attached to other bits of information in a sequence.

Either way, a child learns from their interactions. The more the bot chats with the user, the more it learns about the user and their preferences. Everything is memorized and saved in the bot’s memory about the user to be reused later, so that no information needs to be asked twice.

We have worked for many months with computational linguists to transpose this inherent logic of natural conversations (and not just natural language) into the CSML. The result is an incredibly simple and natural framework to build just any chatbot about as easily as imagining a conversation.

A simple CSML chatbot flow to receive non-stop cat gifs 😸

Connecting humans with any machine

CSML is designed to be interoperable with any API-enabled third-party system. We understand that many of our users will want to run their own code directly inside the conversational engine, which is why we make it possible to integrate any language runtime (using any FaaS platform, in the cloud or on-premise) that enables chatbot developers to execute custom code in Javascript, Python, Go, Java, C#, or interconnect with their other systems natively from any CSML script.

The immediate benefit is that CSML makes it possible to reuse existing code with no or very little modifications, or use built-in connectors with popular systems (ServiceNow, SAP, Microsoft Office 365, Zapier, Workday, Salesforce…) or communication channels (Messenger, Teams, Slack, Workplace, Discord, Skype, Hangouts, Alexa, Google Home, Twilio, websockets…).

CSML is open-source

We are committed to helping the community benefit from this new programming language as much as possible.

To ensure that any entity, company or person, involved in a conversational program, can commit to using this new game-changing language, we will be releasing the full CSML source code in the coming months.

Chatbots are no more than natural interfaces to machines. As a language dedicated to creating chatbots easily, the CSML engine natively includes a modern package system, allowing developers to create, share, or download reusable bots or parts of bots. We will also be providing original content (bots, functions, integrations…) in the form of plugins, that can be added to any bot as installable dependencies.

CSML is secure

One of the side-effects of open-sourcing the CSML is that you can ensure that nobody can ever access your previous customer data by running it on your own servers. Some of our early users have been using the CSML in entirely private environments, sometimes even inaccessible from the internet; others prefer to run it in their own cloud environment: by default, CSML comes with easy-to-use bindings to AWS services like DynamoDB for storing the bot’s databases and AWS Lambda to execute code in any major programming language, in addition to SQLite and FaaS platforms like OpenFaas or FnProject for custom runtime executions. The CSML engine also comes with easy-to-deploy, stateless Docker containers.
In addition to network separation and deployment flexibility, one of the leading design principles of CSML has been to ensure that all data is stored safely and securely: by default, all sensitive user data is stored encrypted using strong 256-bit AES encryption — the gold standard for military-grade encryption.

CSML is scalable

CSML is built with large enterprises in mind, who want to go beyond the proof-of-concept phase without inducing immense development and product management costs, while not limiting themselves in what they can or can not do with their chatbot. We want to empower developers to create what they want without technical barriers. We want to make sure that CSML chatbots can accept any number of conversations. We want to make CSML available in the cloud, on-premises, or even offline.

The architecture of the CSML engine was designed to address all these constraints and handle any number of conversation, from a few to a few millions, without any restriction. Small bots can be created in minutes, then expanded to any arbitrary size of enterprise-grade bots later. With CSML, you are in control of your chatbot development project with very little boilerplate and a standardized lifecycle and development process, maximizing return on investment for your team.

Build your CSML chatbot in minutes!

If you are intrigued by this new language, give it a try! You can setup your chatbot in minutes by signing up for free to the beta at https://studio.csml.dev.