@blue
И с riot интересная вещь. Ключи на сервер бэкапятся автоматом, а вот на устройство только руками, причём сохранять их нужно часто. Я как-то с парой чатов ключи сохранил, было 100 с чем-то. Они как бы заставляют пользоваться бэкапом на стороне сервера из-за неудобства локального хранения. Что мешало им сделать локальный автобэкап непонятно.
@amoeba@mastodon.ml
@savant
Никто, кроме сотрудников protonmail не знает наверняка, как оно работает. И нет гарантии, что они не имеют копии ключей. Даже если вы будете публиковать исходники сервера, никто не мешает вам скомпилить бинарники сервера с патчами из локального репа. Верификация здесь невозможна.
@amoeba@mastodon.ml @blue
@blue
В общем история про ещё один "RedHat" и новое "systemd", которое потом может оказаться в каждом "утюге".
Недостатки мобильных клиентов xmpp мы недавно обсуждали, плюс в нем есть некоторые, для меня, неприятные моменты с передачей файлов. И для некоторых людей настройка или даже регистрация акка xmpp является проблемой. Мне не сложно, когда-то tkabber'ом пользовался.
@amoeba@mastodon.ml
@blue
Они ещё вроде добавили поиск по истории зашифрованных сообщений. Как я понял, база данных с индексируемыми сообщениями. Очередная дыра в безопасности. Ещё одна дыра, перекрестное подтверждение, когда остальные устройства пользователя потдверждаются автоматически и плевать на то, что в этот момент может произойти компрометация. Зачем вообще нужны были тогда эти "танцы" с индетификацией устройств, непонятно. Похоже Riot плавно превращается в подобие telegram.
Я все жду, что может кто-нибудь форкнет Jami и прикрутит к нему e2e шифрование.
В мире opensource последнее время все через одно место. Bitmessage заброшен, из мессенджеров ничего нормального не появилось. А то что есть, куда-то катится на поводу у проприетарщины.
@amoeba@mastodon.ml
@Revertron
Командами, как на dial-up'е.
@blue @amoeba@mastodon.ml @rplatonov@mastodon.social @rf@mastodonsocial.ru
@skobkin
Я тоже. Всё дело в том, что данные телевизоры - это ведь ваш выбор и вы сами выбрали более ограниченные платформы, чем те же AndroidTV или AOSP. И теперь пытаетесь спихнуть ответственность за этот выбор на разработчиков открытой платформы или приложений, которым не интересны и фактически невыгодны не особо популярные платформы, а иногда вообще недоступны. Если вы обманулись в ожиданиях, в результате действий маркетологов этих компаний, то все претензии к этим компаниям, а не к открытой платформе или разработчикам приложений.
@drq @groosha
@Revertron
Раньше все это было, но вся эта культура куда-то исчезла. Создаётся аккаунт на крупном сервере с большим аптаймом, когда-то использовали твиттер, потом блог-платформы, в нем постятся все предупреждения и другие сообщения во время восстановления сервера. На время восстановления, создаётся http-заглушка со ссылкой или редирект на информационный аккаунт. Если проблема длительная, то через манипуляции с dns. Если проблема небольшая, без потери работоспособности самой ОС, то можно поднять второй простенький web-сервер и завернуть трафик через iptables. Но в последнем варианте есть недостаток, это не снимет нагрузку с физического сервера, т.к. все это развёрнуто на одном железе или в одном доме при виртуализации.
Когда у человека перестанет коннектится клиент, он пойдет проверять через браузер и попадёт на заглушку, которая либо даст ссылку, либо перенаправит на открытый аккаунт, откуда он без всякой регистрации сможет узнать о том, что происходит.
@drsebro @yura @inexcode @rf@mastodonsocial.ru
@drq
Он даже с NewPipe перестал открываться. До этого зашёл с браузера, был не валидный сертификат, а сейчас хром на сертификат вроде не ругается, но в NewPipe результат тот же.
@groosha @blue @fediversehistory
@sptnkmmnt
Fedilab хранит закладки локально, на устройстве, но есть функции "загрузить на сервер" и "загрузить с сервера". Если что-то в fedilab добавить в закладки, но не загрузить на сервер, то оно в закладках учётной записи не появится.
При плохом соединении, в клиентах, просто долгое ожидание загрузки, но нет тормозящего интерфейса. А в веб, приходится долго ждать, пока загрузится меню, чтобы попасть в закладки и т.д..
@rf@mastodonsocial.ru
@a1batross
А есть мобильное приложение? Для нелюбителей компов.
@chillqrtirmster @hornyjesus@miniwa.moe
@yura
Он давно глючит. Уже скоро как год, а исторические картинки в закладках как не грузились, так и не грузятся. Встроенный браузер все также ломится мимо прокси.
@sptnkmmnt
Спасибо за идею. Но не всегда инет хороший и web-интерфейс из-за этого подтормаживает. И хранить закладки на стороне сервера как-то совсем не хочется.
@rf@mastodonsocial.ru
@tolstoevsky
Не обязательно tor или shadowsocks. Сеть может иметь такую конфигурацию, что пропускать некоторый трафик через основные маршруты невозможно или нежелательно. Для этого поднимается socks, чтобы можно было прокинуть не только http, но и некоторые другие сервисы.
Есть ещё более извращенный вариант, пропуск трафика через i2p до выходного узла или узла сопряжения с tor или vpn.
Для домашних пользователей гонять tor на телефоне, излишне сажая аккумулятор или живя возле розетки, сомнительное удовольствие. В домашней сети проще tor поднять на маршрутизаторе, на том же openwrt.
В fedilab еще прикол есть. Если указать socks proxy, и при этом в настройках выбрать встроенный браузер, то встроенный браузер ломится напрямую, а не через прокси.
@rf@mastodonsocial.ru
@tolstoevsky
У Tusky нет настройки ходить через proxy SOCKS?
@rf@mastodonsocial.ru
Подскажите, есть ли нормальный клиент для #mastodon с закладками кроме #fedilab ? #fedilab оказался глючным говном. Всё попытки заставить его отображать картинки в исторических закладках не увенчались успехом. Единственный вариант: если в туте были ответы, то удалить закладку и тут же, чтобы не потерять нужный тут, зайти на ветку обсуждения через ответ, тогда картинка в топике загрузится. Есть ещё один вариант, удалить его из закладки и найти в ленте пользователя, который отправил этот тут, но в этом варианте, если тут совсем исторический, то можно утонуть в куче тутов и ничего не найти.
@rf@mastodonsocial.ru