We are thrilled to announce an exciting partnership between Symbl.ai, the leader in Understanding and Generative AI for Conversations, and Recall.ai, the universal API for meeting bots. This collaboration marks a significant milestone in empowering developers and organizations to extract actionable insights from their meeting data like never before. By combining the advanced capabilities of Recall.ai with the cutting-edge technology of Symbl.ai and Nebula, our recently announced conversation LLM, we are revolutionizing how businesses understand and leverage their conversational data.

export SYMBLAI_APP_ID="<YOUR_SYMBLAI_APP_ID>"
export SYMBLAI_APP_SECRET="<YOUR_SYMBLAI_APP_SECRET>"

export RECALLAI_API_KEY="<YOUR_RECALLAI_API_KEY>"

curl -X POST https://api.recall.ai/api/v1/bot 
    -H 'Authorization: Token '$RECALLAI_API_KEY' 
    -H 'Content-Type: application/json' 
    -d '{
          "meeting_url": "https://symbl-ai.zoom.us/j/86101209066?pwd=Z2V1QzJLbGRUZEJrVlk5Zy9PbE1udz09",
          "bot_name": "Bot",
          "transcription_options": {
            "provider": "symbl"
          }
        }'

{
    "id": "657365b8-04b7-41ba-bad6-3de0da346bb8",
    "video_url": null,
    "recording": "482d3192-6b4b-49ca-aadb-c0cf6957e187",
    "status_changes": [
        {
            "code": "ready",
            "message": null,
            "created_at": "2023-06-20T23:27:28.926697Z",
            "sub_code": null
        }
    ],
    "meeting_metadata": null,
    "meeting_participants": [],
    "meeting_url": null,
    "join_at": null,
    "calendar_meetings": []
}

export RECALLAI_BOT_ID="<YOUR_RECALLAI_BOT_ID>"

curl --request POST 
     --url 'https://api.recall.ai/api/v1/bot/'$RECALLAI_BOT_ID'/leave_call/' 
     --header 'Authorization: Token '$RECALLAI_API_KEY'' 
     --header 'accept: application/json'

curl --request GET 
     --url 'https://api.recall.ai/api/v1/bot/'$RECALLAI_BOT_ID'/transcript/' 
     --header 'Authorization: Token '$RECALLAI_API_KEY'' 
     --header 'accept: application/json'

curl --request GET 
     --url 'https://api.recall.ai/api/v1/bot/'$RECALLAI_BOT_ID'' 
     --header 'Authorization: Token '$RECALLAI_API_KEY'' 
     --header 'accept: application/json'

{
    "id": "657365b8-04b7-41ba-bad6-3de0da346bb8",
    "video_url": "...some URL…",
    "recording": "482d3192-6b4b-49ca-aadb-c0cf6957e187",
    "media_retention_end": "2023-06-28T00:20:26.904067Z",
    "status_changes": [
        {
            "code": "ready",
            "message": null,
            "created_at": "2023-06-20T23:27:28.926697Z",
            "sub_code": null
        },
       …
        {
            "code": "done",
            "message": null,
            "created_at": "2023-06-21T00:20:26.904067Z",
            "sub_code": null
        }
    ],
    "meeting_metadata": {
        "title": "David vonThenen's Zoom Meeting"
    },
    …
}

export RECALLAI_RECORDING_ID="<YOUR_RECALLAI_RECORDING_ID>"

curl --request GET 
     --url 'https://api.recall.ai/api/v2/recordings/'$RECALLAI_RECORDING_ID'' 
     --header 'Authorization: Token '$RECALLAI_API_KEY'' 
     --header 'accept: application/json'

{
    "id": "482d3192-6b4b-49ca-aadb-c0cf6957e187",
    "outputs": [
        {
            "id": "d297b8c8-6990-4ab2-8030-0fc797a21d2d",
            "type": "active_speaker_diarized_transcription_symbl",
            "metadata": {
                "connection_id": "c5d6b9c4-3194-4126-b30c-b3f4ddcd40d4",
                "conversation_id": "6207479207952384"
            },
            "endpoints": []
        }
    ],
    "created_at": "2023-06-21T00:11:34.372026Z",
    "expires_at": null
}

export SYMBLAI_CONVERSATION_ID="<YOUR_SYMBLAI_CONVERSATION_ID>"

curl --url https://api.symbl.ai/oauth2/token:generate 
  --header 'Content-Type: application/json' 
  --data '{
    "type": "application",
    "appId": "'"$SYMBLAI_APP_ID"'",
    "appSecret": "'"$SYMBLAI_APP_SECRET"'"
}'

{
    "accessToken": "...YOUR_ACCESS_TOKEN…",
    "expiresIn": 86400
}

export SYMBLAI_ACCESS_TOKEN="<YOUR_SYMBLAI_ACCESS_TOKEN>"

curl --request GET --url 'https://api.symbl.ai/v1/conversations/'$SYMBLAI_CONVERSATION_ID'/messages' 
     --header 'accept: application/json' 
     --header 'authorization: Bearer '$SYMBLAI_ACCESS_TOKEN''

curl --request GET --url 'https://api.symbl.ai/v1/conversations/'$SYMBLAI_CONVERSATION_ID'/trackers' 
     --header 'accept: application/json' 
     --header 'authorization: Bearer '$SYMBLAI_ACCESS_TOKEN''

curl --request GET --url 'https://api.symbl.ai/v1/conversations/'$SYMBLAI_CONVERSATION_ID'/summary' 
     --header 'accept: application/json' 
     --header 'authorization: Bearer '$SYMBLAI_ACCESS_TOKEN''

curl --location 'https://api-nebula.symbl.ai/v1/model/generate' 
--header 'Content-Type: application/json' 
--header 'ApiKey: '$SYMBLAI_NEBULA_TOKEN'' 
--data '{
    "prompt": {
        "instruction": "Identify the main objectives or goals mentioned in this context concisely in less points. Emphasize on key intents.",
        "conversation": {
            "text": "DROP IN CONVERSATION TEXT HERE"
        }
    },
    "return_scores": false,
    "max_new_tokens": 2048,
    "top_k": 2,
    "penalty_alpha": 0.6
}'

Remember to refer to the API documentation provided by both Symbl.ai and Recall.ai for additional features, parameters, and examples to further extend the capabilities of this integration. I highly recommend taking advantage of Symbl.ai’s conversation APIs and to get the most out of your conversations, leverage Nebula to elevate your conversation understanding.

Stay tuned for future updates and enhancements as both platforms continue to evolve, helping you stay ahead in the conversation analytics space. If you have any questions or need additional help, don’t hesitate to reach out to the Recall.ai and Symbl.ai support teams. Happy conversing!

The post Extract Insights using Symbl.ai’s Generative AI for Recall.ai Meetings appeared first on Symbl.ai.

Mark your calendars for the upcoming Symbl.ai Community Meeting this Wednesday, July 26th! We have an exciting announcement to make: the availability of the Symbl.ai LLM called Nebula. If you’re curious about what Nebula has to offer, this is the perfect opportunity to join our vibrant community and expand your knowledge. Don’t miss out on this groundbreaking session!

The post July 26 Community Meeting: Meet Nebula, Symbl.ai’s LLM appeared first on Symbl.ai.

The discussion topics will include:

• An introduction to Large Language Models (LLMs), discuss what LLaMA (Large Language Model Meta AI) is and how it differs from ChatGPT
• An introduction to BabyAGI and AutoGPT and how they differ from each other
• Finally, we will discuss the differences between Generative AI and Task-Driven AI Agents

If we still don’t have your attention, I think the demos (yes, plural) for this meeting should be pretty cool.

This month’s meetings will be taking place:

• Americas – Wednesday, June 28th at 11 am PST – Invite (Convert to your Timezone)
• Asia-Pacific – Thursday, June 29th at 8 am IST – Invite (Convert to your Timezone)

We invite you to come to learn more about LLMs and Generative AI, ask questions, or join in the discussion related to conversation AI/ML.

What is the best way to do that? Just…

• Join the Symbl.ai Google Group
• Add the Community Calendar to your Google Calendar
• Then if you have topics for discussion, add them to Agenda Doc

Whether you are information gathering, in development, or utilizing LLMs/Generative AI, knowing what lies ahead can be incredibly advantageous. It promises to be an engaging discussion!

Since we grabbed your attention, here are other happenings within the community…

Expanded Weekly Office Hours

We have expanded our weekly Office Hours to include the time slot of Tuesday at 6 pm PST, and we continue to have the Friday at 10 am Pacific session as well. Office Hours is an informal gathering – not recorded – without a predetermined agenda or curated presentations.

The primary goal is to create a comfortable and secure environment for open discussions, which means no meeting notes or recordings will be taken. Whether you seek assistance with a specific problem, wish to engage in conversation regarding topics related to conversation AI/ML, or want to discuss something unrelated, we encourage you to stop by!

Join the Symbl.ai Google Group to get Access to the Google Calendar.

• Add the Community Calendar to your Google Calendar
• Office Hours will occur every:
  • Tuesday at 6pm PST – Invite – (Convert to your Timezone)
  • Friday at 10am PST – Invite – (Convert to your Timezone)

We are excited to hear from and engage with the community in all the events happening in June. We look forward to seeing you all there!

May 2023 Community Meeting Recap

In our May 2023 meeting, we discussed Enterprise Conversations Architectures. We looked at an off-the-shelf and free-to-use implementation available for anyone interested in building out a scalable conversation-based application. The code is open source and provides a pluggable infrastructure where anyone can easily extend the functionality to fit their business needs or reuse some existing community-developed plugins.

The slides have been posted, as well as the recording for the meeting, which you can view below:

To find out more information about the projects, you can visit the GitHub pages below:

• Enterprise Conversation Application – https://github.com/dvonthenen/enterprise-conversation-application
• Enterprise Conversation Plugins – https://github.com/dvonthenen/enterprise-conversation-plugins 

I hope you see everyone at the June Community Meeting. See you there!

The post June Community Meeting: Large Language Models and Generative AI appeared first on Symbl.ai.

To help answer these questions and go deeper with some real-world examples, we’ll cover data retention through the lens of security and privacy in this post. This includes the various sources of conversation data, the reasons why you need to store these conversations in the first place, why it’s critical to have a conversation data retention policy, and finally, the latest best practices for conversation data retention.

Today’s Conversation Data Sources

The ways we collect conversation data today can take on many forms since the primary vehicle for communicating between individuals is in some form of language, whether it be via voice or video, or written text. There are also many forms of communication that occur visually, such as sign language, and ways of communication that aren’t written per se, but are more tactile in nature, such as braille.

For this post, we’ll focus on written and spoken communication because it covers the majority of use cases related to conversation data retention, but that isn’t to say the other forms aren’t important. In fact, it’s incredibly fascinating to witness all the work being done intaking these non-verbal forms of language and making them digital. For example, using image recognition to convert braille to text.

In spoken word, your input sources include video conference applications like CPaaS platforms (i.e., Zoom, Agora, Vonage, etc.), more traditional forms like Telephony via SIP, WebRTC or PSTN, or even recorded audio/video, such as a sales meetings, contact center interactions, or media like a podcast, Instagram video, or YouTube video. We often think of these things first because these are the mediums we consume most frequently and in overwhelming amounts today. We also cannot forget about written communications, including emails and Slack messages, and social media interactions taking place on platforms such as Twitter, Facebook, and LinkedIn.

All of these conversations in all these formats are being stored today, and it’s essential to understand what these mediums are used for and the content of the conversations. That brings us to our next topic…

Motivations for Storing Conversations

Now, the requirements for storing conversation data can vary based on your use case, business or industry, but generally speaking, the most common reasons for maintaining persistent storage of this data include:

• Historical Context: Enables you to aggregate conversations over time to uncover patterns occurring within your business and then act on them.
• Analytics: Different from observable patterns, conversations can yield quantitative data and insights, such as how often do things occur and when.
• Data Labeling: Obtains metadata about your conversations and provides context about what is being said. These are things like referenceable entities, questions, action items, and other insights into your conversations.
• Reinforcement Learning: Provides business domain-specific insights by feeding conversation data into your own AI/ML workflows.
• Taking Action: Enables real-time identification of actions to take as a result of conversations, including automated follow ups and next steps to move conversations forward, such as a sales engagement or process.

Use Case: Healthcare

The healthcare and medical industries are under intense, ongoing pressure to protect patient data and privacy, and rightly so. This sector is seemingly at the intersection of most, if not all, of the most significant privacy concerns today. This includes protecting patient medical records and history, but also other areas, such as credit payments (look into Payment Card Industry Data Security Standard [PCI-DSS]) and 3rd party records/references from insurance companies. Adhering to compliance standards including PII, HIPAA, GDPR, and EDPA UK, for example, are the first line of defense for keeping our records and identity from becoming public. But, there’s more to do…

The first obvious line of defense to keeping your data private is keeping records generated by the medical institution itself private. That covers everything from new patient intake forms to medical charts to prescribed medications. The reason for this is that there are a lot of things that can be inferred when bad actors gain access to even a few medical records. For example, if John Doe is currently taking some form of penicillin, you could infer that John has some form of bacterial infection. Then the strength of that antibiotic could spell out the severity of that infection, and so on.

Keeping these records private becomes an ongoing challenge because medical institutions bound by HIPAA, for example, need to keep medical records for at least 6 years from the date of creation or in last effect, whichever is later. Maintaining those records confidentiality takes discipline over a great deal of time. The good news: There are easy out-of-the-box methods that Symbl.ai can provide to help, such as Redaction capabilities to hide personal identification information and protect patient privacy.

Now, it’s critical to understand conversation aggregation and connecting the dots of information to find relationships between seemingly unrelated things. As in the previous example, the relationship between John Doe’s medication and the severity of his illness. In this case, that happens to be negative because you’re talking about pulling on a string of information to unravel more details about an individual. The good news is that if you are embracing the idea of using enterprise conversation applications, this might be an easier issue to address because to protect relationships between data, you first need to identify the connection and then redact or obfuscate it.

Use Case: Social Media

Now, let’s take at look at a use case that’s dramatically different in terms of the industry’s goals and audience: Social media.

Social media is a fascinating medium. These days it seems like the objective is to get as many “likes” or “followers” as possible, but the reality is influencers are trying to build a brand around themselves or their interests. That’s usually achieved through creating an enormous amount of content. Why? There are many reasons, but if we stick to monetary reasons, it’s mainly for either affiliate sales, advertising, or paid content to make money. Understanding motivations helps us understand the business, and these businesses are primarily focused on consumerism, at least for those using it for a substantial amount of their income.

If we are talking about consumers, the audience is literally anyone and everyone, but since we’re talking about the interwebs, a good portion of that audience is younger, and therein lies the problem. In the United States, regulations like COPPA, or Children’s Online Privacy Protection Act, play an interesting role in what data can be collected and, more importantly, stored relating to minors under 13. In those cases, you want the TTL, or the expiration date, to occur instantaneously, thereby not collecting that information at all.

If we look beyond minors under the age of 13 and to those that are 14 and older, the information that can be collected and stored from social media interactions can drastically vary, depending on the domain or subject.  If you aren’t subject to regulatory compliance, there are some minimal prerequisites required by your local, state, or federal government. In the worst case, those regulations tend to be the “better to be safe than sorry” self-imposed requirements. In the United States, this could be something like the Federal Information Security Management Act (FISMA), which requires data retention for 3 years, for example.

Let’s Talk About Retention Policies

Now that we have defined some examples of the types of conversation data to store, it’s important to create policies addressing those requirements. To do that, you need to look at the lifecycle of a single bit of information and the journey it takes. This is usually defined in the following stages:

• Creation
• Storage
• Access
• Archival
• Deletion

The creation phase is pretty straightforward. We need information or input to do something within the business, so we ask the user for it. This minimally contains something representing a timestamp to record when this data was created.

Once we’re done using that information, we store that information usually using some database that at some point lands on disk. Why? We need some form of persistent storage to keep all of this information so that it can be reused and recalled later. Check out this recent post on Data Persistence for Conversation Applications to learn more on this specific topic, including best practices when storing data of any kind.

If your applications and business require saving data, you need to be able to recall that information quickly. There are entire software systems from SQL, NoSQL, graph, vector, etc., that devote their entire existence to storing and retrieving data, but the more relevant topic for this post is when your retention policy needs to delete this information. To do that, you need metadata containing when that information was last accessed. As noted above, many regulatory bodies require data to be deleted after a period of time from last access.

If older data is not particularly relevant to your business’s day-to-day operations, you might have a process that places this data into archival storage. Why? There are two main reasons: 1) you need to hang onto this data until you find it useful, but before a specific date to remain in compliance, so you can’t just delete it, and 2) primary storage is expensive. Suppose you have the budget and find a reason for keeping this information around because you know it will be accessed and useful at some point. In this case, you need to have physical storage strategies to be able to expand the storage capacity. Otherwise, you can migrate that data into some archival system where you no longer intend to access it unless there is some external motivation to do so. For example, providing evidence in a legal matter like a court case.

The final stage on the journey of data is deletion. There may be cases where you don’t need to archive data since it’s immediately deleted (i.e., COPPA). But, if you store any conversation data, you should have a strategy to remove it, if needed. Removal is a tricky word. Removal could mean leaving it in the archives, but you don’t actively perform any maintenance on it or… lose the references or anonymize the data so you can’t recall who it is, etc. In some cases, deletion means deletion because of regulatory compliance, and at other times… well, as the saying goes, if it ends up on the internet, it lives there forever.

Key Takeaways

In closing, here is the TLDR on conversation data retention policies:

• Know what regulatory bodies and laws apply to your business.
• EVERYTHING is collected these days, know the reasons why.
• Know what classification your data falls into, including public, HIPAA protected, COPPA protected, etc.
• Remember that EVERYTHING is stored in some form today and you need to know where your data is stored at all times.
• Data lives on disk in different forms due to regulations, security, and even cost, know what types of storage your conversation data lives on.
• Eventually, data is deleted, be sure you know when that happens and for which datasets.
• Know what “deleted” truly means for your organization.

If you know the answer to these questions for your business, that’s a great starting point. If the process is documented, you’re half-way there. If there is a design specification and a way to visualize all of these buckets of data down to the leaf node of individual data, that is truly spectacular!

Being able to develop a conversation data retention policy for your business is instrumental in avoiding accusations of misappropriating data, risks when systems are compromised in data breaches, and even helping your bottom line to properly store your data using the most effective means based on your retention requirements. Usually, you only hear of failures in managing data retention policies when something catastrophic happens, and it ends up on the evening news or front pages in the form of personal data breaches or data loss because someone accidentally deleted something.

So, be proactive with your conversation data retention policy because it could avoid that 3am in the morning phone call from production support!

If you’d like to learn more, reach out to us today!

The post Know the Security and Privacy Implications of Conversation Data Retention appeared first on Symbl.ai.

## April Community Meeting Recap

At our April Symbl.ai Community Meeting, we examined all the things you need to know about OpenAI and ChatGPT, covering both the pros and cons. We also discussed this thought-provoking integration between Symbl.ai and ChatGPT centered around this GitHub project: https://github.com/dvonthenen/chat-gpeasy 

If you are interested in learning more about ChatGPT, along with getting a quick walkthrough of some notable APIs, you can find the April Community Meeting recording below. If you have any questions regarding the project or the content of the meeting, stop by the Symbl.ai Public Slack and drop us a line.

## Up Next: May Community Meeting on Enterprise Conversation Applications

We are excited to announce the topic for our upcoming May Community Meeting, which is on enterprise conversation implementations! In this meeting, we will cover enterprise architecture, use cases and features, and how they relate to conversation-enabled applications.

The aim of this community meeting is to drive a conversation between attendees with an open exchange of questions and answers, as well as sharing ideas surrounding enterprise application requirements (think regulatory compliance, data retention policies, data security, etc). If you aren’t familiar with what enterprise architectures looks like or the capabilities, you can find more information in the blog posts below: 

• Understanding Enterprise Architectures for Conversation Aggregation
• Enterprise Reference Implementations for Conversation Aggregation

Below are the dates that the May community meetings that will take place:

• Americas – Wednesday, May 24th at 11am PST – Invite (Convert to your Timezone)
• Asia-Pacific – Thursday, May 25th at 8am IST – Invite (Convert to your Timezone)

We invite you to come learn more about Enterprise Architectures, ask questions, and discuss random topics related to conversation AI/ML at this meeting.

What is the best way to do that? That’s easy! Just…

• Join the Symbl.ai Google Group
• Add the Community Calendar to your Google Calendar
• Then if you have topics for discussion, add them to Agenda Doc

Even if you aren’t at the point of enterprise implementations and scale just yet, it’s extremely helpful to know what’s in store when that time arrives. We’re sure our May meeting will make for an exciting conversation!

## Establishing Weekly Office Hours

We’re also pleased to announce that we’ll be holding weekly Symbl.ai Community Office Hours every Friday at 10am Pacific Time. During Office Hours, there will be no set agenda or curated presentations. The idea is to provide a welcoming, safe space for discussion… so there will be no meeting notes and no recordings. Whether it’s to get help with a problem you’ve been having, chat about anything related to conversation AI/ML, or anything off-topic, we would love to hear your thoughts.

Join the Symbl.ai Google Group to get Access to the Google Calendar.

• Add the Community Calendar to your Google Calendar
• Office Hours will occur every Friday at 10am PST – Invite – (Convert to your Timezone)

We are excited to hear from and engage with the community in all the events happening in May! We hope to see you all there!

The post Symbl.ai Community News: April Recap, Join Us for Exciting May Events appeared first on Symbl.ai.

Thick clients are making a comeback, which is a stark departure from older design patterns like Model-View-Controller (MVC) or the modern version of that, being Microservice architectures. There are (too) many reasons why these design patterns dominated implementations for decades and why Thin Clients, or clients focused on display artifacts only, became the predominant standard for applications.

With this current rise in the use of thick clients, I thought it might be an excellent opportunity to review the security implications of thick clients and maybe even look through the lens of penetration testing and things to watch out for.

# Improper Access Control: Locking Down Your App

Improper Access Control is one of the most common vulnerabilities that can be exploited in thick client applications. This vulnerability occurs when an application doesn’t properly limit access to sensitive data or functions. Hackers can take advantage of this by accessing data or performing actions they shouldn’t be able to access. Since, by definition, thick clients have more of the business logic available client side, these exploits become increasingly more common because the details of how your application functions are available for all to see.

Developers should ensure that access to sensitive data or functions is properly restricted based on user roles and permissions. This can be achieved by implementing role-based access control, where users are assigned roles determining what data and functions they can access. Developers should also ensure that any user input that controls access is appropriately validated to prevent tampering.

# Insecure Storage: Protect Your Data

Insecure storage is another vulnerability that can be exploited in thick client applications. This vulnerability occurs when an application doesn’t properly encrypt or secure the data that is being stored. Hackers can take advantage of this by accessing sensitive data, such as user credentials, held on the client side.

To mitigate this risk, developers should ensure that data is properly encrypted and stored in secure locations. This can be achieved by using strong encryption algorithms and secure storage mechanisms. Developers should also ensure that sensitive data is never stored in plain text and that encryption keys are properly managed.

This might even need to include encrypting sensitive information while being held in memory when the application is running! If you need to hold credentials or access tokens in memory to be used repeatedly throughout the lifecycle of your application, especially if this is a long-running process like a microservice, encrypt the information and decrypt when needed. There are many ways to scan your applications memory space in order to retrieve this information. Also, make sure the decrypted credentials or tokens are only used in stack memory if possible! It reduces your security footprint and helps to ensure the memory is released quicker.

# Variable and Response Manipulation: Don’t Let Hackers Control Your App

As we get down further in this article, the level of sophistication to pull off these attacks requires significantly more skill and knowledge on how software systems work and the architecture of the computers they run on. Make no mistake, there are a ton of people out there that understand security and how to exploit vulnerabilities.

Variable and response manipulation is another vulnerability that can be exploited in thick client applications. This vulnerability occurs when an application doesn’t properly validate input from users. Hackers can take advantage of this by manipulating variables or responses in order to gain access to sensitive data or perform unauthorized actions.

Developers should ensure that input is properly validated and responses appropriately sanitized. This can be achieved by implementing server-side validation of user input and ensuring that data received from the server is validated before being used. Additionally, mission-critical data, or data that can alter the behavior of your application, should never make its way to the client side at all… as in ever.

I could tell you stories about websites back in the day when you could have purchased things off the internet and name your own price. Like a computer printer for $1. By the way, hit me up in Slack or Twitter to reminisce about security failures you have witnessed. Those stories typically are unbelievable.

# Reverse Engineering: Keep Your Code Secure

Finally, one of the biggest risks to thick client applications is reverse engineering. Traditionally, this vulnerability occurs when hackers decompile or disassemble the code in order to discover vulnerabilities, but a more modern version of this type of attack is understanding the mindset of the individual(s) implementing the application (aka social engineering) and then exploiting it. Once vulnerabilities are discovered or can be deduced from predicting the developer’s next move, hackers can take advantage of them to gain unauthorized access to sensitive data or perform unauthorized actions.

These types of vulnerabilities are few and far between, but when these issues are found out in the wild, these tend to be the catastrophic ones. These ones affect users in the hundreds of thousands or cost the company millions of dollars to mitigate or fix because they are more architecture-related. If you are lucky, you get to avoid the lawsuit when this type of “oops” happens, and it’s contained to a couple of sleepless nights to produce a software patch to fix the problem. In the hardware world, this might be doing a tapeout again and spinning the hardware with a recall; when this happens, it’s potentially a “career-limiting” event.

For example in 2019, Facebook disclosed that two third-party Facebook app developers accidentally leaked over 540 million records related to users because a cache server did not implement proper security measures. Catastrophic indeed!

# Ok, So What Now?

This blog isn’t meant to bash Thick Clients, but rather call attention to what code is running on these Thick Clients, question whether that code should be executed in client space, and do the proper threat analysis on your project or application. I started to think about this a lot recently as I have seen an explosion of applications using frameworks (such as Angular, Vue, etc) where projects were implementing all of their business logic entirely on the client; effectively making these applications only a Thick Client.

You could always make the argument that if safety is the only concern, the safest thing to do in EVERY situation is to limit your security footprint and push as much code and processing of data as you can onto your backend servers. This would then place more development efforts into creating clearly defined interfaces, implementing RBAC, etc. Ultimately, turning your client into your traditional Thin Client used for display only (aka the “View” in the MVC pattern).

Having said that, not all applications have these massive implications if a breach exists. Pushing all of this logic into the backend can be extremely expensive due to requiring server infrastructure and even paying for the expertise of skilled backend developers. Even things like time to market might take all of the priority because this project is just a proof of concept or it’s for demo purposes only. Traditionally, it’s been significantly easier to implement client-only applications/code. So there are nuances in application development that need to be considered.

By the way, if you are looking to implement a conversation-based application and want to do it with enterprise security in mind, then you should take a look at our Enterprise Architecture Implementation Project in GitHub as a blueprint and implementation that you can repurpose for your own application! It turns out that design and implementation for that project pushes all audio stream processing server side, all conversation analytics on the backend, and sends application-level display only messages to the client. Reusing this project will cut down on implementation time, effort, costs, and give you that blueprint to implement your application securely!

To wrap this all up, I think about security a lot. Too much, in fact. Just this past week, a couple of my neighbors had break-ins to their garages and things were stolen. I have several security measures in place because my area is high in theft. So my garage has honeypots, structural door reinforcements, security screws/nuts have been used in key locations, etc., to name some of my security measures. The recent break-ins got me wondering what else can I do to turn my garage into a Home Alone booby trap situation (admittedly, a lot of it for my own amusement). The point is just because you aren’t thinking about securing your stuff, doesn’t mean someone else isn’t trying to figure out how to get in.

Until next time, cheers!

The post Security Concerns with the Status Quo: Secure Your ML Conversation Applications appeared first on Symbl.ai.

We’re exploring ChatGPT‘s capabilities and discovering integration opportunities with the Symbl.ai platform that will enhance your application’s ability to understand conversations and demonstrate how complementary these two platforms can be.

So, during the April meeting we plan on:

• Reviewing the high-level basics of ChatGPT for foundation
• Dissecting OpenAI’s APIs and SDKs
• Offering up some design strategies for combining the two platforms
• Exploring why these platforms naturally lend themselves to generating feedback and reinforcement training

After getting through all of this material, we’ll also go through a demo (yes! A live demo!) that implements this possible design in code. You will find this demo quite helpful for when you’re going through the process of building your own Symbl.ai and ChatGPT integration.

This month’s meetings will be taking place at the following times (please note the time change for Asia-Pacific):

• Americas – Wednesday, April 26th at 11 a.m. PST (Convert to your Timezone)
• Asia-Pacific – Thursday, April 27th at 8 a.m. IST (Convert to your Timezone)

If you’re interested in learning how these two great platforms unlock some pretty amazing use cases, I encourage you to stop by because this is a Community Meeting you don’t want to miss. This meeting is for you, so feel free to bring any questions you might have!

What is the best way to catch the Community Meeting, you ask?

That’s easy! Just…

• Join the Symbl.ai Google Group
• Add the Community Calendar to your Google Calendar
• Then if you have topics for discussion, add them to Agenda Doc

It’s as simple as that.

What is ChatGPT?

ChatGPT is a natural language processing tool driven by AI technology that allows you to have human-like conversations and much more with a chatbot. The ChatGPT language model can answer questions and assist you with tasks including composing emails, essays, and code.

To say there has been a lot of hype behind ChatGPT would be a massive understatement. OpenAi’s user base went from practically zero to 100 million ACTIVE users in the two months the platform was open to the public. To put this into perspective, it’s the fastest-growing application ever created in the history of applications. People are touting that ChatGPT has the potential to revolutionize how humans engage with technology and communicate.

Having used the platform extensively by now, I don’t disagree with that statement. However, the real magic will happen when people start to integrate ChatGPT into existing applications. One great example is Microsoft integrating it into its search engine, Bing. Microsoft has nothing to lose in this venture because Bing barely registers as a blip on the search engine radar, but if I were Google, I personally would be shaking in my boots right about now. These are the kinds of powerful integrations that I’m talking about.

Join us, friends!

Our Community Meetings hit upon some pretty hot topics and are chock-full of vital information. If you want to chat beforehand or if you have any discussion ideas for future Community Meetings, drop by our Slack channel and let us know.

Until then, I look forward to seeing you soon!

The post Understand Your Business Better with ChatGPT and Symbl.ai Platform Integration appeared first on Symbl.ai.

The first video covers Symbl.ai’s Transcription feature; transcription is simply the process of converting speech into text. In the video, we discuss what transcription is, its common use cases, and how it can be applied in real-world scenarios. We also take a deep dive into the feature’s API and demonstrate how to use it in code via our SDKs.

The second video digs into Redaction, which is the process of removing sensitive information from a document or other piece of content. This feature is particularly useful for applications that manage personal data, such as healthcare- or finance-related information. In the video, we cover the basics of redaction, including its use cases and how to apply it to specific examples. We also show how to use the feature in code via our SDKs.

We believe that these videos will be extremely useful for anyone who wants to use transcription or redaction in their applications. Whether you’re building a healthcare app that needs to redact sensitive patient information or a customer service tool that requires transcription, these videos will give you the knowledge and skills you need to get started!

The upcoming chapters in the video training series are Topics, Questions, Follow-Ups, and Action Items. We’re committed to providing you with the best possible resources to help you succeed, so please don’t hesitate to let us know how we can support you.

We hope you enjoy these new videos. Cheers!

The post Symbl.ai Training Series Expands with Videos on Redaction, Transcription appeared first on Symbl.ai.

Symbl.ai is a conversation analytics platform that helps you understand and improve customer conversations. Our platform can be used to analyze conversations ranging from online meetings to video conferencing to support calls. You will then gain access to insights that will help you make better decisions, improve the customer experience, and anticipate customer needs.

Conversation analytics is a powerful tool for businesses of all sizes. By understanding the ways that customers interact with your business, you can not only better understand the customer experience, but underlying customer needs as well. This can help you identify underperforming areas and improve upon your customer service strategies.

In this video training series, we will go over the basics of the platform, how it works, and how you can use it to enhance your customer conversations. We’ll also look at some best practices and strategies to optimize your use of the platform.

I plan to have a new training video released each week covering a wide variety of topics. We hope you find this series useful and look forward to helping you make the most of Symbl.ai!

The post Introducing the Symbl.ai Video Training Series: Learn How to Unlock the Conversation Intelligence Platform’s Capabilities appeared first on Symbl.ai.

This blog post will unlock the real potential of why this Enterprise Reference Implementation is exceptional. The secret sauce in the implementation is this idea of a Plugin-based Conversation architecture. We have danced around this topic in previous blog posts for a while. Now is the perfect time to do a deep dive into this mic-dropping capability and unveil the Enterprise Conversation Plugins repo.

Extensible Conversation Application via Plugins

In software development, there are always countless things we write code for time and time again. The industry devised solutions for this problem by creating libraries or reusable code that we could reference or drop into the codebase. This reduces the need to write the same code repeatedly while decreasing time spent on maintenance and increasing robustness through reuse. We have taken a page from that book by implementing that design goal in a non-obvious way; hence this blog post.

Because the project uses RabbitMQ to handle the notifications for events happening within the system, we will leverage that same system to pull off the interface to the plugin framework. RabbitMQ can fan out or broadcast messages to anyone subscribing to specific notifications. A high-level depiction of what that might look like is pictured below.

That brings us to the Enterprise Conversation Plugins repo. This repo intends to offer an “App Store”-like experience where people can take advantage of generic pre-built functionality. By launching a plugin within the repo, you can surface messages, create triggers, etc., within your application. There are currently two plugins within the repo, a historical and a statistical plugin, that offer exceptional capabilities and can be dropped into your application today.

Watch the following video demo to learn more:

How Do I Create a Conversation Plugin?

You might be saying, “This is pretty amazing—how do I create my own plugin?” Well, I’m glad you asked, because that’s what we will address next.

In the Enterprise Reference Implementation repo, a Plugin SDK offers up the plugin interfaces required to implement. The plugin interface is pretty simple:

/*

   This implementer of this interface handles much of the routing to your middleware-analyzer component

   As Symbl insights are received from the platform, these callbacks will be invoked

*/

type InsightCallback interface {

   /*

       This ensures there is a 1-to-1 mapping between insights the Symbl Platform provides and

       which events are possible to be notified to

   */

   sdkinterfaces.InsightCallback

   /*

       The Client Publisher interface will be set before messages trigger functions in the

       sdkinterfaces.InsightCallback

   */

   SetClientPublisher(mp *MessagePublisher)

}

You might be asking, what is SetClientPublisher(*MessagePublisher) used for? That command will pass a pointer to the struct that implements the MessagePublisher interface, which allows your Conversation Plugin to pass named application-specific messages to your UI or client.

/*

   This provides an interface for the implementing struct to sent messages to the client.

*/

type MessagePublisher interface {

   PublishMessage(name string, data []byte) error

}

Is there an example code/scaffolding for a plugin that could be used as a starting point? The answer is: most definitely. In the Example Middleware Plugin folder, there is an example Conversation Plugin that passes a simple application-specific message for every possible Symbl.ai Platform message to your UI or client. Then, to test out your plugin’s application-specific message implementation, you can use the Example Simulated Client App to ensure your UI will receive your messages when you finally implement that piece of your application.

Plugin Advanced Topics

I wanted to mention some advanced Conversation Plugin topics that might be of value to you. The first is how to scale out your plugin instances, and, finally, how to have your plugins talk to each other.

Scaling Out Your Plugin Instances

If you haven’t noticed yet, the Conversation Plugin’s architectural design is actually that of a Microservice. This is great news because we can containerize our plugins (coming soon to a GitHub action near you), and you can also scale out your plugin if you use a container orchestrator such as Kubernetes. If your plugin would benefit from scaling for reasons including pegging the CPU, memory requirements, etc., this is an effective solution.

One possible and effortless way this could be done is by dividing up the work based on the conversation UUID. For example, if you know through profiling that the response time has passed the threshold and is increasing exponentially within your plugin, you could scale to two instances. Then divide the work by allocating conversations UUIDs starting with 0-7 to plugin instance No. 1 and UUIDs starting with 8-F to plugin instance No. 2.

Of course, the best way is to use a modern scheduler such as Kubernetes or have a proxy service that dispatches or redirects requests to instances based on round robin or, better yet, by instance load if you are capturing metrics on your services. Too many ways!

Internal Communication Between Plugins

Another great concept we can implement is having Conversation Plugins talk to other conversation plugins. Why might you want to do this?

Some of those reasons might be but are not limited to:

• Complex workflows or business logic
• Separation of concerns
  • different teams working on different microservices
  • Interfacing with other platforms or systems
• Aggregation of plugins messages and/or data
• Creating a higher-level message that needs more metadata

I want to call out that last reason, creating a higher-level message that needs more metadata, because it’s probably the one you will run into most often. The Conversation Plugins within the repo are intended to be generic and void of any company-specific business rules or logic. Still, you might want the information supplied by one plugin and add more of your (meta)data or context around it.

For example, you might use the statistical plugin to collect information about how many times a particular Tracker has come up in the past hour. If that number exceeds ten mentions, you might want to send a Slack message to a specific channel to investigate. All you would need to do is create a new Conversation Plugin that subscribes to the Statistics metrics (seen here and shown in the above diagram as the green arrow) from the statistical plugin. Your implementation would be limited to sending a Slack message when that value is greater than 10 and maybe a notification to the UI, if needed.

Bring It All Together

We have now discussed several remarkable things about this Enterprise Reference Implementation and the idea of having a community repository for Conversation Plugins that everyone can use. This Conversation Plugins repo is for others to be able to contribute different kinds of functionality that the community could use. Said a little differently… we would be excited to take any pull requests for plugins!

Many people have been interested in security as it pertains to various architectures and implementations for these Conversation Applications. So, we are going to tackle that topic in the next blog post. Talk to you then!

The post Introducing an Easy Button for Creating a Pluggable Enterprise Conversation Application appeared first on Symbl.ai.