Using the floating stable toolchain currently breaks this project. Repro via just build-debug:
```
Compiling matrix-sdk v0.16.0
error: queries overflow the depth limit!
help: consider increasing the recursion limit by adding #![recursion_limit = "256"] to your crate (matrix_sdk)
note: query depth increased by 130 when computing layout of matrix-sdk Client::sync async body
error: could not compile matrix-sdk (lib) due to 1 previous error
```
Pinning CI to 1.93.0 keeps CI on the known-good toolchain until upstream/toolchain compatibility is addressed.
We should have had that to begin with (we're pinning as much as we can anyway), but..
Ref: https://github.com/etkecc/baibot/pull/83#issuecomment-4008463792
* Add support for access tokens using MAS
* use 1.13.0
* Update dependencies
* Harden auth credential selection in matrix link init
Use the same non-empty access-token criterion for auth mode selection and bind the token directly from the branch condition.
Return explicit configuration errors for missing or empty `device_id`/`password` instead of panicking, so invalid auth config fails gracefully.
* Centralize and harden user auth config handling
Move authentication-mode resolution into typed config parsing with ConfigUserAuth,
so downstream login setup consumes validated credentials instead of re-checking raw optional fields.
Enforce explicit password-vs-token selection, validate token/device/user-id requirements in one place,
and normalize empty auth env overrides to unset values for consistent behavior across YAML and environment input.
* Add auth config unit tests
Move auth_config tests into a dedicated cfg test module file to keep production config code compact while preserving behavior coverage. The tests cover password/token mode selection, missing/both auth method rejection, missing device_id, and empty-value handling.
* Use conventional mxlink version requirement
Replace the unconventional wildcard lower-bound expression with a standard semver lower bound for readability and tooling consistency.
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
The dev environment previously hardcoded Synapse (bundled with Postgres
and Element Web) in a monolithic etc/services/core/ directory.
With Continuwuity now available as a lighter alternative (no external DB),
this refactors the service layout so developers choose their homeserver
once and everything derives from that choice. Continuwuity is the new
default for its smaller footprint.
Key changes:
- Break etc/services/core/ into etc/services/synapse/ and
etc/services/element-web/, each with their own compose.yml
- Add `homeserver` variable in justfile (reads var/homeserver,
defaults to continuwuity)
- Add `homeserver-init` recipe to persist the choice
- Use placeholders (__HOMESERVER_SERVER_NAME__, __HOMESERVER_URL__,
__HOMESERVER_CLIENT_URL__) in config templates, resolved at
prepare time based on the chosen homeserver
- Make services-start/stop/prepare/tail-logs delegate to the chosen
homeserver's recipes + element-web
- Make users-prepare delegate to {homeserver}-users-prepare
- Update docs/development.md for the new homeserver choice flow
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds Continuwuity as an alternative to Synapse for local development,
useful for testing baibot compatibility with different homeserver
implementations. Follows the same optional service pattern as localai/ollama.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
serde_yaml is deprecated and unmaintained. serde_yaml_ng is the community
fork with a compatible API, so this is a straightforward rename across the
codebase.
- Add mise.toml (prek 0.3.2) and .pre-commit-config.yaml with hooks for
trailing whitespace, end-of-file, YAML check, merge conflicts, large files,
cargo fmt, cargo clippy (-D warnings), and unit tests
- Add prek/mise recipes to justfile
- Run cargo fmt to fix formatting issues
- Fix all clippy warnings: collapse nested if statements, derive Default for Avatar
Document the new tools feature in README, features.md, and providers.md.
Update the `!bai providers` command output to show vision/tools support
consistently for all providers.
Based on #62 by @yeslayla which migrated the OpenAI provider to the
Responses API.
See: https://github.com/etkecc/baibot/pull/62
Sticker generation was failing when using newer GPT image models
(gpt-image-1, gpt-image-1-mini, gpt-image-1.5). The issue occurred
because stickers requested 256x256 size, but these models only support
1024x1024, 1536x1024, 1024x1536, and auto.
To reproduce, send `!bai sticker Something` to an agent configured
with a GPT image model. The error was:
invalid_request_error: Invalid value: '256x256'. Supported values
are: '1024x1024', '1024x1536', '1536x1024', and 'auto'. (param: size)
(code: invalid_value)
The fix replaces the hardcoded 256x256 size override with a
`smallest_size_possible` flag, letting each provider determine the
appropriate sticker size based on the model being used.
The `openai_compat` provider still defaults to requesting 256x256 in all cases
(regardless of model name).
