Например, если у каждой страницы есть номер, то при показе страницы N делаем кнопки с call_data=page:N-1 и page:N+1 (отдельно учитываем первую и последнюю страницу. При нажатии на кнопку редактируем сообщение, заменяя его текст на содержание страницы N+1/N-1 и кнопки на соответствующие.
serhiops, в обработчике команды ничего не надо отправлять. В нём нужно только добавить задание в очередь с указанием времени. Например (но необязательно!), очередь можно хранить в таблице в базе, для чего сделаем таблицу message_queue с такими полями:
id - главный ключ;
send_time - время отправки;
recipient_id - id получателся;
message - текст сообщения;
status - статус сообщений, пусть имеет значения awaiting или sent.
Вместо отправки добавим сообщение в таблицу в статусе awating (ожидает).
Регулярно пусть выполняется выгрузка из базы сообщений, которые ещё awaitng, но время уже наступило:
SELECT id,send_time,recipient_id,message FROM message_queue WHERE status='awaiting' AND send_time<NOW();
Извлечённые сообщения отправляем. Каждое переводим в статус sent, чтобы не отправить второй раз:
UPDATE message_queue SET status='sent' WHERE id=<id сообщения в очереди>;
Остаётся вопрос: как организовать регулярную выборку сообщений из очереди? Можно сделать по-разному:
1. Сделать отдельный тред в скрипте, который будет отслеживать очередь, перемежая это вызовами sleep. Или вместо треда таску в asyncio (если уже используется aiogram, то это более чем разумно).
2. Обрабатывать очеред в отдельном постоянно запущенном скрипте, либо запускать скрипт из cron каждую минуту.
Первый способ хорош тем, что всё в одном скрипте и потенциально очередь можно хранить не в базе, не в файле, не в брокере очереди типа rabbitmq, а прямо в переменной в скрипте. Правда, при этом в случае падения скрипта все запланированные задания на отправку будут потеряны. Второй хорош тем, что проблемы/тормоза скрипта отправке не будут вредить основному коду бота.
И, наконец, есть ещё один способ, при котором можно избежать организации очереди своими силами - использовать модули schedule/aioschedule (синхронный и асинхронный соответственно). Фактически, они берут на себя сохранение задания в очереди и вызов запрошенной функции в нужное время. Именно это тут посоветовали в первом ответе.
Mak_Sweet, где-то делаются запросы с этим токеном, то ли в этом боте, то ли в ещё где-то запущенном с таким же токеном.
По коду при поллинге none_stop=True приводит к тому, что бот делает повторные попытки, начиная с интервала 1/4 секунды и далее с увеличением в 2 раза последующие попытки. При этом ошибки будут логгироваться, но если событие в итоге обрабатывается, то это не страшно.
Александр Кошелев, есть гугл, есть море обзоров, есть каталоги типа https://vds.menu/ (это навскидку, таких сайтов куча), где можно подобрать самые разные варианты.
Скажем так, "небольшой объём" это очень расплывчатое понятие. Гигабайт, например, это как бы и немного, но дешёвые виртуалки настолько маленькие, что и это для них чересчур.
Тем не менее, варианты найти можно, например:
1. Есть бесплатные виртуалки от Oracle и бесплатные на год от Amazon.
2. Есть база Postgres в Heroku, но проект придётся запускать там же.
Но в целом непонятно, почему так остро хочется именно бесплатно? Сейчас дешёвые виртуалки продаются за копейки, один раз сходил в магазин за продуктами и вот уже год-другой их стоимости потратил.
Например, можно делать list пользователей на рассылку, брать из него элемент, посылать... Если случился Exception (лучше не какой попало, а понять, какой именно случается на те или иные ситуации) возвращать обратно в list и вставлять sleep например на 30 секунд; в следующей итерации на него будет новая отправка.
Тут главное отличать ошибки временные от ошибок фатальных. Например, если какой-то пользователь заблокирует бота, то такой подход может увести бота в бесконечный цикл.
В целом я советую идей рассылки пользователям в самом боте избегать. API ботов не для этого проектировалось.
Nick, если хочется клёво и красиво... Так-то можно tkinter, pygame или что-то ещё, а любители веб/электрона могут заинтересоваться его питон-аналогом eel.