Главная » Полезное » Discord как удалить все сообщения. Видит ли собеседник удаленные сообщения

Discord как удалить все сообщения. Видит ли собеседник удаленные сообщения

Discord стал местом встречи для геймеров по всему Интернету. Независимо от того, в какую игру вы играете, в Discord есть сообщество для неё. Учитывая количество геймеров по всему миру, которые используют эту программу, неудивительно, что боты Discord становятся всё более популярными.

Личные серверы могут использовать боты для игр с друзьями, в то время как общедоступные серверы могут использовать их для модерации пользователей. Для обоих типов серверов доступны полнофункциональные музыкальные боты, поэтому геймеры всегда могут послушать музыку во время игры. С таким количеством различных типов ботов, вам может быть трудно найти тот, который подходит именно вам. Сегодня бы расскажем о наиболее популярных ботах, и надеемся, что эта информация поможет вам определиться, стоит ли добавлять тот или иной бот в ваш канал или нет.

Музыкальные боты

Любой сервер может использовать музыкальные боты. В действительности, музыкальные боты настолько популярны, что на странице ботов Discord для них отведен целый раздел. Музыкальных ботов очень много, но два лучших из них – Erisbot и Pancake.

Erisbot интуитивно понятен и прост в использовании. Программа работает как музыкальный плеер, и включает в себя множество функций, подобно IPod. Вы даже можете использовать программу автономно. Кроме того, в ней есть забавные картинки и встроенный поиск по словарю городского сленга.

Pancake немного отличается, и предлагает всего несколько функций. Он работает как музыкальный бот подобно ErisBot, хотя и с меньшим количеством настроек и опций. Однако в нём также есть кое-какие изображения, игры и возможности модерации. Он делает всё понемногу и является отличным инструментом для использования, если вы хотите одного многофункционального бота, и не хотите добавлять много разных.

Боты-модераторы

Кроме Pancake существуют много ботов, выполняющих модерацию. Автоматическая модерация может быть очень полезна при управлении публичным сервером Discord, особенно если вы хотите поддерживать язык и содержимое чатов в порядке.

Как и Pancake, Dyno является многофункциональным ботом. Как и Pancake, он может проигрывать музыку, но его основная функция – это модерация. В отличие от большинства ботов, у Dyno есть автоматическая модерация и приветственные сообщения, поэтому он может управлять целым каналом, без необходимости постоянного присутствия модераторов в чате.

Хотя Dyno – многофункциональный бот, Auttaja предназначен практически исключительно для модерирования. При этом потенциал Auttaja огромен. Помимо того, что бот автоматически модерирует чаты, но он также может модерировать систематические процессы, такие как имена пользователей и наказания.

Игровые / развлекательные боты

Одни из самых популярных ботов – это интерактивные игровые или развлекательные боты. Два самых популярных бота в этой категории – это Pokecord и Dank Memer.

Pokecord – симпатичная интерактивная игра, которая в основном создает текстовое приключение Pokemon в вашем канале. Это весёлый и простой способ привлечь ваших участников Discord к игре.

– глупый бот, который разве только позволит вашему уму немного повеселиться. Он позволяет создавать мемы и делиться ими, а также имеет в своём функционале некоторые другие развлечения. Однако в первую очередь он предназначен для создания мемов из популярных онлайн-изображений.

Не можете найти подходящий бот – создайте свой собственный!

Хотя существуют сотни ботов Discord, каждый со своими уникальными настройками и широким диапазоном команд, возможно, вы не найдёте того, который был бы адаптирован к вашим конкретным потребностям. Или, может быть, вы просто хотите иметь полную настройку или более ограниченный доступ к боту. В любом случае, существуют несколько способов сделать собственного бота, но мы сосредоточимся на самом простом и эффективном способе:

Первое, что вам нужно сделать, это войти в Discord, перейти на страницу приложений и нажать «Создать приложение» (“Create an application”).

Затем добавьте название приложения (и аватар, если хотите), и нажмите «Бот» (“Bot”) на панели с левой стороны. Там же нажмите «Добавить бот» (“Add bot”). Затем вы увидите всплывающее окно с вопросом, хотите ли вы продолжить, щёлкните «Да» (“Yes”).

Отсюда вы можете указать ваши конкретные полномочия. Это можно настроить исходя из ваших предпочтений. Под именем пользователя бота теперь должен появиться раздел под названием «Токен» (“Token”). Под ним щёлкните ссылку «Нажмите, чтобы открыть токен» (“Click to reveal token”). Скопируйте код токена, он вам ещё понадобится

Затем в левой части нажмите «OAuth2». Здесь вы должны указать, какую программу вы создаете. Нажмите «Бот», а затем скопируйте URL-адрес, который будет отображён. Вы перейдёте на страницу, на которой вы сможете добавить бота на любой из серверов, которыми вы управляете. Далее выберите сервер, к которому вы хотите добавить бота.

Здесь вам понадобится какая-нибудь программа для кодирования и определённые знания, чтобы в полной мере использовать бота. Чтобы активировать бота, вам понадобится текстовый редактор, такой как NotePad, и инструмент для кодирования, такой как JavaScript. Вам нужно будет взять токен, который вы получили раньше, и сохранить его как документ NotePad в папку для своего бота. Этот документ должен иметь название «auth.json» и должен быть написан следующим образом:

“token”:

You’ll need to create two more files to run your bot. One should be saved as package.json with the following code:

“name”: “greeter-bot”,

“version”: “1.0.0”,

“description”: “”,

“main”: “bot.js”,

“author”: “”,

“dependencies”: {}

Для последнего кода создайте файл и назовите “bot.js.” Здесь вы должны детализировать основные функции бота. Предпочтительнее если у вас есть некоторые знания и навыки кодирования, чтобы вы могли создать бота с тем набором функций, которые вам нужны. Однако на сайте Medium представлен простой код бота Discord. Таким образом, если вы не знакомы с JavaScript, вы можете использовать следующий код для создания бота с простым набором функций.

var Discord = require(‘discord.io’); var logger = require(‘winston’); var auth = require(‘./auth.json’); // Configure logger settings logger.remove(logger.transports.Console); logger.add(logger.transports.Console, { colorize: true }); logger.level = ‘debug’; // Initialize Discord Bot var bot = new Discord.Client({ token: auth.token, autorun: true }); bot.on(‘ready’, function (evt) { logger.info(‘Connected’); logger.info(‘Logged in as: ‘); logger.info(bot.username + ‘ – (‘ + bot.id + ‘)’); }); bot.on(‘message’, function (user, userID, channelID, message, evt) { // Our bot needs to know if it will execute a command // It will listen for messages that will start with `!` if (message.substring(0, 1) == ‘!’) { var args = message.substring(1).split(‘ ‘); var cmd = args;

args = args.splice(1); switch(cmd) { // !ping case ‘ping’: bot.sendMessage({ to: channelID, message: ‘Pong!’ }); break; // Just add any case commands if you want to.. } } });

Наконец, вы можете запустить этот код, открыв JavaScript (или любую другую программу для кодирования по вашему выбору) и набрав “npm install discord.io winston –save” – который установит все программы, которые вам нужны для работы бота. Затем вводите “node bot.js” каждый раз, когда вы хотите запустить бот.

Поскольку этот процесс требует некоторых знаний по кодированию, и созданы уже сотни ботов, вам следует рассмотреть их, прежде чем пытаться создать свой собственный. Конечно, у вас может возникнуть искушение просто сразу создать собственный, в то время, как есть множество уже существующих ботов, которые могут делать именно то, что вам нужно.

  • Перевод

Discord продолжает расти быстрее, чем мы ожидали, как и пользовательский контент. Чем больше пользователей - тем больше сообщений в чате. В июле мы объявили о 40 млн сообщений в день , в декабре объявили о 100 млн , а в середине января преодолели 120 млн. Мы сразу решили хранить историю чатов вечно, так что пользователи могут вернуться в любой момент и получить доступ к своим данным с любого устройства. Это много данных, поток и объём которых нарастает, и все они должны быть доступными. Как мы это делаем? Cassandra!

Что мы делали

Изначальную версию Discord написали быстрее чем за два месяца в начале 2015 года. Возможно, одной из лучших СУБД для быстрого выполнения итераций является MongoDB. Всё в Discord специально хранилось в едином реплисете (replica set) MongoDB, но мы также готовили всё для простой миграции в новую СУБД (мы знали, что не собираемся использовать шардинг MongoDB из-за его сложности и неизвестной стабильности). На самом деле это часть нашей корпоративной культуры: разрабатывай быстро, чтобы испытать новую функцию продукта, но всегда с курсом на более надёжное решение.

Сообщения хранились в коллекции MongoDB с единым составным индексом на channel_id и created_at . Примерно в ноябре 2015 года мы вышли на рубеж 100 млн сообщений в базе, и тогда начали понимать проблемы, которые нас ждут: данные и индекс больше не помещаются в ОЗУ, а задержки становятся непредсказуемыми. Пришло время мигрировать в более подходящую СУБД.

Выбор правильной СУБД

Перед выбором новой СУБД нам требовалось понять имеющиеся шаблоны чтения/записи и почему возникли проблемы с текущим решением.
  • Быстро стало понятно, что операции чтения исключительно случайны, а соотношения чтение/запись примерно 50/50.
  • Тяжёлые серверы голосовых чатов Discord практически не присылали сообщений. То есть они присылали одно или два сообщения каждые несколько дней. За год сервер такого типа вряд ли достигнет рубежа в 1000 сообщений. Проблема в том, что даже несмотря на такое малое количество сообщений, эти данные труднее доставлять пользователям. Просто возвращение пользователю 50-ти сообщений может привести к многим случайным операциям поиска на диске, что приводит к вытеснению дискового кэша.
  • Тяжёлые серверы приватных текстовых чатов Discord отправляют приличное количество сообщений, легко попадая в диапазон между 100 тыс. и 1 млн сообщений в год. Запрашивают они обычно только самые последние данные. Проблема в том, что на этих серверах обычно менее 100 участников, так что скорость запроса данных низкая и вряд ли они будут в дисковом кэше.
  • Большие публичные серверы Discord отправляют очень много сообщений. Там тысячи участников, отправляющих тысячи сообщений в день. Легко набираются миллионы сообщений в год. Они почти всегда запрашивают сообщения, отправленные в последний час, и это происходит часто. Поэтому данные обычно находятся в дисковом кэше.
  • Мы знали, что в наступающем году у пользователей появится ещё больше способов генерировать случайные чтения: это возможность просматривать свои упоминания за последние 30 дней и затем перескакивать в тот момент истории, просмотр и переход к прикреплённым сообщениям и полнотекстовый поиск. Всё это означает ещё больше случайных чтений!
Затем мы определили наши требования:
  • Линейная масштабируемость - Мы не хотим пересматривать решение позже или вручную переносить данные в другой шард.
  • Автоматическая отказоустойчивость - Нам нравится спать по ночам и делать Discord настолько самоисцеляющимся, насколько это возможно.
  • Небольшая поддержка - Она должна работать сразу же, как мы её установим. От нас требуется только добавлять больше нод по мере увеличения данных.
  • Доказано в работе - Мы любим пробовать новые технологии, но не слишком новые.
  • Предсказуемая производительность - Нам отправляются сообщения, если время отклика API в 95% случаев превышает 80 мс. Мы также не хотим сталкиваться с необходимостью кэшировать сообщения в Redis или Memcached.
  • Не хранилище блобов - Запись тысяч сообщений в секунду не будет отлично работать, если нам придётся непрерывно десериализировать блобы и присоединять к ним данные.
  • Open source - Мы верим, что управляем собственной судьбой, и не хотим зависеть от сторонней компании.
Cassandra оказалась единственной СУБД, которая удовлетворила всем нашим требованиям. Мы можем просто добавлять ноды при масштабировании, а она справляется с потерей нод без всякого влияния на приложение. В больших компаниях вроде Netflix и Apple - тысячи нод Cassandra. Связанные данные хранятся рядом на диске, обеспечивая минимум операций поиска и лёгкое распределение по кластеру. Она поддерживается компанией DataStax, но распространяется с открытым исходным кодом и силами сообщества.

Сделав выбор, нужно было доказать, что он действительно оправдан.

Моделирование данных

Лучший способ описать новичку Cassandra - это аббревиатура KKV. Две буквы “K” содержат в себе первичный ключ. Первая “K” - это ключ раздела. Он помогает определить, в какой ноде живут данные и где их найти на диске. Внутри раздела множество строк, и конкретную строку внутри раздела определяет вторая “K” - ключ кластеризации. Он работает как первичный ключ внутри раздела и определяет способ сортировки строк. Можете представить раздел как упорядоченный словарь. Все эти качества вместе взятые позволяют очень мощное моделирование данных.

Помните, что сообщения в MongoDB индексировались с использованием channel_id и created_at ? channel_id стал ключом раздела, поскольку все сообщения работают в канале, но created_at не даёт хорошего ключа кластеризации, потому что два сообщения могут быть созданы в одно время. К счастью, каждый ID в Discord на самом деле создан в Snowflake , то есть хронологически сортируется. Так что можно было использовать именно их. Первичный ключ превратился в (channel_id, message_id) , где message_id - это Snowflake. Это значит, что при загрузке канала мы можем сказать Cassandra точный диапазон, где искать сообщения.

Вот упрощённая схема для нашей таблицы сообщений (она пропускает примерно 10 колонок).

CREATE TABLE messages (channel_id bigint, message_id bigint, author_id bigint, content text, PRIMARY KEY (channel_id, message_id)) WITH CLUSTERING ORDER BY (message_id DESC);
Хотя схемы у Cassandra и похожи на схемы реляционных БД, их легко изменять, что не оказывает какого-либо временного влияния на производительность. Мы взяли лучшее от хранилища блобов и реляционного хранилища.

Как только начался импорт существующих сообщений в Cassandra, мы сразу увидели в логах предупреждения, что найдены разделы размером более 100 МБ. Да ну?! Ведь Cassandra заявляет о поддержке разделов 2 ГБ! По всей видимости, сама возможность не означает, что так нужно делать. Большие разделы накладывают сильную нагрузку на сборщик мусора в Cassandra при уплотнении, расширении кластера и т.д. Наличие большого раздела также означает, что данные в нём нельзя распределить по кластеру. Стало ясно, что нам придётся как-то ограничить размеры разделов, потому что некоторые каналы Discord могут существовать годами и постоянно увеличиваться в размере.

Мы решили распределить наши сообщения блоками (buckets) по времени. Мы посмотрели на самые большие каналы в Discord и определили, что если хранить сообщения блоками примерно по 10 дней, то комфортно вложимся в лимит 100 МБ. Блоки нужно получать из message_id или метки времени.

DISCORD_EPOCH = 1420070400000 BUCKET_SIZE = 1000 * 60 * 60 * 24 * 10 def make_bucket(snowflake): if snowflake is None: timestamp = int(time.time() * 1000) - DISCORD_EPOCH else: # When a Snowflake is created it contains the number of # seconds since the DISCORD_EPOCH. timestamp = snowflake_id >> 22 return int(timestamp / BUCKET_SIZE) def make_buckets(start_id, end_id=None): return range(make_bucket(start_id), make_bucket(end_id) + 1)
Ключи разделов Cassandra могут быть составными, так что нашим новым первичным ключом стал ((channel_id, bucket), message_id) .

CREATE TABLE messages (channel_id bigint, bucket int, message_id bigint, author_id bigint, content text, PRIMARY KEY ((channel_id, bucket), message_id)) WITH CLUSTERING ORDER BY (message_id DESC);
Для запроса недавних сообщений в канале мы сгенерировали диапазон блоков от текущего времени до channel_id (он тоже хронологически сортируется как Snowflake и должен быть старше, чем первое сообщение). Затем мы последовательно опрашиваем разделы до тех пор, пока не соберём достаточно сообщений. Обратная сторона такого метода в том, что изредка активным инстансам Discord придётся опрашивать много разных блоков, чтобы собрать достаточно сообщений со временем. На практике оказалось, что всё в порядке, потому что для активного инстанса Discord обычно находится достаточно сообщений в первом разделе, и таких большинство.

Импорт сообщений в Cassandra прошёл без помех, и мы были готовы опробовать её в производстве.

Тяжёлый запуск

Выводить новую систему в производство всегда страшно, так что хорошей идеей будет проверить её, не затрагивая пользователей. Мы настроили систему на дублирование операций чтения/записи в MongoDB и Cassandra.

Немедленно после запуска в баг-трекере появились ошибки, что author_id равен нулю. Как он может быть нулевым? Это обязательное поле!

Согласованность в конечном счёте

Cassandra - система типа , то есть гарантированная целостность здесь приносится в жертву доступности, что мы и хотели, в общем. В Cassandra противопоказано чтение перед записью (операции чтения более дорогие) и поэтому всё, что делает Cassandra, - это обновление и вставку (upsert), даже если предоставить только определённые колонки. Вы также можете писать в любую ноду, и она автоматически разрешит конфликты, используя семантику «последняя запись выигрывает» по каждой колонке. Так как это нас коснулось?


Пример состояния гонки редактирование/удаление

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

  1. Записывать обратно целое сообщение во время редактирования сообщения. Тогда есть возможность воскрешения удалённых сообщений и добавляются шансы конфликтов для одновременных записей в другие колонки.
  2. Выявить повреждённое сообщение и удалить его из базы.
Мы выбрали второй вариант, определив требуемую колонку (в этом случае author_id) и удаляя сообщение, если оно пустое.

Решая эту проблему, мы заметили, что были весьма неэффективны с операциями записи. Поскольку Cassandra согласована в конечном счёте, то она не может вот так взять и немедленно удалить данные. Ей нужно реплицировать удаления на другие ноды, и это следует сделать даже если ноды временно недоступны. Cassandra справляется с этим, приравнивая удаление к своеобразной форме записи под названием “tombstone” («надгробие»). Во время операции чтения она просто проскакивает через «надгробия», которые встречаются по пути. Время жизни «надгробий» настраивается (по умолчанию, 10 дней), и они навсегда удаляются во время уплотнения базы, если срок вышел.

Удаление колонки и запись нуля в колонку - это абсолютно одно и то же. В обоих случаях создаётся «надгробие». Поскольку все записи в Cassandra являются обновлениями и вставками, то вы создаёте «надгробие» даже если изначально записываете нуль. На практике, наша полная схема сообщения состояла из 16 колонок, но среднее сообщение имело только 4 установленных значения. Мы записывали 12 «надгробий» в Cassandra, обычно без всякой причины. Решение проблемы было простым: записывать в базу только ненулевые значения.

Производительность

Известно, что Cassandra быстрее выполняет операции записи, чем чтения, и мы наблюдали в точности это. Операции записи происходили в интервале менее миллисекунды, а операции чтения - менее 5 миллисекунд. Такие показатели наблюдались независимо от типа данных, к которым осуществлялся доступ. Производительность сохранялась неизменной в течение недели тестирования. Ничего удивительного, мы получили в точности то, чего ожидали.


Задержка чтения/записи, по данным из лога

В соответствии с быстрой, надёжной производительностью чтения, вот пример перехода к сообщению годичной давности в канале с миллионами сообщений:

Большой сюрприз

Всё прошло гладко, так что мы выкатили Cassandra как нашу основную базу данных и вывели из строя MongoDB в течение недели. Она продолжала безукоризненно работать… примерно 6 месяцев, пока однажды не перестала реагировать.

Мы заметили, что Cassandra непрерывно останавливается на 10 секунд во время сборки мусора, но совершенно не могли понять, почему. Начали копать - и нашли канал Discord, который требовал 20 секунд для загрузки. Виновником был публичный Discord-сервер подреддита Puzzles & Dragons . Поскольку он публичный, мы присоединились посмотреть. К нашему удивлению, на канале было только одно сообщение. В тот момент стало очевидно, что они удалили миллионы сообщений через наши API, оставив только одно сообщение на канале.

Если вы внимательно читали, то помните, как Cassandra обрабатывает удаления при помощи «надгробий» (упомянуто в главе «Согласованность в конечном счёте»). Когда пользователь загружает этот канал, хоть там одно сообщение, Cassandra приходится эффективно сканировать миллионы «надгробий» сообщений. Тогда она генерирует мусор быстрее, чем JVM может собрать его.

Мы решили эту проблему следующим образом:

  • Уменьшили время жизни надгробий с 10 дней до 2 дней, потому что мы каждый вечер запускаем починку Cassandra (противоэнтропийный процесс) на нашем кластере сообщений.
  • Изменили код запросов, чтобы отслеживать пустые блоки на канале и избегать их в будущем. Это значит, что если пользователь снова инициировал этот запрос, то в худшем случае Cassandra будет сканировать только самый последний блок.

Будущее

В данный момент у нас работает кластер из 12 нодов с коэффициентом репликации 3, и мы продолжим добавлять новые ноды Cassandra по мере надобности. Мы верим, что этот подход работоспособен в долговременной перспективе, но по мере роста Discord просматривается отдалённое будущее, когда придётся сохранять миллиарды сообщений в день. У Netflix и Apple работают кластеры с сотнями нодов, поэтому пока что нам не о чем волноваться. Однако хочется иметь пару идей про запас.

Ближайшее будущее

  • Обновить наш кластер сообщений с Cassandra 2 на Cassandra 3. Новый формат хранения в Cassandra 3 может сократить объём хранения более чем на 50%.
  • Более новые версии Cassandra лучше справляются с обработкой большего количества данных в каждом ноде. Мы сейчас храним примерно 1 ТБ сжатых данных в каждом из них. Думаем, что можно безопасно сократить количество нодов в кластере, увеличив этот лимит до 2 ТБ.

Отдалённое будущее

  • Изучить Scylla - это СУБД, совместимая с Cassandra и написанная на C++. В нормальной работе наши ноды Cassandra в реальности потребляют немного ресурсов CPU, однако в непиковые часы во время починки Cassandra (противоэнтропийный процесс) они довольно сильно зависят от CPU, а время починки возрастает в зависимости от количества данных, записанных с момента прошлой починки. Scylla обещает значительно увеличить скорость починки.
  • Создать систему для архивации неиспользуемых каналов в Google Cloud Storage и загрузки их обратно по требованию. Мы хотим избежать этого и не думаем, что такое придётся делать.

Заключение

Прошло уже больше года с момента перехода на Cassandra, и несмотря на «большой сюрприз» , это было спокойное плавание. Мы вышли с более 100 миллионов общего количества сообщений на более чем 120 миллионов сообщений в день, сохранив производительность и стабильность.

Благодаря успеху этого проекта, с тех пор мы перенесли все остальные наши данные в производстве на Cassandra, и тоже успешно.

В продолжении этой статьи мы исследуем, как мы осуществляем полнотекстовый поиск по миллиардам сообщений.

У нас до сих пор нет специализированных инженеров DevOps (только четыре инженера бэкенда), так что очень классно иметь систему, о которой не приходится волноваться. Мы набираем сотрудников, так что обращайтесь , если подобные задачки щекочут ваше воображение.

Теги: Добавить метки

Зачастую у пользователей текстовых чатов возникает желание удалить всю старую переписку, как потерявшую актуальность, и занимающую лишнее место. Между тем, попытки сделать это через программный интерфейс не позволяют этого сделать. Как же быть в данной ситуации, и имеется ли возможность провести очистку?

Понятие чата

Под чатом в программе Discord понимаются отдельные каналы. Они в свою очередь по типу используемых способов общения подразделяются на голосовые и текстовые.

В качестве базового элемента работы в Discord выступает сервер, создаваемый пользователем. После этого уже в нем имеется возможность создания неограниченного количества каналов обоих типов.

Очистка чата в программе Discord

Сразу необходимо сказать, что инструментов для моментального удаления всех сообщений, скопившихся в канале, приложение пользователям не предоставляет. Удаление возможно только отдельных записей (сообщений). Тем не менее, существует один способ, позволяющий ускорить процесс очистки. Речь идет о таком термине как «реакция», то есть ответ других участников беседы на выложенные сообщения.

Для удаления всех реакций, имеющихся в чате, предусматривается следующий порядок действия:

  • Войти в программу Discord;
  • Выбрать интересующий канал;
  • С правой стороны от выбранного сообщения нажать за значок «двоеточие»;
  • Выбрать из выпадающего меню вариант «Удалить все реакции».

Конечно, таким образом невозможно одним нажатием провести чистку всех сообщений, но это позволит существенно снизить потребное время для проведения полной очистки. Сами же сообщения участников беседы придется удалять вручную по одному.

Для этого требуется:

  • Войти в приложение;
  • Выбрать интересующий канал;
  • Напротив каждого сообщения нажать на значок «двоеточие»;
  • Выбрать из выпадающего меню вариант «Удалить».

Можно провести удаление и путем выделения текста сообщения правой клавишей с дальнейшим нажатием на предлагаемый вариант действий «Удалить».

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

  • Зайти в приложение;
  • Выбрать интересующий канал;
  • Перейти в раздел «Меню» или кликнуть правой кнопкой;
  • Из предложенного списка действий выбрать вариант «Удалить канал».

Таким образом, возможно, как удаление самого канала, так и записей в нем. Пусть последняя процедура и требует определенных потерь времени.

О самой программе

Программа Discord предназначена для организации голосового общения игроков онлайн-игр. Конечно, сервис предлагает и стандартные возможности текстового общения, но при этом необходимо признать, что по уровню функциональных возможностей текстовые каналы приложения уступают мессенджерам. Нельзя не признать, что проект Discord ориентирован в первую очередь на геймерскую аудиторию.

Сейчас, когда компьютерная и мобильная технология развита непогодам, вопрос первой важности сосредоточен на возможностях поддерживать общение между собой.

Мессенджеры позволяют в реальном времени обсудить любые вопросы, начиная от приватных и заканчивая деловыми конференциями. Поэтому их популярность ничуть не меньше чем у многопользовательских игр.

Все мессенджеры имеют одну проблему, которая заключается в быстром скоплении старых сообщений. Они занимают лишнюю память на вашем устройстве.

Очистка чата в Дискорде (инструкция)

Регулярное общение в мессенджере имеет свойство забивать память устройства. Сообщения накапливаются, а многие из них не несут смысловой нагрузки. Поэтому их удаление необходимо.

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

  • Удалить канал.
  • Отдельное удаление каждого сообщения.
  • Удаление всех сообщений за последнюю неделю.

После отправки есть всего несколько секунд которые позволяют удалить сообщение до того как его увидят все участники канала. Выбор метода очистки очень ситуативный, и подбирается под личные потребности создателя сервера. Подробнее о каждом из методов с инструкцией использования.

Способ первый, удалить весь канал и создать новыйР2>

Проще варианта не придумать. Когда тема исчерпала себя, или просто накопилось много компромата в обсуждениях, удалите полностью канал и создайте новый. Удаление происходит за несколько секунд, и восстановлению не подлежит.

Внимание! Если есть важная информация, перепишите в отдельный документ или пересохраните скриншотами.

Нужно выполнить несколько простых шагов:



Затем создаете новый, можно даже с прежним названием.

Способ второй: удаляем каждое сообщение по отдельности

Самый длительный способ чистки. По причине больших временных затрат, подходит только для удаления небольшого количества. Инструкция по использованию:



Удаленные сообщения пропадут у всех пользователей канала. Если было отмечено в закладки – пропадет.

Способ третий: чистка за последних 7 дней

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

  • За двадцать четыре часа.
  • Или последние семь дней (и ночей).


Как поместить человека в черный список :

  • на имени пользователя нажать правой кнопкой мышки и выбрать – Забанить (дальше будет указан никнейм пользователя).


Указывать причину по желанию, можете оставить поле пустым.

Как часто стоит очищать чат?

Очистка чата полностью зависит от вашей тематики сообщества. Если вы обмениваетесь юмором, тогда нет смысла удалять, лучше оставить все как есть, чтобы можно было, вернутся к понравившейся записи.

Если у вас сборная солянка, условно, полная свобода обсуждения на разные тематики, то лучше подчищать хотя бы раз в несколько дней. В идеале конечно – раз в сутки. Конкретных требований в этом вопросе нет, поэтому каждый Администратор сам устанавливает себе планку в этом вопросе.



Предыдущая статья: Следующая статья:

© 2015 .
О сайте | Контакты
| Карта сайта