SHA256
131 lines
5.1 KiB
Markdown
131 lines
5.1 KiB
Markdown
# Программа `shine_login_guard`
|
|
|
|
Документ описывает текущее временное поведение программы классификации логинов SHiNE.
|
|
|
|
Задача программы:
|
|
|
|
- по логину определить класс регистрации;
|
|
- вернуть результат в `return_data`;
|
|
- не хранить PDA и не вести собственное состояние.
|
|
|
|
## 1. Назначение
|
|
|
|
`shine_login_guard` — маленькая служебная программа, которую вызывает `shine_users` через CPI до регистрации пользователя.
|
|
|
|
В текущем временном режиме она отвечает только на вопрос:
|
|
|
|
- является ли логин допустимым для автоматической регистрации;
|
|
- нужно ли отклонить слишком короткий или некорректный логин.
|
|
|
|
UI может накладывать дополнительные временные ограничения поверх этой логики, но сама программа про них не знает.
|
|
|
|
## 2. Program ID
|
|
|
|
Текущий program id:
|
|
|
|
- `SHiGxGsXGioQYCYhchQ5R7KWoxN5UjFAFsucPf6sfnh`
|
|
|
|
## 3. Состояние
|
|
|
|
У программы нет PDA-состояний и persistent storage.
|
|
|
|
Программа полностью stateless и не опирается на словари при классификации.
|
|
|
|
## 4. Единственная инструкция
|
|
|
|
Инструкция:
|
|
|
|
- `classify_login(login: String)`
|
|
|
|
Бинарный ABI инструкции:
|
|
|
|
```text
|
|
- tag: u8 = 1
|
|
- login_len: u32 LE
|
|
- login_bytes[login_len]: UTF-8
|
|
```
|
|
|
|
Аккаунты:
|
|
|
|
- аккаунты не требуются
|
|
|
|
Если вызов идёт через CPI из `shine_users`, программа `shine_login_guard` не требует signer-аккаунтов.
|
|
|
|
## 5. Выходные классы
|
|
|
|
Программа возвращает `u32` через `set_return_data`:
|
|
|
|
- `0` — `CLASS_FREE`
|
|
- `1` — `CLASS_PREMIUM`
|
|
- `2` — `CLASS_TRADEMARK`
|
|
|
|
Сейчас фактически используются только:
|
|
|
|
- `CLASS_FREE`
|
|
- `CLASS_PREMIUM`
|
|
|
|
`CLASS_TRADEMARK` сохранён для совместимости ABI, но временная логика его не возвращает.
|
|
|
|
## 6. Правила нормализации логина
|
|
|
|
Перед классификацией логин нормализуется:
|
|
|
|
- пустой логин запрещён;
|
|
- длина исходного логина не больше `20`;
|
|
- символ `_` удаляется;
|
|
- остальные символы обязаны быть ASCII alnum;
|
|
- буквы приводятся к нижнему регистру.
|
|
|
|
Если нормализация не удалась:
|
|
|
|
- логин считается `CLASS_PREMIUM`.
|
|
|
|
Это означает, что `shine_users` не пустит такой логин в обычную регистрацию.
|
|
|
|
## 7. Временные правила классификации
|
|
|
|
Текущий временный алгоритм:
|
|
|
|
1. Нормализовать логин.
|
|
2. Если нормализованный логин короче `5` символов, вернуть `CLASS_PREMIUM`.
|
|
3. Иначе вернуть `CLASS_FREE`.
|
|
|
|
То есть on-chain программа в этом режиме:
|
|
|
|
- пропускает любые валидные логины длиной от `5` символов;
|
|
- не использует premium-словари;
|
|
- не использует trademark-словари;
|
|
- не выполняет словарную сегментацию логина.
|
|
|
|
## 8. Граница ответственности
|
|
|
|
Важно разделять уровни:
|
|
|
|
1. `shine_login_guard`
|
|
- проверяет только базовую валидность и минимальную длину `5`.
|
|
|
|
2. UI
|
|
- может вводить дополнительные временные ограничения;
|
|
- например, пускать логины длиной `5..7` только по временному коду.
|
|
|
|
3. `shine_users`
|
|
- остаётся финальной on-chain точкой регистрации;
|
|
- дополнительно проверяет общий формат логина в собственной логике.
|
|
|
|
## 9. Совместимость
|
|
|
|
Сохранено:
|
|
|
|
- тот же ABI инструкции;
|
|
- тот же формат `return_data`;
|
|
- те же значения классов `0/1/2`;
|
|
- тот же `Program ID`.
|
|
|
|
Изменено относительно полной словарной версии:
|
|
|
|
- нет словарной классификации;
|
|
- нет разделения на premium/trademark по содержимому логина;
|
|
- короткий порог временно снижен до `5`.
|
|
|
|
При возврате к полной модели нужно будет обновить этот документ снова синхронно с кодом.
|