Текущий этап: 05.08.23

Бэк:

— в общем-то готов к работе. Стартовые API (в смысле то, что точно нужно на запуске) готовы и наколенные тесты проходят

— в качестве БД используется SQLite, но я об этом, вроде, предупреждал. Этого достаточно для отладки и даже для малого числа участников

— несколько раз, не менее четырёх, переписывал хранение номеров телефонов и их запрос. Хочется свести к минимуму возможности утечек, но при этом помнить, что работаем на мобилке. Пока остановился на:

    — хранятся только sha256 от e164 номеров: report.Number = fmt.Sprintf("%x", sha256.Sum256([]byte(report.Number))). Этот Number и кладётся в БД

    — e164 ожидается только репорте спама. Он принимается только в API репорта: Number string `json:"number" validate:"required,e164"`. То есть при РЕПОРТЕ нельзя передавать не e164. Потому что репорт делается для плохих номеров — спамеров
    — в ЗАПРОСЕ номера принимается ТОЛЬКО строка из ровно 40 символов: len(hash) != 40. То есть если кто-то со злым умыслом или по ошибке будет запрашивать чистые номера, бэк будет просто отбивать запросы. Сам nginx пока будет логгировать эти запросы, но это исправлю к релизу

    — в ответ прилетит список подоходящих под запрос хешей из БД и статистика по ним: лайки, дизлайки, сколько отзывов. Клиентское приложение должно будет локально понять, что из пришедшего ему нужно было

— добавлена таблица "золотых" номеров. В неё буду вносить номера экстренных служб, типа 112, 911, 01 и всё такое. Золотые номера незлья зарепортить. Это сделано, чтобы злоумышленник не мог заблокировать номера экстренных служб

— добавлена, но пока не используется, таблица "плохих парней". Если на чьи-то репорты будут массовые жалобы (обжалование репортов тоже будет, да) — именно от разных пользователей (массовые от одинаковых просто игнорируются), автор репортов будет добавляться в базу плохих парней. И потом, если он действительно мудак сраный, его токен будет заблокирован

— каждый пользователь - это просто `GUID`. Понятное дело, что никаких имёт, имейлов, номеров телефонов для регистрации. Только GUID

— регистрация возможна только по инвайтам. Инвайтер сейчас может генерировать до 5 инвайтов единоразово. Каждый инвайт живёт 72 часа, либо до активации. Успешная активация или протухание инвайта сбрасывает счётчик активных инвайтов и тот, у кого есть права на приглашение, может создавать новые инвайты
    — таким образом я планирую избавляться от просто идиотов. Есть надежда, что инвайтер просто перестанет давать инвайт мудаку, который то и дело улетает в бан и просит новый

    — собственно, сама регистрация - это сделать GET, передав инвайт и в ответ получив GUID

Вроде пока всё по базе. Адрес сервера публиковать не буду. Когда будет готов клиент, вы его и так и исходниках увидите

Клиент:

— сел писать клиента

— реализовал, а потом удалил код запроса истории звонков. Тогда-то и увидел вот это поведение: https://t.me/mydaybug/458

    — удаление связано с тем, что сделал описанную выше логику с запросом номеров не по полному номеру, а по 40 символам из 64. Этот подход будет давать на один реальный номер несколько хешей. А история звонков может создать сотни запросов

    — возможно в будущем снова сделаю подгрузку из истории звонков, если в голову придёт другой сценарий, более полезный

— записал вот этот видосик. На мелкий шрифт внимания не обращайте — это моя системная настройка. У меня глобально выставлен мелкий в системе. А тут ещё сверху наложилось сжатие и получилось то, что получилось

Если что, e164 — это вот такое написание номеров: +79031234567. Приведением локального номера к e164 должен заниматься клиент. Бэк будет просто отбивать те репорты, которые приходят в формате, который не валидируется как e164.

Иначально я положил на бек задачу приведения тоже. Но для приведения требуется также указывать и страну. Решил, что лучше клиент сразу пусть даёт в правильном формате - это одно поле, чем в правильном или неправильном плюс страну - это два поля