vit01>> Если я скопирую конфиг вручную и попробую её запустить снова, то она даже не выдаст предупреждения, что points.txt пуст (и что его следовало бы наполнить чем-то).

AL> Мне казалось, что это логично. Открываем вебморду и регистрируемся =)

Не все пользуются вебмордами. Можно хотя бы спросить юзера, вроде того, хочет он создавать первого поинта или нет.

vit01>> 2. Запускаем скрипт
vit01>> 3. Пытаемся получить поинта и написать "test"
vit01>> Пункты 2 и 3 проще совместить, чтобы всё было "не отходя от кассы".

AL> Куда тут отходить то? Даже директорию менять не надо =) Я искренне не понимаю зачем это.

Про points.txt и points.py в твоём README нет ни слова (значит логично было бы пустить их в дело сразу же), плюс нододержатель так или иначе пойдёт сам этой нодой пользоваться (как минимум ради теста). Мелочь, а приятно.

AL> Какого рода подсказки? Есть README, а конфиг, как только дойдут руки, будет копироваться автоматом из умолчального.

Например, после копирования конфига предложить сисопу его сначала поправить в редакторе, а затем только ноду запустить. В *nix системах можно даже $EDITOR брать на вооружение, чтобы ускорить процесс.

-----------

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

Прошу высказаться насчёт идеи idec-python отсюда: ii://dvUD1leZtApAyB5AlwUC, и ещё хотелось бы услышать пожелания по поводу того, как строить GUI для фэх

AL> Что ещё туда можно запихнуть?

Как минимум, обработка тегов, работа с msgline, пара двустрочников для base64, упрощение работы с бандлами.
Также парсинг значений /x/c, строк /x/file, list.txt, тех же фэх

Вот посмотри сюда: https://github.com/vit1-irk/idec-mobile/blob/master/app/src/main/java/vit01/idecmobile/Core/IIMessage.java
Здесь, конечно, не всё необходимое (отсутствует перевод в бандл-строку, например), но в своей основе вынос работы с сообщениями с глаз долой был бы очень удобен в нашем малокачественном python-коде.

AL> Всё, что сверх протокола завязывается уже на конкретный способ хранения и отображения и уже не совсем понятно как добиться универсальности.

Из того, что сверх протокола, неплохо бы прикрутить функции для работы с сетью (думаю поделиться проксификацией через lib-socks-proxy и поддержкой таймаутов).

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

AL> Ты пробовал запустить iing, закинуть что-нить в фэху и получить это с помощью цезия? Как один из вариантов реализации.

Попробовал зафетчить фэху pictures с помощью Цезия. GUI здесь по факту отсутствует, хотя реализация и рабочая. Хотелось бы для CutieFeed'а что-нибудь и для IDEC Mobile, чтобы самому выбирать, какие файлы скачивать, и чтобы более-менее прилично выглядело.

AL> Если же говорить о idec-mobile, то не проще ли сразу кидать полученные нодой файлы на фреки, как это сделано в той же iing?

Проще, но ведь всё равно не очень полноценно с точки зрения юзабилити. Пока что попробую реализовать только Upload-диалог, а там посмотрим.

AL> Вот как лучше сделать приватные фреки в вебморде? Потому как authstr теперь передаётся только через POST-запрос. Есть мысли?

В вебморде можно всё в куки складывать и по ним проверять. Только проверку на csrf сделать ещё.

IDEC Mobile переведён на английский язык!

Уделено внимание даже таким мелочам как дефолтный конфиг (т.е. русским пользователям подставляется Станция мира и Таверна, а всем остальным Mira Station и Tavern).

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

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

AL> Просто если ты на десктопе подписан на фэху, то зачем какой-либо GUI? Сфетчилось и сфетчилось.

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

К тому же, попробуй мыслить дальше. Если пользователь сидит за графическим десктопом (будь то Иксы или Винда), то ему наверняка захочется открывать файлы кликом мыши. Картинку открыть в просмотрщике картинок, текст - в текстовом редакторе, архив - в архиваторе и так далее.

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

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

AL> Но актуально это будет разве что для новых проектов, так как в текущих, по сути, уже всё есть.
AL> Ну это как минимум к выкидыванию кучи уже рабочего кода.

Именно к этому и призываю - выкинуть кучу дублирующегося (пусть и рабочего) кода, чтобы упростить то, что у нас уже есть, и унифицировать поддержку всех фич. Если берём в расчёт существующие CutieFeed, Caesium, iing, то они всё равно различаются, и те вещи, которые в одном месте упустили, в других присутствуют.

В идеале в моих фантазиях клиенты и нода будут различаться только своими GUI. То есть будет нечто вроде idec-base, к которому по желанию прикручиваются bottle-модуль, ncurses-модуль, qt-модуль и так далее.

Что на сегодня:

1. Учтены замечания Петра
2. Попытался починить очередной баг с падением

Всем обновиться!

Peter> Из замечаний: все таки стоит добавлять / к урлу станции, если его не ввели, имхо.

Он и так добавляется. Просто предупреждение выдаётся, дабы человек запомнил. Но могу его убрать.

Peter> С шифрованием, конечно, частично все упрощается. Но по моему, все таки, делать его частью стандарта не очень...

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

А так-то фильтрация по получателю будет работать в любом случае. Только на клиенте, а не на ноде. Нода пойдёт осуществлять только самое базовое обслуживание (вроде удаления через N дней).

Peter> поинт -> нода поинта -> целевая нода
Peter> То есть, нет никакой сложной маршрутизации, сообщение от ноды поинта сразу коннектится к целевой ноде и отправляет сообщение на нее. Я считаю это нормальным, так как нода по определению доступна в сети интернет, и нет смысла делать какую то хитрую маршрутизацию

Это противоречит самым основам IDEC (да и ii), а именно:

1. Интернет не должен быть единственным транспортом
2. Никто, абсолютно никто не обязан быть доступным 24/7 (это самое важное правило, на котором построена наша сеть)
3. Один и тот же человек сегодня может подключаться к одной станции, а завтра - к другой

Peter> есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

Peter> 1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемы

> a) фетчить netmail могут только те ноды, которым мы доверяем;
> b) сообщение в netmail должны убиваться после доставки;

Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Опишу целиком.

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

1. Есть публичная эха netmail, которую может фетчить каждый. Все сообщения в netmail зашифрованы.
2. Все ноды открыто забирают друг у друга netmail и смотрят на поле получателя. Если получатель числится на ноде, то сообщение сохраняется там навечно (ну или на очень долгое время вроде 3 месяцев). Иначе (если нода ведёт транзит, т.е. такого поинта на ней нет) - держится около 5-10 дней, на усмотрение сисопа.
3. Шифрование всё end-to-end, сервера в нём не участвуют. Смог расшифровать - сообщение твоё. Не расшифровал - значит не твоё.

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

Difrex> Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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

Difrex> На самом деле никому ключ передавать не нужно. Можно воспользоваться тем же pgp.mit.edu. Либо, чтобы сисоп поднял sks и грузить ключик туда. Это не сложно =)

Почесал репу и подумал, что всё-таки это хорошая идея.

Peter> В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.

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

Peter> Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

Мы совершенно про разные вещи говорим. При схеме

                      abcde
                        |
нода1(from) > нода2 > нода3 > syscall (to)

нода 2 может организовывать атаку MITM, подменяя части сообщений. Например, подменив адрес получателя, она может добиться того, что нода3 отправит сообщение не получателю syscall, а левой ноде abcde. А если она подменит адрес отправителя, то может сама отлавливать чужую почту. Поэтому схемы без шифрования обречены на провал.

Возвращаясь к полю адреса, мы уже высказывали когда-то идею, что в поле адреса можно вписывать открытый ключ или ID этого ключа (неважно, для станции или для самого человека). При этом ЭЦП должна применяться не только для текста сообщения, но и для этого самого поля адреса, чтобы остальные ноды во время синхронизации не смогли подделать "обратный адрес" следования.

И теперь насчёт того, делать шифрование + ЭЦП на ноде или на клиенте.

1. На клиенте
+ не надо доверять сисопам
+ не надо сильно переделывать код станций
+ юзверь может получить свою почту с любой станции, с какой захочет
- надо совершенствовать клиенты
- нужен актуальный keystore для базы данных поинтов

2. На станции
+ не надо переделывать клиенты
+ реализация проще и легковеснее
- юзверь может получить почту только со своей станции
- поинт должен доверять своему "боссу"
- все ноды/юзвери должны знать, на какой станции живёт получатель, чтобы сообщение расшифровалось там, где это надо

Peter> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.

Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

Peter> Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Ну так ЭЦП ведь действует независимо от шифрования. Так что читать чужие письма всё равно сисопы смогут.
Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

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

vit01>> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.
AL> В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю?

vit01>> Также любые метаданные сообщений можно подменять на пути следования.
AL> Ну и долой такого сисопа при первом палеве из сети.

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

AL> Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

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

Когда мы пытаемся договориться по поводу чего-то, надо учитывать и плюсы, и минусы. Так что надо приводить примеры и с MITM, потому что кому-то это может не понравиться.

Просматривая документацию фэх, обнаружил, что при использовании f/p совершенно нет никаких кодов ответов
Так что ради соответствия сделал file ok:<hash> по аналогии с msg ok:<hash> в обычном /u/point. Ну и, конечно же, error: no auth
Очень странно, что это было пропущено при проектировании, в iing и в стандарте.

На станции мира в экспериментальном режиме теперь работают фэхи. Правда, я f/list.txt забыл сделать, но это не критично. Зато f/blacklist.txt не забыл =)

jmaks> Не работает почему-то authstr, который ты мне выдавал с mira station.

Напиши мне на me@ii-net.tk , разберёмся

jmaks> И кнопки просмотреть pass нету.

Сделаю кнопку

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

1. Заходишь на https://ii-net.tk, там есть кнопка
2. Или в самом клиенте в Navigation Drawer'e в списке есть кнопка "Обновиться", она приведёт сразу на APK

jmaks> Реквестирую СОХРАНЕНИЕ черновика сообщения

Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

jmaks> прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts

Очень странное поведение. Однако я понял примерно, куда копать, спасибо за багрепорт.

vit01>> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

btimofeev> Похоже нужно ещё и в onPause сохранять.

Да уже сообразил, чётко видно в исходниках. Но потом, сегодня занят.

На mira station есть ещё фэха pr0n.share

Да, это именно то, что вы подумали, название говорит само за себя :)

Более чем уверен, что её наполнять никто не будет, но пусть останется на всякий случай.

Peter> Еще у меня возникла мысль, что чтобы не переделывать клиентский софт, можно слать и получать приватные сообщения в обычную эху но такую:

Peter> netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

Это гениально! =) Отличная идея. Только тут надо помнить, что название эхи - это lowercase, но тут невелика проблема, можно преобразовать.

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

Насчёт "эх внутри нетмейла". Идея неплохая, но это можно реализовать проще: через теги, т.е. тем же способом, каким у нас сейчас ставится repto.

Итак, IDEC Mobile получает начальную поддержку файловых эх

Обновляться всем обязательно!

1. Заходите в настройки станции, ставите галку "Поддержка файловых эх"
2. Фетчите сообщения как обычно
3. В NavDrawer'е идёте на вкладку "Файловые эхи"

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

Багов ещё много, но это уже хотя бы что-то. Занимался сегодня клиентом целый день, даже еде внимания меньше уделял. Так что прошу feedback!

AL> Проанализировал логи и заметил, что фэхи с меня узлы не тянут (или тянут с отличным от эх периодом).

Станция мира фетчит фэхи на таверне раз в 20 минут.
Но я решил сделать проверку и увидел, что фетчер отказывается скачивать оттуда 3 файла.

У меня на станции стоят строгие регулярки, по которым имя файла разрешается только в lowercase (как имя эхи). Вроде бы, мы именно так по стандарту и договаривались, не?

// IDEC Mobile автоматически преобразует имя файла через toLower(), поэтому через него грузить безопасно.

Обновление IDEC Mobile!

Интерфейс фэх стал более отзывчивым, исправлены вчерашние баги, о которых было сообщено.
Также есть новые фичи:

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

2. Из режима чтения по просьбе Андрея теперь можно делиться сообщениями из Секты в plain-text, например, по Email/SMS/чтоугодно.

btimofeev> А чем плохи заглавные буквы в именах файлов?

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

Обновления по фэхам на сегодня

1. Исправлен баг с прокруткой списка в конец
2. Опция "Поделиться" для файлов (длинное нажатие)
3. Копирование fid в буфер обмена
4. Если файл криво скачался (т.е. повреждён), то алгоритм предложит его либо удалить, либо открывать на свой страх и риск
5. К скачанному содержимому фэх теперь можно дотянуться из сторонних приложений в диалоге выбора файла. (работает на Android 4.4 и выше)
6. Всё допереведено на русский (мелочь, но всё равно)

Сегодня у меня был тяжёлый день, проведённый в документации Google и на StackOverflow, поэтому крутые фичи под пунктами 2 и 5 требуют того, чтобы вы их оценили.

В общем, в стандарт гоним вот это

[A-Za-z0-9_!-.]{1,60}.[A-Za-z0-9_!-]{1,60}

А ещё прокидываю фэху ii://file.wishes, куда будем писать всякие пожелания по поводу того, чем поделиться, а также всякие перезаливы, отзывы по файлам и так далее.

Мне нравится эта идея. Не, серьёзно.

Peter> 1) не читабельные имена эх. генерируемых автоматически. Но, может, терпимо?

Терпимо. Только я за то, чтобы название скрытоэхи генерировалось на клиенте (даже если это хэш(authstr + дата)). А сервер будет только по алгоритму делать проверку.
То есть если название эхи называется с "__private.", то лишь тогда относить её к нетмейлу.

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

Наша задумка с единственной эхой не имеет такой фичи.

Можно разделять нетмейл на эхи-беседы так, как предлагал Денис (подставлять в поле echo свой текст), а затем просто делать по ним доп. запросы, чтобы получать сообщения всех участников.

GET /netmail
pauth=blablabla
nechoes=first.necho:second.private.123

И теперь нетмейл будет формироваться с учётом скрытобесед независимо от того, какие получатели проставлены на "помеченных" сообщениях.

vit01>> Вариант Петра хорош тем, что "скрытоэхи" для совместных бесед автоматически прокидываются на фетч между станциями.
vit01>> Наша задумка с единственной эхой не имеет такой фичи.

AL> Потому что мухи отдельно, котлеты отдельно. Я искренне недоумеваю зачем валить в одну кучу и личную переписку и скрытоэхи, если это логически разные вещи.

AL> Но зачем?

Соблазн по фичам. С одной стороны, обыкновенный нетмейл по единственной эхе будет как-то работать. Но будет мало гибкости

1. Обычный нетмейл - это разговор 1 на 1.
2. Скрытоэхи работают только на "своей" станции, ибо не гейтуются автоматически

-----
to All

Ещё возникли сомнения по поводу роутинга и адресации нетмыла, но это в целом к нашим разговорам по сабжу относится.

1. Предположим, я пишу пользователю Andrew Lobanov, проставив его имя в поле получателя. Сообщение расходится по всей сети через общую эху net.mail. На станции syscall (там есть публичная регистрация) некто заводит аккаунт с именем Andrew Lobanov (предположим, что этого поинта на syscall раньше не было) и ловит всю его почту. Пролёт.

2. Придумываем, что некто написал письмо мне, vit01, но в поле получателя написал (mira,1). Сообщение расходится по всей сети. Здесь, внезапно, станция мира падает под DDoS или потому что я не оплатил хостинг. Само собой разумеется, я перенастраиваю клиент на другую ноду, пусть это будет Таверна, где мой адрес уже (tavern,N). И...

и получаю, что в нетмыле пусто.

Предлагайте свои варианты.

Захожу сегодня в клиент, загружаю новую почту. Обнаружил, что резервная станция irk39.tk (mtest) не функционирует.
Ладно, думаю, проблема с хостингом, то есть с RedHat OpenShift. Как оказалось, у хостера всё работает, сервер на месте.

Зашёл к доменному регистратору (ранее dot.tk, теперь freenom) и офигел.

Единственным доменом, который за мной значится, оказался alicorn.tk.
Остальные (а их там было штук 5 минимум) куда-то исчезли, в том числе сам ii-net.tk без всяких на то предупреждений. А ведь раньше предупреждали.

ii-net.tk никто захватить ещё не успел, поэтому я его взял заново, но уже за 10$, а не бесплатно.
В ближайший день может отказать почта и дебаг-сервер (да и сам сайт), если мою заявку не зачтут.

Все остальные домены, в том числе irk39.tk, возвращать не буду, жалко тратиться =)
Насчёт резервной станции ещё подумаю.

// Нашим советую перенаправить фетч на alicorn.tk денька на 2, там стоит зеркало mira station, просто домен в фетчере поправить и всё.

Круто!

А что за тема оформления у твоего емакса?

jmaks> После крайнего обновления, сегодня, сабж виснет при старте и не работает.

Пересобрал сейчас, попробуй новую сборку.
Только она нестабильная, если что (некоторые штуки в интерфейсе есть, не обращайте внимание, это следы экспериментов)

Из новых фич там только сортировка файлов в фэхах по давней просьбе Андрея. Выбор сортировки запоминается в конфиге.

// to btimofeev: цитаты Difrex(mobile) пофиксил

Ты хоть дебаг-лог скинь, который в adb появляется.

Или тот, который по емейлу идёт, если он есть, конечно.

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

В связи с прекращением поддержки Redhat OpenShift v2 резервная станция mtest (бывший irk39.tk) должна скоро навернуться. В ближайшие пару дней уберу её из списка.

Подробности: https://www.linux.org.ru/news/redhat/13708785

На новую 3 версию пока не могу перейти, ибо там с похапе проблемы какие-то, и осваивать заново надо. Ещё там гвоздями прибитая к Git система деплоя, и просто так рандом-софт не развернёшь.

Ну ничё, разберёмся. Второй сервак задействую для резерва, может быть,

> Просто серый экран и все.

Ну хоть что-то должно появляться в adb-логе
Попробую на 4.4 проверить, но там вроде работало в последний раз.

> Подключусь попробую посмотреть, как вообще процесс называется?

vit01.idecmobile называется. Всё как и должно быть.

Да там нужен всего лишь какой-нибудь контейнер с python + php + mariadb. Больше и не надо.

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

> Вот такое нашел через logcat | grep -i idec

Это неполный лог, в котором не видно ошибок, потому что grep пропустил мимо стектрейс, который мне так нужен. Надо полный вывод logcat

Зато я хотя бы понял, почему серый экран. Где-то внутри приложения возникла ошибка, и оно пытается запустить окно с сообщением о крэше, чтобы скинуть мне это на почту. А запустить CrashReportActivity, видимо, тоже не может. Хрень какая-то

Если ты так и не отловишь полный трейс, то тут два выхода

1. Либо я пытаюсь как-нибудь поднять виртуалку с 4.2 (не факт, что это будет быстро и просто)
2. Или мы связываемся друг с другом в воскресенье и удалённо подключаем отладчик к твоему телефону через ssh-туннель

Спасибо

Теперь ясно, что проблема именно с ContentProvider'ом, и копать надо туда

Питоноэха снята с гейта и добавлена в архив. Снапшот архива на alicorn.tk обновлён. См. документация.

Фэха books прокинута

Решил провести сабж

python.15 - убрана со станции, в архиве есть
vk-news.15 - убрана с фетча и со станции, перемещена в архив
lenta.rss - удалена без возможности восстановления

Снапшот архива обновлён, его размер в сжатом виде вырос до 14 мб, количество эх - до 88, количество сообщений - 45 333.
// Качать как обычно, ссылки не изменились

Немного есть сомнения в нужности ifiction.15 (пустота), piratemedia.rss.15 (у Андрея походу поломался гейт). Думаю их тоже прибрать.

На mira station сейчас 25300-25350 сообщений с учётом скрытоэх.

vit01>> piratemedia.rss.15
AL> Я её прибил у себя. Последняя новость на сайте была от второго мая сего года. Так что не вижу в ней смысла.

На самом деле новости там были и позже. Но, судя по всему, на Гиктаймсе практически всю полит.истерию дублируют.

Обе эхи убраны в архив, снапшот обновлён, готово.

ооох, пришлось проснуться =)

> у сепаратистов основная идея - что все люди безошибочно правильные
Неправда, люди совершают ошибки и не могут быть супер идеальными (а жаль)

> от проблем следует запираться
Не от всех, а только от некоторых

> и что технологические решения важнее социальных
Опять же неправда, такого не говорилось

> мне там прямым текстом заявили "девочки не нужны, люди не нужны, зато у нас будут красивые клиенты" :)
Девочки не нужны - я это заявлял. Люди нужны. Красивые клиенты не являются основной целью, но если будут - мы только рады.

//пошёл спать дальше

> Я говорю, что этого вообще не видно. И, по-моему, не видно даже понимания этого, судя по гонору некоторых, они вообще уверены, что некоторые вещи появляются сами собой, поэтому мелкие проблемы раздувают до масштаба жизненно важных, а то, что реально имеет значение - этому вообще не придаётся статус проблемы.
Видно будет по результатам. А насчёт некоторых: какие они проблемы сами решают, о тех и говорят. Лично я вот с технических проблем пока на нетехнические перешёл - с контентом. Скоро доложусь.

> Меня тоже постоянно оскорбляли, что в новостях, а кто-то и на сайт приходил. Не вижу в этом ничего страшного, это неизбежная часть рабочего процесса, "жить в обществе и быть свободным от общества нельзя"
Ну ок, что ж. Надо иммунитет выработать. Хотя мириться с этим просто так нельзя.

> Я уже говорил - а вы ИНТЕРЕСНЕЕ, чем их текущие средства общения? Вот что самое главное.
Вот именно, что нет. Но "мы работаем над этим".

> ээээ... кроме статей, есть ещё и заметки. в которых я, например, писал, почему linux стал более-менее массовым только с приходом livecd.
Хм, первый раз слышу о твоих заметках. Даже почитать захотелось.

> почему linux стал более-менее массовым только с приходом livecd.
Уже и сам догадываюсь - потому что с ним стало легче познакомиться

> Кто такие "плохие люди".
Это относительное понятие. Но относительно к нам я могу объявить его так: люди, которые мешают и целенаправленно творят зло (спамеры, хакеры, ддосеры), "тролли", хамы, то есть люди, совершающие аморальные поступки (определение неточное и относительное, я знаю), неадекваты. Список, конечно, неполный.

> Вот я - плохой?
Смотря когда и в каких ситуациях. Как абсолютно - человек не может быть плохим или хорошим сам по себе.

> А если кто-то на одном сайте хороший, а на другом - плохой?
Это всё относительно. Если у нас он плохой, то для нас он плохой.

Приток людей планируется, но гарантий, к сожалению, никаких нет.

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

> И кто судьи?
Ноды и остальные поинты
> Да я откуда знаю? Это у вас там принцип "не допущать плохих", вот мне и интересно, как вы их определять будете.
Точно так же определять, как ты определяешь, кто тут враг, а кто нет =)

Не забуду. Я ж у себя докладываться собираюсь.
> А то ни плана развития, ни обсуждения проблем.
План был опубликован. Проблемы? Ну так давайте обсуждать, кто мешает?
> Только срач в ii.dev.
Ну и где я там в срачи вступал?

Странно, конечно, от своего же поинта такое слышать =)

> А по-моему, это как раз на идеальных людей и рассчитано. :)
> И, вообще, как я понимаю, что вы ждёте специальных идеальных людей, а не готовы работать с существующими и реальными. :) Хороший способ построения сообщества.
Идеальных людей я сам ни разу не видел. И сегодняшнее население ii сетей к идеальным людям тоже не относится (про себя говорю в том числе).

> Я вообще не видел, ни разу, ни одного обсуждения, как вы собираетесь делать свой Майданный Айай интереснее. Все текущие обсуждения - только технические.
Во-первых, не майданный. Во-вторых, над интересом мы работаем. Конечно, пока неэффективно, но обороты будут наращиваться. Коммиты - это вещи всё равно нужные, этим надо заниматься так или иначе.

> Надо всё таки быть реальнее. Ближе к народу. В изначальной ii были проблемы, но они и подразумевались, что они будут, и заранее как-то просчитывались, и потом решались в рабочем порядке.
И у нас решаются. Если говорить про реальность и близость к народу, то в техническом плане для этого уже почти всё сделано. Контент - надо добавлять, конечно, а то скучно станет.

> хотя, конечно, предательства со спины я не ожидал :)
Не предавал я тебя, тогда я просто обиделся. Я ж тебя только с фетча убрал (между прочим, предупредил, что репрессии будут, заранее), но поинта не убирал (в вк же пообещал, тем более, всё равно так бы делать не стал). Согласен, что снятие с фетча было глупым поступком, но из-за оскорблений и мата эмоции дали своё.

> Вот ты видел, чтобы я когда-нибудь запрещал кому-нибудь что-нибудь говорить? Пользовался служебным положением? Единственное, что я всегда использовал - это слово, объяснение, разъяснение и переговоры. А у вас перебанить несогласных - первое дело. :)
Да, действительно не видел. Если несогласен человек, то ничего плохого, но когда оскорбляют, и правда хочется забанить.

> Вы даже не понимаете, почему это плохо, особенно в вашем/нашем положении.
Очевидно же - людей не останется.

> Хотя, если я опять же понял ваши речи и ваши вздохи о неидеальности людей, вы выбираете путь самоизоляции. Что ж, может быть, это и лучше, и для вас, чтобы не сталкиваться с реальным миром, и для бедных реальных людей. :)
Бедные реальные люди не найдут для себя здесь ничего интересного. У них есть социальные сети, где есть картинки, видео и онлайн игры. Им интерактив нужен, поэтому сюда они вряд ли полезут.

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

> "кто не согласен или не понимает, тот нас недостоин"
Кто не согласен, тому это не нужно. Для тех, кто не понимает, уже готово куча статей, в том числе тобой написанных, если им не лень прочитать - поймут.

> Поэтому... может быть, я чего-то не знаю или не так услышал, но позиции "сделаем свой несовместимый майданный ай-ай, и отгородимся от людей" я понять не могу. Не вижу у вас какой-то внятной политики, отвечающей на вопрос смысла вашего существования.
Во-первых, совместимый, во-вторых, никакой не майданный. Отгораживание идёт не от всех людей, а только от плохих. В фидо же, как я понимаю, точно также было. Смысл существования - поддерживать хороший проект и сидеть тут, потому что тут хорошо, а идти больше некуда.

> А вы ещё раз разделитесь.
А по сути никто и не мешает никому разделяться. Хочешь разделяться - подними свою ноду да и живи там

> Если в первый раз помогло - то и во второй поможет. Каждый будет сидеть, и, как святой Франциск, мотыжить свой участок.
Может, и поможет

> Предложение пообсуждать все дружно проигнорировали.
Так давай обсуждать, я лично не против. Говори эху и проблемы, которые надо обсуждать. И остальные пусть тоже включаются.

> Я и не говорил, что ты в них участвовал, я о отм, что кроме срача там почти ничего не осталось.
Тогда пойду сообщать туда о том, что сделал, по твоему примеру. dev всё-таки нужно наполнять

> А ты думал, что в сказку попал? :)
ага :)