search

malfoyslastname / character-card-spec-v2

An updated specification for AI character cards.
91 stars 6 forks source link

Proposed new standard fields #2

Closed acidbubbles closed 1 year ago

acidbubbles commented 1 year ago

Following a conversation on Discord with @malfoyslastname, here is a list of fields suggestions, their format, and why.

Spec version

It is possible to add new fields or compatible values in the future without creating a completely different spec. If the spec includes a version number, future versions of the spec can be easily detected and supported, and if an importing software does not support the provided version, it can gracefully inform the user that some fields may not be imported, instead of just silently dropping them.

Valid values:

2.0, 2.1

Example:

{
  "spec": "chara_card_v2",
  "version": "2.1"
}

Culture

Cards are written in a certain language, and I hope people will feel comfortable creating characters in their own language.

It can also be used for:

Valid values:

Strings following RFC 5646 such as en or en-GB.

Example:

{
  "data": {
    "culture": "en-us"
  }
}

Tags

We need a simple way to find imported characters and to make them discoverable.

Valid values:

A list of strings, all lowercase, numbers and underscores only.

A set of tags would be considered standard, but that list will grow independently of the spec itself:

Example:

{
  "data": {
    "tags": [
      "nsfw",
      "adventure",
      "custom_tag_123"
    ]
  }
}

Author

Who made that character, good motivation for character builders and easier to find more by the same author in the future.

Valid values:

A username, and potentially a URL to get more or contribute (e.g. patreon)

Example:

{
  "data": {
    "author": {
      "name": "johndoe",
      "url": "https://..."
    }
  }
}

Version

If a character was updated (typos fixed, more details added, more lore created, etc) we need to know which is which.

Valid values:

A single sequential number, OR semver.

Example:

{
  "data": {
    "version": "1.0"
  }
}

Origin

Where the character was uploaded to first, so if you get a character from someone, it's possible to track it down. That field could be auto-populated by boorus, or by the author, but it's completely optional. I expect people will use it to point to their Discord server, Patreon, Twitter, etc.

Valid values:

A valid https url.

Example:

{
  "data": {
    "origin": "https://twitter.com/whatever"
  }
}

Extensions

We need a way to add useful fields such as gender, age, and eventually custom fields such as visual novel software requiring animation data for example.

The difference between extensions and root fields like personality is that this is NOT meant to be sent as a prompt, but rather for supporting the software using the card.

This can also be useful to avoid custom export formats, e.g. "exported by software version", etc.

NOTE: Any field that is suggested in extensions that is NOT software-specific could eventually (or already) be migrated to a root field in future versions of the spec. For example, culture, gender, age, voice, llm, etc. The objective is for anyone who needs additional data to have a way to do so.

Valid values:

Keys must be strings, values are any (object, string, number, boolean)

Example:

{
  "data": {
    "extensions": {
      "text_color": "#ff3333",
      "agnai/voice": { "service": "elevenlabs", "id": "Bella" }
    }
  }
}
malfoyslastname commented 1 year ago

From me:

Obvious yes:

Unsure:

Not convinced of functional utility at this current moment, voice settings are still fringe enough that it might be worth keeping it the user's responsibility to set as global settings rather than the botmaker to have an additional field, although the problem is mitigated by defaulting it to English on English-language character creators.

Auto-correct sounds also like a systemwide setting that is not usually overridden by applications.

Is this essentially a structured way to add off-spec properties? Sounds good, I suppose.

acidbubbles commented 1 year ago

I guess culture's main use would be like a specialized tag, I know English is taken for granted a lot but the content of the card may very well be written in another language, if you don't speak that language, it's nice to only show languages you do speak :) also I'd love for gaslights to be language specific, right now I have to manually select it rather than simply match it by language.

acidbubbles commented 1 year ago

Oh and for extensions: Yes, exactly :)

malfoyslastname commented 1 year ago

@acidbubbles for the time being i'm going to add spec version, tags, author, character version, and extensions

no origin/culture

lloorree commented 1 year ago

No objections to any of this. How about expressions? Now that I know it’s just a folder of PNGs for SillyTavern (the .miku format made me think it would be more of a pain than that) they seem fairly easy to add. EDIT: Looking into how Risu does it now since they're five steps ahead of me here. Ignore the example. Literally embedding them into the card would be maybe impossible (?), but perhaps a dict of url locations, if not in the “real” part of the spec then in extensions? E.g.,

{

    “data”: {

        # other fields here…

        “expressions”: {

            “happy”: “https://cdn.example.com/uuid.png”,

            “sad”: “https://cdn.example.com/uuid2.png”,

            # more emotions…

        }

    }

}
acidbubbles commented 1 year ago

@lloorree because this is still fairly new and may change, I would suggest to make that part of extensions. For example, because you need expressions to be known words, and the associated image might contain one image, or multiple, you may have multiple alternative expression words, you might have text speed and color, etc this would be a great fit for extensions. Like:

{
  "data": {
    "extensions": {
      "risu/expressions/1.0": {
        "expressions": {
            "happy": "https://cdn.example.com/uuid.png",
            "sad": "https://cdn.example.com/uuid2.png",
          }
        }
      }
    }
}

This way, if someone has an alternative format, the spec itself won't become obsolete.

Cohee1207 commented 1 year ago

What should the frontend do with these v2 fields system_prompt, post_history_instructions if the user-selected generation API doesn't use system prompts? Should we let them be displayed but with an additional note that they won't be used during the reply generation?

malfoyslastname commented 1 year ago

@Cohee1207 I'm going to quote and reply to your question in #1