Documentation
¶
Overview ¶
Package sticker implements per-user custom sticker management.
Two-step registration contract (API) ¶
- Upload the image: POST /v1/file/upload?type=sticker (multipart). The response carries `path` and — when the server has signing capability (OCTO_MASTER_KEY configured) — `sticker_handle`.
- Register: POST /v1/sticker/user with body {path, format, placeholder, handle}, passing the upload's `sticker_handle` value as `handle`.
Stickers do NOT support presigned uploads: the upload handle can only be minted where modules/file holds both the authenticated uploader and the content-validated bytes, so the image must transit the multipart endpoint.
Handle enforcement (capability vs policy) ¶
Whether `handle` is REQUIRED is governed by the system_setting `sticker.handle_required` (SystemSettings.StickerHandleRequired) — a DB-backed, admin-toggleable policy independent of the signing capability (OCTO_MASTER_KEY / stickersig.Enabled). It lives in system_setting rather than an env var so the rollout can be toggled and rolled back from the admin console without a restart (converging across replicas within the snapshot TTL). Clients read the effective policy from GET /v1/common/appconfig → `sticker_handle_required`. See the stickersig package doc for the rollout rationale and behavior matrix.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Sticker ¶
Sticker 用户自定义贴纸 API。
type StickerModel ¶
type StickerModel struct {
StickerID string
UID string
Path string
Placeholder string
Format string
Sort int
Shortcode string
Keywords string
SourcePath string
// SourcePathHash is set only for "collect from message" records. Direct
// upload registrations keep it empty so the collect-only unique key does not
// affect existing custom-sticker creation.
SourcePathHash string
Status int
db.BaseModel
}
StickerModel 用户自定义贴纸（个人维度，扁平、不分包）。
Source Files