The open-source hub to build & deploy GPT/LLM Agents ⚡️
MIT License
Bot releases are hidden (Show)
Published by laurentlp almost 3 years ago
Published by EFF almost 3 years ago
Published by EFF almost 3 years ago
Published by EFF about 3 years ago
Published by EFF about 3 years ago
Published by laurentlp about 3 years ago
0.0.36 ==> 0.0.37 see changes here
Published by laurentlp about 3 years ago
0.1.5 ==> 0.1.6 see changes here
0.0.34 ==> 0.0.36 see changes here
0.1.12 ==> 0.1.13 see changes here
Published by EFF about 3 years ago
In this release, the channel web was converted to use the new messaging server. This shouldn't cause any noticeable change in useability, but it does bring a large migration that converts all the messages and conversations stored in the channel-web's web_conversations
and web_messages
tables to tables managed by the messaging server. It also migrates any references to these conversations and messages that exist in other tables. As such, it should not incur any loss of data, and previously existing conversations will still be accesible to users, as well as previously existing HITL handoffs.
Since this migration is so large and impacts so many tables, it has been designed to work using a transaction, meaning that if anything goes wrong during the migration, all changes will be rollbacked automatically to prevent loss of data. You can also run this migration in dry mode using the --dry
command line option. This will run the entire migration without applying the changes and will display the number of conversations and messages that will be migrated.
It's possible that some messages and some conversations get deleted due to new constraints required by the messaging server. For example a message pointing to a deleted or null conversation will be deleted, and a conversation pointing to a null botId will also be removed.
Payloads are now sent to the channel-web in the same format as they are stored in the content element files. This means that some usage of the sdk that relied on channel-web specific format of payloads to create events is now invalid. For example :
await bp.events.sendEvent(
bp.IO.Event({
botId: 'myBotId',
direction: 'outgoing',
channel: 'web',
target: 'aUserId',
type: 'file',
// This payload format is old and deprecated. It may still work due to backward compatibility in the webchat ui but it should be ported as soon as possible
payload: {
type: 'file',
title: 'My image title',
url: 'https://www.my-website.com/my-image.png'
}
})
)
Should be replaced with :
await bp.events.sendEvent(
bp.IO.Event({
botId: 'myBotId',
direction: 'outgoing',
channel: 'web',
target: 'aUserId',
type: 'image',
// This is the correct payload format to use. Notice that this is the same format in which your content type is saved.
payload: {
type: 'image',
title: 'My image title',
image: 'https://www.my-website.com/my-image.png'
}
})
)
If you were using the renderElement method already then everything should still work
// This works in both the old and new version
bp.events.replyToEvent(
event,
await bp.cms.renderElement(
'builtin_image',
{ title: 'My image title', image: 'https://www.my-website.com/my-image.png' },
event
)
)
This change only affects builtin content types. Custom content types still use the backend renderers defined in renderElement
function.
0.1.4 ==> 0.1.5 see changes here
0.0.33 ==> 0.0.34 see changes here
0.1.8 ==> 0.1.12 see changes here
Published by EFF about 3 years ago
0.1.2 ==> 0.1.4 see changes here
0.0.25 ==> 0.0.33 see changes here
0.1.7 ==> 0.1.8 see changes here
Published by EFF about 3 years ago
In this release, most of channels related code was removed from main code base and was replaced by an executable messaging server binary. When running from binary or from Docker it doesn't change anything for the user, the Messaging Server Binary ships with Botpress main binary as for Docker it's baked in the image. When running from sources, the Messaging server binary, hosted on the Github repo, is downloaded in the Botpress directory by a "postinstall" script. The Botpress core will automatically start Messaging Server on a dedicated port unless told otherwise.
Moreover, notice that channels configuration has now moved under the messaging configuration on your chatbot's config file. For more details on each channel, see the docs.
Published by daehli about 3 years ago
Published by EFF over 3 years ago
In this release, all Studio related code was fully removed from main code base and was replaced by an executable binary. Studio code was moved in its own repository. When running from binary or from Docker it doesn't change anything for the user, the Studio Binary ships with Botpress main binary as for Docker it's baked in the image. When running from sources, the Studio binary is hosted on the Github repo page and is downloaded in the Botpress repo by a "postinstall" script. The Botpress core will automatically start studio on a dedicated port unless told otherwise.
Published by EFF over 3 years ago
Published by EFF over 3 years ago
Published by EFF over 3 years ago
This release contains important architectural changes, see important change notice below.
Replace NLU engine by executable binary of NLU Server
In this release, all nlu related code (except the nlu module) was fully removed from main code base and was replaced by an executable binary. The code was moved in this repository. The NLU server binary is hosted on the Github repo page and is downloaded in the Botpress repo by a "postinstall"
script. The botpress core will automatically start the NLU server unless told otherwise. The NLU module now use an HTTP client to make trainings and predictions.
By default, Botpress core starts the NLU server at runtime, so nothing is expected from the user, Botpress will still work the same.
nluServer.autoStart = false
in the nlu json config file. You'll then have to specify endpoint and auth-token of your manually started NLU server. Keep in mind that NLU server is not distributed yet, so each instance of your botpress infra should always communicate with the exact same instance of NLU Server. More on that in # self-hosting
section.NLU_BIN_DIR
to tell botpress where you binaries are located.out/bp
when Botpress is ran from sources and out/binaries
when ran from binary.package.json
.If you want to self host your NLU server, make sure each instance of your Botpress infra always use the same instance of NLU Server like shown on the following image. NLU Server is not yet available for multi-clustered infrastructure setup.
Published by EFF over 3 years ago
Note: This patch also contains some minor visual changes to the administration ui but contains absolutely no change to functionality.