Field guide
Character Card V3 fields you're losing when uploading to Chub
The V3 spec adds nine fields on top of V2. Most platforms still store V2 internally. Here's what gets dropped, what gets coerced, and what you can do about it.
V3 character cards are now common — RisuAI, SillyTavern, and several editors emit them natively. But the most popular distribution platform, Chub, still stores cards as V2. When you upload a V3 PNG, Chub re-reads it through a V2 parser and writes a V2 record. Nine fields don't survive the round trip. Some are mostly cosmetic; others can quietly break attribution or break your localization.
The full lossy list
- assets — V3 lets you ship icons, backgrounds, emotions, and user-side avatars in a typed array. V2 has no equivalent. Anything past the embedded card portrait is dropped.
- nickname — separate "display" name. Falls back to
data.nameon V2 hosts. - creator_notes_multilingual — locale-keyed author notes. Only the default
creator_notessurvives. - group_only_greetings — greetings reserved for group chats.
alternate_greetingsstill survives. - source — provenance / attribution array.
- creation_date / modification_date — epoch timestamps. Chub stamps its own at upload.
- decorators on lorebook entries (
@@constant,@@activate, etc.) — recognized by some V3-aware hosts, ignored by V2 parsers. - use_regex on lorebook entries — V3 lets keys be regex; V2 hosts treat the string literally.
What this means in practice
If you maintain a V3 master copy and publish to Chub for reach, your Chub version is a strictly lossy projection — that's fine, as long as you know which fields you relied on. The painful surprise comes when:
- You wrote multilingual creator notes and uploaded the JA/KO versions thinking the host would serve them based on user locale. Chub serves only the default.
- You designed group_only_greetings for ensemble RPs. They simply don't exist on the Chub-hosted version of the card.
- Your lorebook depends on
use_regex. On V2 hosts the regex string is matched literally and never triggers.
Detect before you upload
The lint engine flags every lossy field per target platform. Drop your card into /audit and look for findings tagged compat.v3_to_v2.*.lossy. The audit page also surfaces decorator-and-regex compatibility warnings under compat.v3.decorators.legacy_platform.
Treat compat warnings as "ok to publish but document upstream." They don't block sync; they tell you which fields to mirror somewhere durable (creator_notes being the obvious place).
Keep the V3 master, project for the host
The right workflow isn't to downgrade your master copy to V2 — it's to keep a V3 master and project a V2 view at publish time. Tavern·AI Cards stores V3 internally, runs the audit against your master, and lets you publish to Chub knowing exactly which fields will be visible on each surface. Distribution preserves what the host supports; attribution and multilingual notes live on the creator profile, not the card body.