= Сообщение: 668 из 2620 ==================================== RU.FTN.DEVELOP = От : Alexey Vissarionov 2:5020/545 17 Jun 15 16:00:00 Кому : Sergey Poziturin 17 Jun 15 16:00:00 Тема : Про набор поинтов сисопами и продолжен ие сети FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/545+5581843d На : area://RU.FTN.DEVELOP?msgid=2:5020/2140.2+53362bd4 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/2141.3+0adccd1e ============================================================================== Доброго времени суток, Sergey! 17 Jun 2015 14:17:26, ты -> мне:
AV>> Вот, кстати, очень интересно: откуда лезут пробелы в сабже? SP> fidogate иногда шалит на моём поинте :( Я даже нашёл, где и SP> почему, но там код править надо, пока руки не дошли.
Какое-нибудь преобразование из base64 или qp?
AV>>>> Рекомендую в качестве основного критерия выбирать узлы AV>>>> из сетей, которые географически ближе к пользователю. SP>>> Да, уже думаю над этим. Каким образом привязаться к месту на SP>>> телефоне б-м понятно, а вот как лучше поступить с узлами? SP>>> Разве что ввести ещё один тэг <Location> с SP>>> координатами и ранжировать по расстоянию. AV>> Еще проще: вывести список узлов с алфавитной сортировкой по AV>> городам. SP> Сделал так: юзеру предлагается перед запросом выбрать ближайшие SP> страну и город: https://dl.dropboxusercontent.com/u/2729127/hd/loc.png
Про встречу в реале лучше убрать - большинство современных усеров это, наобормот, напугает; "you may like to find some region-specific echoareas" значительно лучше.
А зачем здесь имя сисопа? Усеру нужны именно страна и город.
SP>>> Я тоже думал на тему, что сделать ещё один тип SP>>> requestby="binkp", тогда бы прямо как в старые добрые SP>>> времена можно было бы на узел непарольный нетмейл с SP>>> запросом зафигачить с адреса .999 :) AV>> Зачем? Заливаем какой-нибудь b68d264d121bd137.pntreq, а binkd AV>> на него натравливает парсер для ответа, который уйдет в той же AV>> сессии. SP> Можно попробовать, и аналогично со списком эх. Сделайте формат, SP> если будет пользоваться популярностью - я поддержу.
Запрос (текстовый файл, порядок строк произвольный, ключевые слова регистронезависимые, [число] означает максимальную длину строки, все нераспознанные строки считаются комментариями):
name[32]: Ivan Sidorov email[40]: ivanpetrovichsidorov@example.tld pass[8]: 2xE2i6Za location[40]: Gadyukino, Muhosransk region, Russia about: учусь на 2 курсе Мухосранского Заборостроительногго института, люблю девок и пиво
Еще было бы неплохо пихать сюда же список уже существующих aka.
Ответ:
result: ok comment: Node 2:5020/545 welcomes new point! address: 2:5020/545.12345 suggest: GREMLIN.POINTS, ro:GREMLIN.LINK, SU.CHAINIK
Слово "suggest:" предваряет список эх, на которые я рекомендую подписаться свежеиспеченному пойнту, а префикс "ro:" означает, что доступ к эхе будет read-only - это надо будет показать усеру. Оно и "address:" опциональны и используются только при result == ok.
SP>>>>> При http-запросе всё, что нужно знать хотдогу - это 2 строки. SP>>>>> первой OK или ERROR, а во второй - поинтовый адрес, который SP>>>>> присвоен поинту в случае ответа OK.
См. вышеописанное - возможно, оно найдет применение и при запросе по http.
SP>>> Кстати, вот ещё, не сделать ли ещё тег с какой-то памяткой SP>>> юзеру? Типа motd. Они будут его видеть при выборе узла. AV>> Ты хочешь именно xml? Чем плохо "key = value"? SP> Уже сделал тэг. Hе вижу особой разницы.
А, ну да - его ведь только хотдог будет парсить...
SP>>> Там бы такие типы как ты могли бы сразу всех застращать про SP>>> безопасность :) AV>> Hе стращать надо, а генерировать пароль автоматически и AV>> предлагать оный. `head -c6 < /dev/urandom | openssl base64` AV>> вполне достаточно. SP> Хорошие пароли выдаёт, большинство хотдогу подойдут (где нет всяких SP> плюсов и слэшей). Что-то мне сцыкатно эти символы пропускать, так SP> что я рекомендую юзерам [0-9a-zA-Z].
