Add a dedicated configuration/authentication doc covering password and access-token setup,
including environment-variable mappings and token-generation example.
Link to it from configuration docs and align the sample config wording with Matrix Authentication Service/OIDC terminology.
* 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>
This is based on the work done in https://github.com/etkecc/baibot/pull/60 by https://github.com/Fmstrat (Ben Curtis),
with various changes on top to make the code more idiomatic and flexible.
This commit squashes the following patches (newest first):
- Improve handling of `user.avatar` configuration (null & empty string being the same now) and add support for a special `keep` value
- Minor import reordering
- Simplify avatar configuration (`user.avatar.source` -> `user.avatar`)
- Combine `logo_bytes` and `mime_type` determination logic and do not fall back to default avatar if reading the custom avatar file fails
- Switch from deprecated `mime_guess::guess_mime_type(avatar_path)` to `mime_guess::from_path(avatar_path).first_or_octet_stream()`
- Relax `mime_guess` constraint and order alphabetically
- Use `mime` from `mxlink`
- Add mime-type support and switch to user.avatar.source
- (Original work by Fmstrat) Add support for custom avatars
Co-authored-by: Fmstrat <nospam@nowsci.com>
This patch introduces a new `baibot_conversation_start_time_utc`
variable which indicates the time the conversation got started.
Using `baibot_now_utc` is still possible, but given that the current
time is a moving target, its use is in conflict with prompt caching.
Because the new `baibot_conversation_start_time_utc` prompt variable
is a more reasonable default, we're now using it in all sample configs.
Since 2024-10-02, `gpt-4o` is actually the same as `gpt-4o-2024-08-06`.
We previously used `gpt-4o-2024-08-06`, because it was pointing to a
much better (longer context) model. Since they're both the same now,
we'd better stick to the unpinned model and make it easier for future
users to get upgrades.
