yetone 2b2a7bf83f sync: a WebDAV server that answers 403 for what isn't there (a Synology, PROPFIND too) no longer fails the first sync as if the account couldn't write in the folder — magpie's own folder in it is looked for, and when it isn't there a 403 to reading the backup is no backup yet and one to writing it is made as a 404 is

2026-09-28 10:51:05 +08:00

..

dav_test.go

sync: a WebDAV server that answers 403 for what isn't there (a Synology, PROPFIND too) no longer fails the first sync as if the account couldn't write in the folder — magpie's own folder in it is looked for, and when it isn't there a 403 to reading the backup is no backup yet and one to writing it is made as a 404 is

2026-09-28 10:51:05 +08:00

dav.go

sync: a WebDAV server that answers 403 for what isn't there (a Synology, PROPFIND too) no longer fails the first sync as if the account couldn't write in the folder — magpie's own folder in it is looked for, and when it isn't there a 403 to reading the backup is no backup yet and one to writing it is made as a 404 is

2026-09-28 10:51:05 +08:00

davsync_test.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

davsync.go

backup: the library goes with a backup and a WebDAV sync — the instructions, MCP servers and skills with their files, a fifth part, ticked by default (magpie backup/restore --no-library). A backup without keys leaves the servers' secret env and headers empty and a restore fills them from the servers kept here; a skill's file over 2 MB, or past 32 MB in all, stays behind; a path that climbs out of its skill is refused. What it replaces is kept with the library's backups. Tested from a sandbox: exported without keys, changed and removed things, imported — the server back with the local key kept, the skill back as files, run.sh still executable

2026-09-27 17:24:53 +08:00