разговоры про технологию nn/ii, idec


\/ . Andrew Lobanov to vit01 @ Re: Эталонная реализация idec 12/08/19 03:51

vit01> Попытался запустить на рабочем сервере своём ii-net.tk и обломался, потому что там проставлен HSTS, и браузер ни в какую не хочет пускать по обычному http, форсируя защищённое соединение.
vit01> Нужна поддержка сертификатов.
vit01> В той же Gitea всё это продумано до мелочей, хз, как с этим bottle себя ведёт.

Зачем это эталонной реализации? Кто-то будет её юзать в боевых условиях?

2JoCLH... . ОТВЕТИТЬ



\/ . Andrew Lobanov to vit01 @ Re: Эталонная реализация idec 12/08/19 03:51

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
vit01> Слабая валидация POST данных. Особенно на тех же файловых эхах

Непонятно что именно не так =)

vit01> Способ хранения индексов вместе с файлами в фэхах меня тоже немного удивил. Можно попробовать в качестве атаки ввести фэху index и загрузить там файл с названием другой фэхи, тем самым легко затерев всё содержимое последней.

Можешь привести пример?

vit01> Мои пожелания:
vit01> 1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"

На боевой реализации конфиги вообще в БД будут

vit01> Уже часто начал замечать, что при таком подходе гораздо проще делать бэкапы и отделять файлы репозитория от изменяемых файлов.
vit01> // все блэклисты и изменяемые конфиги полностью туда

В БД всё.

vit01> К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

Зачем ускорять развёртывание эталонной реализации. Это же по факту POC.

vit01> 2. Объединить cli-скрипты в единый интерфейс и запускать вроде
vit01> ====
vit01> idec.py run
vit01> idec.py points add Vasya
vit01> idec.py stats -f ... -t ...
vit01> idec.py stats --help
vit01> ====

Нет смысла. Это усложнит чтение исходного кода.

vit01> 3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один
vit01> https://docs.python.org/3/library/argparse.html

Про это я пока у Лутца не читал =)

vit01> 4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

Нет смысла в эталонной реализации. Как и вебморда не нужна.

hOKLaL... . ОТВЕТИТЬ



\/ . vit01 to vit01 @ Re: Эталонная реализация idec 02/08/19 17:17

Попытался запустить на рабочем сервере своём ii-net.tk и обломался, потому что там проставлен HSTS, и браузер ни в какую не хочет пускать по обычному http, форсируя защищённое соединение.

Нужна поддержка сертификатов.

В той же Gitea всё это продумано до мелочей, хз, как с этим bottle себя ведёт.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

SgQXJu... . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Эталонная реализация idec 02/08/19 16:51

AL> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

Слабая валидация POST данных. Особенно на тех же файловых эхах

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

Мои пожелания:

1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"
Уже часто начал замечать, что при таком подходе гораздо проще делать бэкапы и отделять файлы репозитория от изменяемых файлов.

// все блэклисты и изменяемые конфиги полностью туда

К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

2. Объединить cli-скрипты в единый интерфейс и запускать вроде

====
idec.py run
idec.py points add Vasya
idec.py stats -f ... -t ...
idec.py stats --help
====



3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один

https://docs.python.org/3/library/argparse.html

4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

xIxlAp... . ОТВЕТИТЬ



\/ . Andrew Lobanov to vit01 @ Re: Тест 29/07/19 07:55

vit01> Видно, видно

Спасибо. Переехал на новое железо и не был уверен, что фетчер адвокатно отрабатывает.

S9OgED... . ОТВЕТИТЬ







\/ . vit01 to Andrew Lobanov @ Re: Тест 29/07/19 07:17

Видно, видно

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

lTbicJ... . ОТВЕТИТЬ





\/ . vit01 to All @ Странное письмецо, надо посоветоваться 25/07/19 15:41

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

====
Hi there,

I’m working on cleaning the website adaptavist . com, and I need your help in removing some links from your site. Your site is probably perfectly legitimate, but I’m just trying to eliminate as many links as possible.

I’m asking this because it’s come to our attention that some of the links to our website have been acquired against Google’s Webmaster Guidelines, so it’s important for us to remove links that are harming traffic to our website. Furthermore, by linking to our site, it could be detrimental to your site’s overall traffic, so it will be important for you to remove the link.

Here are some examples:

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Link text: ... (убрано мной, чтобы снова их скрипт не сработал)
Page on our site: ...

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK
Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply

Page on your site: https://alicorn.tk/ii-old/?msgid=Q0BNaz1cAGk9A8nrcDfK&reply
Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=1

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=88

Page on your site: https://alicorn.tk/ii-old/?echo=habra.15&page=88

The link(s) need to be actually removed, rather than just disavowed. Even if they are “nofollow,” I’d still like them to be removed.

Please let me know if you have any questions. If you could email me once you have removed the link that would be great.

Thanks in advance! I hope to hear from you soon.

Kind Regards,

Adaptavist Webmaster
====



Мой ответ этим товарищам был вот такой:

====
These links which were mentioned by you, are actually from annotations of archived posts of the Habrahabr website
 
The traffic which comes to your website, is primarily caused by this habrahabr post: https://habr.com/ru/company/billing/blog/271805/ (for example)
 
We can try to get rid of those links, but it's just an archive of short abstracts from the "real" articles. So, I just wanted to make it clear why are you worried about them and if you contacted the author of the original habrahabr article
====



Что может посоветовать в этой ситуации многоуважаемый All?

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

5uBnA5... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 25/07/19 04:33

>> сделаете замечания
Difrex> filter() - это встроенная функция python.
Difrex> Т.е. делая так
Difrex> ====
Difrex> from api import filter
Difrex> ====
Difrex> Ты ее переопределяешь.

Спасибо. Переделаю.

cY87DB... . ОТВЕТИТЬ







\/ . Andrew Lobanov to All @ Re: Эталонная реализация idec 24/07/19 04:17

Много чего доделал и доработал в сабже. Также написал простенький idec-txt под шумок. И переписал скрипт отсылки файлов в фэхи.

Всё это лежит вот тут:

* https://gitlab.com/spline1986/idec - эталонная нода;
* https://gitlab.com/spline1986/idec-txt - скрипт для отпрафки файлов в фэхи;
* https://gitlab.com/spline1986/idec-utils - тут я собираюсь возродить свои скрипты для idec, но пока тут только скрипт для отправки файлов.

Если есть желание и время, буду признателен, если потестируете или сделаете замечания по README хотя бы =)

PS: Да. Докстринги я до сих пор не прописал. Это на очереди.

1YgHm9... . ОТВЕТИТЬ



\/ . vit01 to btimofeev @ Re: android idec и play market 22/07/19 02:55

vit01>> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

btimofeev> Дополнительно можно в F-droid выложить. Могу с этим помочь.

Думаю, что F-Droid - это всё-таки наша первоначальная цель. Потому что это более "элитный" стор.

Difrex> Думаю, что мы можем задонатить =)

Это можно, но главное - это пофиксить неудобства юзабилити и дизайна + создать эталонную ноду, чтобы простые юзвери могли с удовольствием пользоваться клиентом. Вот в том же HodDogEd регистрация уже встроена в клиент, например. Нам до такой крайности опускаться не надо, но упросить порог вхождения желательно.

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

Ещё у меня на 9 андроиде после перезагрузки системы клиент падает с вот таким эксепшеном:

====
06-20 10:27:41.475 I/it01.idecmobil( 7793): Late-enabling -Xcheck:jni
06-20 10:27:41.976 I/Perf ( 7793): Connecting to perf service.
06-20 10:27:42.579 I/ACRA ( 7793): ACRA is enabled for vit01.idecmobile, initializing...
06-20 10:27:42.878 I/it01.idecmobile( 7793): type=1400 audit(0.0:101): avc: denied { getattr } for path="/data/data/com.android.keychain" dev="dm-0" ino=111211 scontext=u:r:untrusted_app:s0:c140,c256,c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=dir permissive=1
06-20 10:27:42.888 W/it01.idecmobil( 7793): Accessing hidden method Landroid/security/IKeyChainService$Stub;-><init>()V (dark greylist, linking)
06-20 10:27:42.889 D/AndroidRuntime( 7793): Shutting down VM
--------- beginning of crash
06-20 10:27:42.893 E/AndroidRuntime( 7793): FATAL EXCEPTION: main
06-20 10:27:42.893 E/AndroidRuntime( 7793): Process: vit01.idecmobile, PID: 7793
06-20 10:27:42.893 E/AndroidRuntime( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.893 E/AndroidRuntime( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)
06-20 10:27:42.913 E/ACRA ( 7793): ACRA caught a NoSuchMethodError for vit01.idecmobile
06-20 10:27:42.913 E/ACRA ( 7793): java.lang.NoSuchMethodError: No direct method <init>()V in class Landroid/security/IKeyChainService$Stub; or its super classes (declaration of 'android.security.IKeyChainService$Stub' appears in /system/framework/framework.jar!classes2.dex)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService$1.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.keychain.KeyChainService.<init>(KeyChainService.java:95)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.Class.newInstance(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:103)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.handleCreateService(ActivityThread.java:3554)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.access$1300(ActivityThread.java:202)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1674)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Handler.dispatchMessage(Handler.java:106)
06-20 10:27:42.913 E/ACRA ( 7793): at android.os.Looper.loop(Looper.java:193)
06-20 10:27:42.913 E/ACRA ( 7793): at android.app.ActivityThread.main(ActivityThread.java:6744)
06-20 10:27:42.913 E/ACRA ( 7793): at java.lang.reflect.Method.invoke(Native Method)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
06-20 10:27:42.913 E/ACRA ( 7793): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:859)
====



+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

cyDzkU... . ОТВЕТИТЬ



\/ . G2I to All @ Re: Netmail 21/07/19 09:57



\/ . G2I to All @ Re: Netmail 21/07/19 07:47



\/ . G2I to All @ Re: Netmail 21/07/19 07:47



\/ . btimofeev to vit01 @ Re: android idec и play market 20/07/19 15:24

vit01> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

Дополнительно можно в F-droid выложить. Могу с этим помочь.

eFBofW... . ОТВЕТИТЬ



\/ . Difrex to vit01 @ Re: android idec и play market 20/07/19 12:57

> 4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег
Думаю, что мы можем задонатить =)

> 5. Нетмейл. Все про него постоянно спрашивают
Продолжу писать стандарт на следующей неделе.

DJ4s5A... . ОТВЕТИТЬ



\/ . vit01 to Peter @ Re: android idec и play market 20/07/19 11:09

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

Для этого есть несколько проблем

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

2. В клиенте есть некоторые баги, которые до сих пор фиг знает как чинить, и для новичков они будут доставлять дискомфорт. Ещё есть недоработки в UI. См. Projects на Гитхабе. Ещё для финальной версии нужна поддержка шифрования, которую мне до сих пор лень делать.

3. Нет нормального хэлпа внутри клиента и некоторого "вступительного экрана". Но с этим вы можете помочь

4. Аккаунт разработчика Google стоит 25 долларов. Напоминаю, что я студент-нищеброд (на этот раз даже без стипендии из-за оптики), и мне жалко денег

5. Нетмейл. Все про него постоянно спрашивают

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

zzm7Ng... . ОТВЕТИТЬ





\/ . Peter to vit01 @ android idec и play market 20/07/19 06:41

Тут интересуются, почему в плеймаркете нет твоего клиента. :) Действительно, почему? Может уже пора начать захватывать мир? Только регистрацию бы попроще сделать...

606PRK... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 18/07/19 08:39

>> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Difrex> Ок, по стилю :)
Difrex> Общие рекомендации:
Difrex> * Код должен быть по PEP8.

Уже переделал этот момент.

Difrex> * Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
Difrex> сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
Difrex> документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
Difrex> нет докстрингов, не принимаются.

Это у меня в TODO было давно =)

Difrex> * Никогда не импортировать * из модулей.

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

Difrex> * Не переопределять имена функций в переменные. Что я имею в виду:
Difrex> В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
Difrex> которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
Difrex> переменные с таким же именем. Это может привести к неочевидным последствиям.

Этот момент я ещё не проработал, но ошибка весьма очевидна, если подумать. Спасибо =)

Difrex> * Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Difrex> Работает четко и круто.

Пока я просто прогнал все файлы через pep8 и исправил все замечания. Ну и форматирование исправил с оператора форматирование на метод форматирования. Правда пока не тестировал чего я там наделал, зато исправил пару критичных багов попутно =)

Difrex> Как облегчить себе жизнь и ваще не париться по поводу стиля:
Difrex> Ставишь из своих репов autopep8, flake8, python-black, pip.
Difrex> Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp
Difrex> Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
Difrex> за тебя GNU Emacs :)

Как раз собирался гуглить как это сделать. GNU Emacs это сила =)

Спасибо за полезные советы и рекомендации. Давно пора было мне упорядочить свой стиль и перестать разводить бардак в коде.

PWEPSP... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Эталонная реализация idec 18/07/19 07:28

> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Ок, по стилю :)

Общие рекомендации:

* Код должен быть по PEP8.
* Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
нет докстрингов, не принимаются.
* Никогда не импортировать * из модулей.
* Не переопределять имена функций в переменные. Что я имею в виду:
В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
переменные с таким же именем. Это может привести к неочевидным последствиям.
Пример:

====
def h(x):
    return x * x


def some_method(func):
    val = get_val_from_rest_api()
    return func(val)


if __name__ == "__main__":
    h = "Template: {}"
    # Тут дальше идет какая-то логика
    # А под конец хотим вызвать какой-либо метод передав в него
    some_method(h
    # Получаем исключение, т.к. вместо функции мы передали строку
====



* Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Работает четко и круто.

Как облегчить себе жизнь и ваще не париться по поводу стиля:
Ставишь из своих репов autopep8, flake8, python-black, pip.
Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp

Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
за тебя GNU Emacs :)

+++ At work. idec.el/0.1

V9tRZj... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 16:49

Difrex> Сделал ПР.

Кстати, так как я учусь только, то лучше мне просто указывать на недочёты и ошибки, чтобы я сам разбирался и делал всё. Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)

qw8Ggp... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 15:50

Difrex> И еще. Генерация authstring в points.txt отстой.
Difrex> Т.к. зная имя пользователя, мы всегда можем получить его строку авторизации.
Difrex> Сделал ПР.

А вот это по существу уже совсем. Спасибо.

8ghoGz... . ОТВЕТИТЬ







\/ . Andrew Lobanov to Difrex @ Re: Эталонная реализация idec 17/07/19 12:29

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
Difrex> Сделал ПР.
Difrex> Замечания:
Difrex> * Не импортируй звездочки из модулей
Difrex> * Форматирование строк через % устарело
Difrex> * PEP8

Спасибо. Разберусь что к чему и смержусь/пофикшу.

Пора уже действительно писать как для людей, а не как для себя =)

SzneJO... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Эталонная реализация idec 17/07/19 11:10

AL> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
Сделал ПР.

Замечания:
* Не импортируй звездочки из модулей
* Форматирование строк через % устарело
* PEP8

+++ At work. idec.el/0.1

ZoH4Ao... . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Эталонная реализация idec 17/07/19 09:26

Давненько уже я начал работу над сабжем, но некоторые события жизни и длинный отпуск существенно замедлили события. Сегодня я, вроде как, закончил вчерне всё. Доступно это добро тут https://gitlab.com/spline1986/idec

Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

hbP5IR... . цепочка . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Таверна 16/07/19 23:50

Готово. Надо потом и документацию обновить

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

J4AEAm... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Таверна 16/07/19 07:24

> Так что перенастраивайте фетчеры на сабж на адрес idec.spline-online.tk я вернул старый домен себе
Done

AkSZrK... . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Таверна 15/07/19 03:45

Я опять проморгал движухху на freenom. Они теперь не пускают по github'овскому аккаунту. Так что перенастраивайте фетчеры на сабж на адрес http://idec.spline-online.tk/ я вернул старый домен себе.

SJjMMR... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to vit01 @ Re: Дмитрий Хара "П. Ш." 08/07/19 07:13

vit01> Прочитал книженцию полностью. Есть там годные и интересные мысли, однако под конец автор вообще всё запорол.
vit01> Особенно ту часть с доктором конспирологом-ВИЧ-диссидентом (приводящим совершенно идиотские аргументы), ну и потом многочисленные нападки на "извращуг" со стороны автора и форсирование "традиционных ценностей", от которых уже тошнить начинает.
vit01> Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.
vit01> А, и да, какие-то остаточные кусочки религиозного мировоззрения там всё-таки присутствуют в высказываниях персонажей.

На самом деле это что-то из разряда х/ф. "Yes man" же =)

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

5YBHsf... . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Фэхи 08/07/19 04:07

AL> В стандарте не указаны ограничения на имена файлов. Значит ли это, что узел должен принимать файлы с любым именем?

AL> Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

NjW1bL... . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Дмитрий Хара "П. Ш." 08/07/19 03:45

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

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

Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.

А, и да, какие-то остаточные кусочки религиозного мировоззрения там всё-таки присутствуют в высказываниях персонажей.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

NwAtOQ... . ОТВЕТИТЬ



\/ . vit01 to All @ IDEC Mobile 15/06/19 11:02

На днях обновил nginx, и клиент перестал пускать на станцию мира, хотя в браузерах всё хорошо работало.

Ошибка заключалась в обновлении протоколов SSL у nginx и в невозможности старого https-клиента netcipher (который в составе IDEC Mobile) с ним работать. Итого я прописал в клиенте свежую версию netcipher, и всё заработало

Просьба обновиться

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

p7m8xM... . цепочка . ОТВЕТИТЬ



\/ . Peter to Difrex @ Re: Сменить псевдоним 31/05/19 08:37

>> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало
> gk11.ru уже год, как лежит :(.

Это да... :(

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

EJzacw... . ОТВЕТИТЬ





\/ . Andrew Lobanov to Peter @ Re: Сменить псевдоним 29/05/19 07:27

>> Хеш может быть любым.
Peter> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
Peter> В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

Ну пока нет лички да =)

TqVXyz... . ОТВЕТИТЬ



\/ . Peter to Andrew Lobanov @ Re: Сменить псевдоним 28/05/19 20:07

> Хеш может быть любым.
Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

AnvzWZ... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Peter @ Re: Сменить псевдоним 28/05/19 17:13

>> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
>> Что-то больше мне не хочется называться Anotheroneuser-ом :)
Peter> Могу попробовать просто заменить имя в конфиге. но если честно - я точно не помню, считается ли хеш по имени в тч или нет. Так что ничего страшного в том, чтоб новый акк сделать -- не вижу.

Хеш может быть любым.

f00rbs... . ОТВЕТИТЬ







\/ . Peter to Anotheroneuser @ Re: Сменить псевдоним 27/05/19 12:15

> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
> Что-то больше мне не хочется называться Anotheroneuser-ом :)

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

3PnqOM... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Anotheroneuser @ Re: Сменить псевдоним 27/05/19 07:29

Anotheroneuser> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Anotheroneuser> Что-то больше мне не хочется называться Anotheroneuser-ом :)

Лучше попросить своего сисопа переименовать тебя. Потому что ты здесь это не только ник, но и адрес =)

sqanjN... . ОТВЕТИТЬ



\/ . Anotheroneuser to All @ Сменить псевдоним 26/05/19 19:46

У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Что-то больше мне не хочется называться Anotheroneuser-ом :)

ed8Gxh... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Фэхи 22/05/19 11:46

Смотрю в стандарт и думаю про сабж.

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

Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

vpSFmi... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to All @ Дмитрий Хара "П. Ш." 22/05/19 04:34

В books закинул отличную книгу. Сабж. Очень помогает мне разобраться в себе и переосмыслить свои поступки, их причины, на свою жизнь и мир вокруг меня.

Книга представляет собой историю одного бизнесмена, рассказанную от первого лица. Действия в книге не так много, но зато много рассуждений и идей, который вроде бы и лежат на поверхности, но я сам до них не додумался за 33 года жизни.

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

2vit01: в книге нет религиозной составляющей =)

PS: Пока я её не дочитал, но прочтённая четверть уже начала вправлять мне мозги.

3fWHRj... . цепочка . ОТВЕТИТЬ







\/ . Andrew Lobanov to Difrex @ Re: Netmail 03/04/19 06:39





\/ . Andrew Lobanov to Difrex @ Re: Netmail 21/03/19 04:28

Difrex> На счёт протокола получения лички клиентом возражений нет? Мержим?

У меня вообще возражений нет. Только соображения. Что ни примите, я или сделаю это у себя или забью.

hNKAqS... . ОТВЕТИТЬ



\/ . Andrew Lobanov to vit01 @ Re: Netmail 21/03/19 04:27

vit01> Предположим, у нас есть 3 станции по такой схеме:
vit01> ====
vit01> node1 ---- node2 ---- node3
vit01> ====
vit01> node1 не соединена напрямую с node3
vit01> Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:
vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов
vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

Для этого есть PGP, например. Если уж параноишь в сети друзей, то делай это правильно. Шифрование на уровне стандарта это бессмысленное переусложнение. IDEC должен всего лишь носить почту, а остальное - не его забота.

vit01> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.

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

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

rCT4IP... . ОТВЕТИТЬ



\/ . Difrex to vit01 @ Re: IDEC Mobile 20/03/19 14:49

Ура, у меня заработали уведомления о новой почте!

+++ картошки хватит на всех

gtuWkm... . ОТВЕТИТЬ



\/ . Difrex to vit01 @ Re: Netmail 20/03/19 14:47

vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM


vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

vit01> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.

Можно обменяться ключами нод. Ну, шифровать ими личку с армором, тогда всё остаётся в plain text, но усложняет стандарт.
С другой стороны gpg есть ваще везде.

+++ картошки хватит на всех

CMr4nG... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Netmail 20/03/19 14:48

На счёт протокола получения лички клиентом возражений нет? Мержим?

+++ картошки хватит на всех

BLxrVH... . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Netmail 20/03/19 12:45

AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Предположим, у нас есть 3 станции по такой схеме:

====
node1 ---- node2 ---- node3
====



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

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

fRVQwF... . ОТВЕТИТЬ



\/ . Andrew Lobanov to vit01 @ Re: Netmail 20/03/19 09:26

AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Но это всего лишь мои мысли.

rB0Mb6... . ОТВЕТИТЬ



\/ . vit01 to Andrew Lobanov @ Re: Netmail 20/03/19 08:33

AL> 1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
AL> 2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
AL> 3. Шифрование не является частью протокола.

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

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

Это и правда упрощает реализацию, хотя и теряется гибкость.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

FZxRdF... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Netmail 20/03/19 07:42

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

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

Jd1mZh... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 08:31

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


+++ At work. idec.el/0.1

tAeA40... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 07:20



\/ . Andrew Lobanov to G2I @ Re: Netmail 18/03/19 04:04

G2I> Ведь нам надо сделать так, чтобы
G2I> 1. Нетмейл-сообщения ходили между станциями

Это просто.

G2I> 2. Станция не могла прочитать нетмейл чужих станций

Почему? Если нужно шифрование, то оно должно быть на стороне клиента, а не на стороне ноды.

G2I> 2.1 Но при этом могла отдавать их даунлинкам

Это совсем просто.

G2I> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

Я не умею пользоваться гитхабом, так что напишу свои мысли тут.

1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
3. Шифрование не является частью протокола.

То есть выглядеть оно должно примерно так:

Поинт забирает почту: GET /x/m/<authstr>[/слайс].

Поинт отправляет почту: POST /x/m/ (параметры pauth и tmsg).

Нода забирает почту с аплинка: GET /x/n/<password>.

Этого уже достаточно для рабочей лички, в принципе.

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

За основу формата сообщений предлагаю взять существующий формат:

====
ii/ok[/reply/<msgid>]
<адрес получателя>
<время>
<имя отправителя>
<адрес отправителя>
<имя получателя>
<тема>

<тело сообщения>
====



И для отправки тоже:

====
<адрес получателя>
<имя получателя>
<тема>

[@repto:<msgid>]
<тело сообщения>
====



В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?

ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.

qfB7Ip... . ОТВЕТИТЬ



\/ . Difrex to All @ Апгрейд на dynamic 17/03/19 07:42



Сегодня буду обновлять основной хост динамика с Debian oldstable до stable.
Возможно все приляжет до завтра. Бэкапы льются на DO, так что все восстановимо будет, если что.
Так же буду переводить сеть между виртуалками с OpenVPN на Wireguard.

wgjqo8... . цепочка . ОТВЕТИТЬ





\/ . vit01 to Difrex @ Re: dynamic 16/03/19 16:20

vit01>> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.

Difrex> Сделаю страничку для роботов :)
Difrex> Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны, чтобы все интерактивно было.

Спасибо, что сделал. Хорошая штука.

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

Скриншот в фэхе pictures прилагается

Хочется найти ему какое-то более крутое применение, потому что инструмент мощный, но придумать пока не могу :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

ah16PT... . ОТВЕТИТЬ



\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 15:56

>>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе

Difrex> Ага, KDE Connect :)
Difrex> А эта штука может работать вне кед?

Конечно может. Я вот уже долгое время работаю в XFCE и этой штукой доволен.

А на нетбуке тоже KDE Connect работает, и там AwesomeWM

Всего лишь индикатор в трее висит и никому не мешает. Огромное количество полезных прибамбасов. Доволен и всем советую. Это действительно одна из тех уникальных и удобнейших вещей, за которую стоит похвалить кедерастов.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

oEiYh3... . ОТВЕТИТЬ



\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 15:41

>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе
Ага, KDE Connect :).

А эта штука может работать вне кед?

0siE9Z... . ОТВЕТИТЬ



\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 14:30

Difrex> Хм. Не вижу никакой новой кнопки.
Difrex> Смотри скрин в файлоэхе pictures

Всё правильно, эта кнопочка на то и волшебная, что отображается не у всех =)

Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

OEPuWa... . ОТВЕТИТЬ



\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 14:10

Хм. Не вижу никакой новой кнопки.
Смотри скрин в файлоэхе pictures

+++ картошки хватит на всех

CumKhN... . ОТВЕТИТЬ



\/ . G2I to All @ Re: Netmail 16/03/19 13:54





\/ . G2I to All @ Re: Netmail 16/03/19 13:43

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:11:45 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472017154

По факту это самая сложная штука для проработки

Ведь нам надо сделать так, чтобы

1. Нетмейл-сообщения ходили между станциями
2. Станция не могла прочитать нетмейл чужих станций
2.1 Но при этом могла отдавать их даунлинкам

Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

KhJliV... . ОТВЕТИТЬ



\/ . G2I to All @ Re: Netmail 16/03/19 13:43

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:58:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472036264

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется
шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

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

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


+++ G2I: https://github.com/idec-net/github2idec. GPLv3

jNKNrz... . ОТВЕТИТЬ



\/ . G2I to All @ Re: Netmail 16/03/19 13:43

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:56:50 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472035614

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

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

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

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

eYVoUm... . ОТВЕТИТЬ



\/ . G2I to All @ Re: Netmail 16/03/19 13:43



\/ . G2I to All @ Re: Netmail 16/03/19 13:43

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 08:43:24 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472330230

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

Именно. Но при этом надо не давать ноде читать нетмейл поинтов чужих нод. Чтобы пересылать можно было, а читать - нет. Поэтому какое-то подобие шифрования желательно

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

A4EKTu... . ОТВЕТИТЬ





\/ . vit01 to All @ IDEC Mobile 16/03/19 09:33

В текущем обновлении для сабжа появилась одна очень интересная фича

Если вы не смотрели коммиты в репозитории, то для вас это будет небольшим сюрпризом

Что делать:

1. Обновите клиент
2. Зайдите в новостную эху (желательно habra.rss )
3. Возьмите любое сообщение и прокрутите в конец
4. Нажмите на волшебную кнопочку

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

P17MiH... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Netmail 13/03/19 09:34

>> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Difrex> Это дело хорошее :)

Нужное как минимум =)

>> В данный момент реализовано всё, кромен фэх и нет вебморды
Difrex> А нужна ли веб-морда в эталонной реализации ноды?

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

>> Обсуждать готов, а вот писать пока не очень.
Difrex> Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

Обязательно, но пока занят всякой фигнёй =(

>> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Difrex> Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.

Да. Всё верно =)

Difrex> Так мы вообще никак не переусложним стандарт.

При случае отпишу туда конь цепцию, которая сложилась в голове на эту тему.

cto8ef... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Netmail 12/03/19 12:27

> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Это дело хорошее :)

> В данный момент реализовано всё, кромен фэх и нет вебморды
А нужна ли веб-морда в эталонной реализации ноды?

> Обсуждать готов, а вот писать пока не очень.
Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

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

KtkAKS... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Netmail 12/03/19 12:07

Difrex> Я думаю, что нужно начинать с этим что-то делать.

Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)

Закладываю три вещи в это дело:

1. Реализация на python, чтобы любой желающий мог ознакомиться и внести изменения.
2. По возможности максимальная модульность реализации.
3. Настолько лаконичный и простой код, насколько я смогу.

В данный момент реализовано всё, кромен фэх и нет вебморды, но оно уже существенно лучше iing в плане реализации. Кода меньше, он проще и быстрее.

Difrex> Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
Difrex> разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
Difrex> и клиента.
Difrex> Вот этот репозиторий: https://github.com/idec-net/netmail

Хорошее дело.

Difrex> Давайте обсуждать и дописывать.

Обсуждать готов, а вот писать пока не очень.

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

AlSz3b... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Anotheroneuser @ Re: Документация 12/03/19 12:07

AL>> Коммитнул в сабж
Anotheroneuser> Это значит, где-то опубликовал?

В внёс изменения в исходники документации по idec.

Anotheroneuser> А где?

На гитхабе.

Anotheroneuser> Я бы тоже хотел свой адрес оставить

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

C61LZi... . ОТВЕТИТЬ



\/ . Difrex to All @ Netmail 12/03/19 09:29

Я думаю, что нужно начинать с этим что-то делать.

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

Вот этот репозиторий: https://github.com/idec-net/netmail
Давайте обсуждать и дописывать.

+++ At work. idec.el/0.1

hOxZjL... . цепочка . ОТВЕТИТЬ



\/ . Anotheroneuser to Andrew Lobanov @ Re: Документация 12/03/19 08:50

AL> Коммитнул в сабж
Это значит, где-то опубликовал?
А где?
Я бы тоже хотел свой адрес оставить

SUDA1L... . ОТВЕТИТЬ





\/ . Andrew Lobanov to All @ Документация 12/03/19 04:21



\/ . Difrex to All @ go-idec 04/03/19 13:41



Раз у нас намечается(наконец-то :) развитие, то я покрыл тестами гошную либу на 90%.
Буду очень рад, если кто-то еще будет туда коммитить. Сейчас там не хватает поддержки фэх.

Пример получения последних сообщений:

====
package main

import (
	"fmt"
	"time"

	idec "github.com/idec-net/go-idec"
)

func main() {
	fc := idec.FetchConfig{
		Node:   "https://dynamic.lessmore.pw/idec/",
		Echoes: []string{"pipe.2032", "idec.talks"},
		Offset: -3,
		Limit:  3,
	}
	ids, err := fc.GetMessagesIDS()
	if err != nil {
		panic(err)
	}
	msgs, err := fc.GetRawMessages(ids)
	if err != nil {
		panic(err)
	}
	for _, m := range msgs {
		msg, err := idec.ParseMessage(m.Message)
		if err != nil {
			panic(err)
		}
		fmt.Printf("Author: %s, Subg: %s, Date: %s\n", msg.From, msg.Subg, time.Unix(int64(msg.Timestamp), 0))
	}
}
====



Запуск

====
go run test.go
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:56:06 +0300 +03
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:21:04 +0300 +03
Author: Peter, Subg: Re: idec, Date: 2019-03-04 11:09:22 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-03 08:25:10 +0300 +03
Author: Peter, Subg: Re: Метадата, Date: 2019-03-02 23:17:49 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-02 20:02:04 +0300 +03
====


Iu0Zni... . цепочка . ОТВЕТИТЬ



\/ . Andrew Lobanov to Peter @ Re: Метадата 03/03/19 05:25

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

Вообще, я примерно так и думаю.

Например:

====
image:<filename>:<base64>
audio:<filename>:<base64>
====



А желание не пропустить информацию, ИМХО, противоречит самой цели секты.

ggygRC... . ОТВЕТИТЬ



\/ . Peter to Andrew Lobanov @ Re: Метадата 02/03/19 20:17

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

le3Gza... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Peter @ Re: Метадата 02/03/19 17:02

Peter> Идея была все-таки вот в чем.
Peter> С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Peter> Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Peter> Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Peter> Ну как в современных мессенжерах. :)

Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов. В итоге мы имеем повсеместно имеем всё равно те же файлы, но только спрятанные глубоко и неудобно.

Peter> А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

Ну тут да. Можно подумать как и что пропускать. Можно метаданные передавать ещё к каждому блобу.

Jzf2nf... . ОТВЕТИТЬ



\/ . Peter to Andrew Lobanov @ Re: Метадата 01/03/19 15:27

Идея была все-таки вот в чем.
С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.

Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Ну как в современных мессенжерах. :)

А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

xqHLvt... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Метадата 01/03/19 15:14

>> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.
>Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.
Но что-то делать с этим точно надо :)

fsq1jH... . ОТВЕТИТЬ



\/ . Andrew Lobanov to Difrex @ Re: Метадата 01/03/19 08:57

>>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>>> Вот это не нравится. А если я не хочу все аттачи тянуть?
>> Тогда просто игнорируешь тег и всё.
Difrex> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

Тогда лишний запрос надыть. Или в теги писать метаданные аттачей, что можно, но чревато большими тегами.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

ogfKFL... . ОТВЕТИТЬ



\/ . Difrex to Andrew Lobanov @ Re: Метадата 01/03/19 07:41

>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>> Вот это не нравится. А если я не хочу все аттачи тянуть?
> Тогда просто игнорируешь тег и всё.
Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

o9M1Ot... . ОТВЕТИТЬ



Andrew Lobanov to Difrex @ Re: Метадата 28/02/19 11:47

>> Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Difrex> Вот это еще не особо нравится.
Difrex> Со стороны клиента мне это видится так:
Difrex> ====
Difrex> +--------------+
Difrex> | |
Difrex> | IDEC Client |
Difrex> +------>| |<------+
Difrex> | +--------------+ |
Difrex> | |
Difrex> xdata tag message
Difrex> | data
Difrex> | |
Difrex> | v
Difrex> +-+-------------+ +-----------------+
Difrex> | /u/m/gkC... | | /x/d/gkC... |
Difrex> | | | |
Difrex> +---------------+ +-----------------+
Difrex> ====
Difrex> Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
Difrex> один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.

Зачем третий запрос? Клиент видит тэг, запрашивает все аттачи по этому тегу. Ему приходят они. В верхней квоте ни слова про третий запрос нет. И на схеме у тебя его нет.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

RAvybD... . ОТВЕТИТЬ


1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 .28. 29 30 31 32