Потому что Дуров использует шифрование в чатах, а это мешает слежке, и бекдор не хочет пихать.

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

До народа не доходит простая мысль

что если месенджер работает в россии - органы его читают

несмотря на шифрование

Если родина не читает - месенджер в стране не работает

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

есть

в личных переписках будет e2e шифрование

а по умолчанию шифрование до серверов телеги

есть

А есть пруфы? На странице месседжера такой инфы не нашел

тебе каких?

тебе каких?

https://tlgrm.ru/faq#%D0%BD%D0%B0%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%B5%D0%BD-%D1%82%D0%B5%D0%BB%D0%B5%D0%B3%D1%80%D0%B0%D0%BC Тут написано про возможность шифрование частных чатов. А есть ли где то подтверждение шифрования переписок вне "секретных чатов" ?

да, для частных есть e2e

да, для частных есть e2e

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

нет, почитай что такое e2e

оно есть только для частных, для остальных обычное шифрование как https

@dnb_page https://core.telegram.org/mtproto This page deals with the basic layer of MTProto encryption used for Cloud chats (server-client encryption).

Дядя майора ФСБ читает :)

Всем привет. Мне интересно тут стало. А кто вообще юзал в продакшене Workerman для вебсокетов ? Просто я традиционно для вебсокетов юзаю nodejs + socket.io или sockjs.

@nurik6 переходи на golang

@nurik6 переходи на golang

Не хочу. Меня всё устраивает.

Всем привет. Мне интересно тут стало. А кто вообще юзал в продакшене Workerman для вебсокетов ? Просто я традиционно для вебсокетов юзаю nodejs + socket.io или sockjs.

Привет! А почему именно workerman, а не ratchet? Есть какие то особые плюсы?

Привет! А почему именно workerman, а не ratchet? Есть какие то особые плюсы?

ХЗ, но когда-то нужно было заюзать ratchet, на тот момент не понял как ssl прикрутить. Долго возился в итоге бросил эту затею.А Workerman из коробки это уже умеет.

Интереса ради - как ВЫ храните дату в базе? Конкретно до секунд. Имею ввиду в каком типе данных? Какие плюсы и минусы? Находил даже плюсы где-то на стаковерфлоу за тип (int) Что правильнее и надежнее? И как потом с этим типом работаете? (Int например можно через date конвертировать, а DATETIME в виде строки идет кажется, что лучше использовать?)

И учитываете ли вы временную зону пользователя в этом случае? (не уверен какой из типов зависит от нее)

Int

Временную зону на клиенте конвертируешь

С разницей от серверной

datetime, потому что нативное поле и всё работает прозрачно.

datetime, потому что нативное поле и всё работает прозрачно.

а что насчет зоны? или это timestamp сохраняет в базу с учетом времени? datetime сохраняет без учета?

Int

Какие минусы у этого метода хранения в отличие от того же datetime?

а что насчет зоны? или это timestamp сохраняет в базу с учетом времени? datetime сохраняет без учета?

от зоны серваера. Для каждого проекта индивидуально обычно.

ну т.е хранить в int это норм практика?

ну т.е хранить в int это норм практика?

норм, просто придётся работать как с int а не как с объектом.

ну т.е хранить в int это норм практика?

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

Но ведь можно создать объект DateTime из таймштампа. а по сути интовое значение таймштамп Да и из базы, кажется приходит просто строкой при селекте, разве нет?

Просто я столкнулся с тем, что grafana не понимает дату в виде интового значения, судя по всему

а дату как дату - вроде хавает адекватно

Но мне не очень хочется хранить ее в виде строки и доставать постоянно один тип и заниматься его переводом в другой вид

Но ведь можно создать объект DateTime из таймштампа. а по сути интовое значение таймштамп Да и из базы, кажется приходит просто строкой при селекте, разве нет?

Строка Timestamp однозначна (в ней есть timezone), int - нет.

Решение стоит принимать исходя из данных проекта. Если Timezone важен, то лучше хранить переменнную Timezone пользователя в данных пользователя. Её проще использовать при создании и работе с объектом. Это обычно не важно, если проект локализован. Например для одного города или часового пояса.

Ну и напоследок. Если проект только для русских - дешевле хранить int и смещение в ячейке пользователя. Размер данных меньше.

в дебиане 8 ссш для рута выключили. Час пытался понять почему после обновления не могу подключиться

=)

Int

зачем int если есть timestamp?

Строка Timestamp однозначна (в ней есть timezone), int - нет.

в какой БД?

Интереса ради - как ВЫ храните дату в базе? Конкретно до секунд. Имею ввиду в каком типе данных? Какие плюсы и минусы? Находил даже плюсы где-то на стаковерфлоу за тип (int) Что правильнее и надежнее? И как потом с этим типом работаете? (Int например можно через date конвертировать, а DATETIME в виде строки идет кажется, что лучше использовать?)

если после 1970, то unix time, иначе в datetime + отдельно временная зона

в какой БД?

mysql

Временная зона мне в принципе не нужна для хранения

ты время как char хранишь?

Мне нужно точное число одинаковое у всех

не как char, как int

откуда тогда там временная зона?

В смысле. Я говорю просто - кто как хранит Как лучше Не плохо ли в инте хранить Причем тут ваш вопрос

я не говорю что в инте временная зона

что тогда такое "строка timestamp"

Строка Timestamp однозначна (в ней есть timezone), int - нет.

Строка Timestamp однозначна (в ней есть timezone), int - нет.

DATETIME, опечатался. Ну всмысле не int.

ERROR: S client not available

что тогда такое "строка timestamp"

Кому вопрос адресуете? Жмите "Reply" вместо "Forward"

Кому вопрос адресуете? Жмите "Reply" вместо "Forward"

ты ответил на мой reply другого человека

Короче - задача хранить точное число секунд, одинаковое у всех и везде, т.е таймштамп. Вопрос что лучше. Инт или не инт и в чем преимущества

лучше timestamp

лучше timestamp

timestamp === int ))) И всегда UTC.

timestamp === int ))) И всегда UTC.

Т.е разницы нет?

timestamp === int ))) И всегда UTC.

только на уровне диска, СУБД с тобой не согласна

на int ты не сможешь временые функции применять

а на timestamp без проблем

между полем типа TIMESTAMP и 4х байтным числом - нет.

на int ты не сможешь временые функции применять

ты имеешь ввиду временные функции mysql?

да

ну а так, ничего "ужасного" в инте нет, я понял, спасибо.

ничего ужасного для хранения чисел

только на уровне диска, СУБД с тобой не согласна

При хранении, хранится 4х байтное число, при запросе, выводится с учётом настроек СУБД.

При хранении, хранится 4х байтное число, при запросе, выводится с учётом настроек СУБД.

SUBTIME на int покажешь?

SUBTIME(FROM_UNIXTIME(int),int) например?

SUBTIME на int покажешь?

Ты вообще ко мне то чо прикопался? Я считаю что надо выбирать исходя из потребностей проекта - и в том и другом случае есть удобства.

просто не вижу смысла использовать int сместо timestamp, а у тебя есть знание о причинах, но ты молчишь

А по существу вопроса это и есть ответ - выбери себе как хранить в зависимости от аудитории проекта. Всё. Преимущества можно долго ковырять.

просто не вижу смысла использовать int сместо timestamp, а у тебя есть знание о причинах, но ты молчишь

Если тебе надо ОЧЕНЬ много хранить отметок времени и у тебя пользователи из определённых таймзон, то дешевле хранить int. Размер меньше.

так ты определить, меньше или нет разницы

между полем типа TIMESTAMP и 4х байтным числом - нет.

http://gpshumano.blogs.dri.pt/files/2009/07/mysql_dt_myisam.jpeg

http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-innodb/

int быстрее, из-за навешивания time функций на int - timestamp медленнее. Если ты занимаешься приводом цифр к дате НЕ в базе - int хранить дешевле и быстрее. Достаточно причин?

July 6th, 2009 не легко тебе с mysql 5.3

July 6th, 2009 не легко тебе с mysql 5.3

Ты по какой-то причине считаешь что голый int может быть медленнее int'a с навешенными функциями? Не зависимо от версий?

Здарова Mad!!!