Context — почему я решил объединить переписку и задачи в одном сервисе
История создания Context: как связать обсуждения, задачи и решения, сохранить историю проекта и защитить переписку с помощью шифрования.
В разработке есть одна проблема, с которой я сталкивался много раз. Причём неважно, работаешь ты в небольшой команде или над большим проектом.
Мы постоянно что-то обсуждаем, принимаем решения, договариваемся. А потом эта информация теряется.
Обсудили задачу в мессенджере. Завели её в таск-трекере. Макеты положили в отдельное хранилище. Через две недели возвращаешься к задаче и пытаешься вспомнить: почему мы вообще решили сделать именно так?
Начинаешь искать переписку, спрашивать коллег, поднимать историю обсуждений.
И я задумался: а почему обсуждение и задача вообще должны существовать отдельно?
Так появилась идея Context.
Не ещё один мессенджер
На рынке достаточно инструментов для командной работы. Есть Slack, Telegram, Jira, Trello, Notion и десятки других.
Каждый из них по-своему решает определённую задачу. Но мне хотелось изменить сам подход к организации работы.
В большинстве привычных сценариев мы сначала общаемся, а потом переносим результат общения куда-то ещё.
В Context я решил сделать иначе.
Обсуждение — это начало работы. Задача — продолжение обсуждения. А принятое решение — часть общей истории.
Представим обычную ситуацию.
Команда обсуждает новую страницу сайта. Дизайнер предлагает изменить первый экран. Разработчик объясняет технические ограничения. В итоге все договариваются о конкретном решении.
В привычном процессе кто-то создаёт задачу в трекере, пишет короткое описание и, возможно, прикладывает ссылку на переписку.
Но часть информации уже потеряна.
В Context задача создаётся непосредственно из сообщения. Она сохраняет связь с исходным обсуждением, а участники в любой момент могут вернуться назад и посмотреть, с чего всё началось.
Это небольшое изменение в пользовательском сценарии, но, на мой взгляд, очень важное.
У каждой задачи должна быть история
Мне не хотелось создавать сложную систему управления проектами, в которой ради одного действия нужно пройти через пять экранов.
Я хотел, чтобы работа выглядела естественно.
У команды есть проекты. Внутри проектов — темы для обсуждения. В обсуждениях появляются сообщения, файлы, идеи и решения.
Когда возникает необходимость что-то сделать, сообщение превращается в задачу.
При этом исходная переписка никуда не исчезает.
Не нужно заводить ещё одну ветку комментариев к задаче и дублировать информацию в разных местах. История остаётся единой.
Отдельное внимание я уделил тому, чтобы пользователь мог быстро понять, что происходит: где требуется его участие, какие задачи ждут выполнения и на чём сейчас сосредоточена команда.
Собственно, отсюда и название — Context.
Важно не просто знать, что нужно сделать. Важно понимать, почему это нужно сделать.
А что с безопасностью?
В какой-то момент разработки я задумался о другой стороне продукта.
Если сервис хранит рабочие переписки, задачи, документы и обсуждения, значит, в нём потенциально находится большое количество информации, которую пользователи не хотели бы раскрывать.
И здесь появляется неприятный вопрос.
Что произойдёт, если кто-нибудь получит копию базы данных?
Часто в новостях об утечках мы читаем, что злоумышленники получили доступ к базе какого-нибудь сервиса.
Но сама по себе база — это только набор данных.
Гораздо важнее другое: смогут ли посторонние прочитать то, что в ней хранится?
Если сообщения лежат в открытом виде, ответ очевиден.
Я решил, что для Context такой подход не подходит.
Поэтому мы добавили шифрование хранимых данных.
Как работает шифрование в Context
Представьте обычный запечатанный конверт.
Снаружи можно увидеть, кому он адресован и когда отправлен. Но прочитать письмо, не вскрыв конверт, невозможно.
Похожий принцип теперь применяется к содержимому переписки в Context.
Сообщения, черновики и другие защищаемые данные хранятся в зашифрованном виде. Для их расшифровки необходим отдельный ключ.
Причём ключи не должны находиться внутри самой базы или её резервной копии.
Это принципиальный момент.
Если злоумышленник получит только копию базы данных, без соответствующих ключей он не сможет просто открыть её и прочитать переписку.
Шифрование распространяется и на вложения. Защищается не только содержимое файла, но и его имя.
Вместо понятного документа с узнаваемым названием атакующий, получивший только зашифрованные файлы, увидит данные, которые не сможет интерпретировать без ключа.
Для пользователя при этом практически ничего не меняется.
Он по-прежнему открывает обсуждения, читает сообщения, ищет нужную информацию, работает с задачами и скачивает вложения.
Шифрование происходит на стороне сервиса.
И здесь важно уточнить: это не сквозное шифрование.
Сервер Context имеет техническую возможность расшифровывать данные для работы приложения. Поэтому защита не рассчитана на ситуацию, когда атакующий полностью контролирует работающий сервер вместе с ключами.
Её задача — защитить содержимое при утечке отдельных хранилищ или резервных копий, если ключи не были скомпрометированы.
Мне кажется, в вопросах безопасности лучше честно объяснять ограничения, чем обещать абсолютную защищённость.
Мало зашифровать. Нужно убедиться, что всё работает
Шифрование — это не та функция, которую можно считать готовой только потому, что соответствующий код написан.
Поэтому отдельной задачей стала проверка того, как система ведёт себя после внедрения защиты.
Мы проверили содержимое базы после переноса данных: сообщения и черновики должны храниться в зашифрованном виде, а не обычным текстом.
Затем протестировали запуск приложения без ключа.
В таком сценарии сервис должен отказывать в запуске, а не незаметно возвращаться к незащищённому режиму.
Ещё одна важная проверка — восстановление из резервной копии.
Недостаточно сохранить данные. Нужно убедиться, что после восстановления с необходимыми ключами переписка, вложения, поиск и остальные функции продолжат работать корректно.
В описанных тестах удалось восстановить данные, проверить целостность вложений и подтвердить, что без ключа защищённое содержимое не читается.
Для меня это важная часть инженерной работы: продумать не только нормальный сценарий, но и то, как система ведёт себя в случае ошибки.
Почему я вообще взялся за собственный продукт
За годы работы в веб-разработке мне приходилось создавать самые разные системы: корпоративные сайты, CRM, сервисы бронирования, инструменты автоматизации и внутренние продукты для бизнеса.
Практически везде я видел одну закономерность.
Люди тратят огромное количество времени не на выполнение работы, а на поиск информации о ней.
Где обсуждали? Кто согласовал? Почему решили именно так? Где последний вариант файла?
Мне хочется попробовать сделать инструмент, который хотя бы часть этих вопросов уберёт.
При этом я не ставлю перед собой задачу создать очередного гиганта, который заменит все существующие сервисы.
Наоборот, хочется сохранить простоту.
Чтобы команда могла открыть Context и сразу начать работать, не изучая огромную систему.
Что дальше
Сейчас Context находится в разработке. Основная идея продукта уже сформирована, а на сайте можно посмотреть интерфейс и попробовать интерактивный сценарий создания задачи из сообщения.
В дальнейшем я хочу развивать продукт, опираясь прежде всего на реальные сценарии командной работы.
AI-возможности и дополнительные инструменты тоже рассматриваются, но я не хочу добавлять искусственный интеллект исключительно ради того, чтобы он был.
Сначала инструмент должен хорошо решать основную задачу.
И только потом имеет смысл усложнять его функциональность.
Context для меня — попытка сделать так, чтобы работа не теряла свой смысл между перепиской и списком задач.
Посмотреть проект и попробовать интерактивное демо можно здесь: