= Сообщение: 675 из 2542 ==================================== RU.FTN.DEVELOP = От : Sergey Poziturin 2:5020/2141.3 17 Jun 15 21:45:40 Кому : Alexey Vissarionov 17 Jun 15 21:45:40 Тема : Про набор поинтов сисопами и продолжен ие сети FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/2141.3+0adccd1e На : area://RU.FTN.DEVELOP?msgid=2:5020/545+5581843d = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello, Alexey Vissarionov. On 17.06.15 16:00 you wrote:
AV>>> Вот, кстати, очень интересно: откуда лезут пробелы в сабже? SP>> fidogate иногда шалит на моём поинте :( Я даже нашёл, где и SP>> почему, но там код править надо, пока руки не дошли. AV> Какое-нибудь преобразование из base64 или qp?
Бинго! Из multiline qp пробелов не убирает в индентации.
AV>>>>> Рекомендую в качестве основного критерия выбирать узлы из AV>>>>> сетей, которые географически ближе к пользователю. SP>>>> Да, уже думаю над этим. Каким образом привязаться к месту на SP>>>> телефоне б-м понятно, а вот как лучше поступить с узлами? Разве SP>>>> что ввести ещё один тэг <Location> с координатами и ранжировать SP>>>> по расстоянию. AV>>> Еще проще: вывести список узлов с алфавитной сортировкой по AV>>> городам. SP>> Сделал так: юзеру предлагается перед запросом выбрать ближайшие SP>> страну и город: SP>> https://dl.dropboxusercontent.com/u/2729127/hd/loc.png AV> Про встречу в реале лучше убрать - большинство современных усеров AV> это, наобормот, напугает; "you may like to find some AV> region-specific echoareas" значительно лучше.
Хорошая мысль.
SP>> Затем список сортируется с приоритетом по стране и городу, ну а SP>> далее как было уже сказано. SP>> https://dl.dropboxusercontent.com/u/2729127/hd/sort.png AV> А зачем здесь имя сисопа? Усеру нужны именно страна и город.
Для справки есть и то, и другое. Имя сисопа для изначального месседжа, что сеть как бы не анонимная и очень даже персонифицированная. И никаких c00l hatzkh04.
SP>>>> Я тоже думал на тему, что сделать ещё один тип SP>>>> requestby="binkp", тогда бы прямо как в старые добрые времена SP>>>> можно было бы на узел непарольный нетмейл с запросом зафигачить SP>>>> с адреса .999 :) AV>>> Зачем? Заливаем какой-нибудь b68d264d121bd137.pntreq, а binkd на AV>>> него натравливает парсер для ответа, который уйдет в той же AV>>> сессии. SP>> Можно попробовать, и аналогично со списком эх. Сделайте формат, SP>> если будет пользоваться популярностью - я поддержу. AV> Запрос (текстовый файл, порядок строк произвольный, ключевые слова AV> регистронезависимые, [число] означает максимальную длину строки, AV> все нераспознанные строки считаются комментариями):
Записал в долгосрочный список TBD.
AV> result: ok comment: Node 2:5020/545 welcomes new point! address: AV> 2:5020/545.12345 suggest: GREMLIN.POINTS, ro:GREMLIN.LINK, AV> SU.CHAINIK Слово "suggest:" предваряет список эх, на которые я AV> рекомендую подписаться свежеиспеченному пойнту, а префикс "ro:" AV> означает, что доступ к эхе будет read-only - это надо будет AV> показать усеру. Оно и "address:" опциональны и используются только AV> при result == ok.
Сейчас мой скрипт на сервере примерно такой же набор данных, включая список эх, шлет поинту по почте при положительном ответе. Так больше шанс, что оно у него где-то сохранится. Но и дублировать в программе его вполне можно.
SP>>>>>> При http-запросе всё, что нужно знать хотдогу - это 2 строки. SP>>>>>> первой OK или ERROR, а во второй - поинтовый адрес, который SP>>>>>> присвоен поинту в случае ответа OK. AV> См. вышеописанное - возможно, оно найдет применение и при запросе AV> по http.
Не исключено.
SP>>>> Кстати, вот ещё, не сделать ли ещё тег с какой-то памяткой SP>>>> юзеру? Типа motd. Они будут его видеть при выборе узла. AV>>> Ты хочешь именно xml? Чем плохо "key = value"? SP>> Уже сделал тэг. Hе вижу особой разницы. AV> А, ну да - его ведь только хотдог будет парсить...
Обработка тега <note> уже сделана, на примере /2141 можно посмотреть в файле. Utf-8 понимает полностью, на длину ограничений нет.
SP>>>> Там бы такие типы как ты могли бы сразу всех застращать про SP>>>> безопасность :) AV>>> Hе стращать надо, а генерировать пароль автоматически и AV>>> предлагать оный. `head -c6 < /dev/urandom | openssl base64` AV>>> вполне достаточно. SP>> Хорошие пароли выдаёт, большинство хотдогу подойдут (где нет SP>> всяких плюсов и слэшей). Что-то мне сцыкатно эти символы SP>> пропускать, так что я рекомендую юзерам [0-9a-zA-Z]. AV> Надежнее всего `head -c6 < /dev/urandom | openssl base64 | tr /+ AV> _.` Можно `head -c6 < /dev/urandom | openssl base64 | tr /+ 12` - AV> оно не сильно испоганит энтропию (всего полтора бита из 48). Или AV> `head -c9 < /dev/urandom | openssl base64 | tr -d /+ | head -c8`, AV> но это неэффективно.
В принципе я давно думаю над тем, что юзеру и вовсе нужно предлагать придумывать пароль только в крайнем случае.
Я кстати сильно затрахался делать схему хранения паролей в хотдоге. Мало того, что они шифруются, так еще и не хранятся в бд, а сидят в пропертях конкретного провайдера. Ну и их так же корректно нужно бэкапить и ресторить. Учитывая архитектуру андроида, где каждое окно - де-факто самостоятельное приложение с ограниченной связью с родителем, это было больно.
-- Best regards! Posted using Hotdoged on Android --- Hotdoged/2.10/Android * Origin: Android device, Milky Way (2:5020/2141.3)
