Сделать только доверенные списки без свободной
коммутации между серверами (доменами) и всё,
это ещё +1 протокол, а не замена.
Ну да. Наваяние любого нового протокола, предназначенного для замены старого, не отменит использование протокола старого потому, что старый протокол запретить невозможно и значит любой самый распрекрасный протокол будет не заменой, а действительно просто +1 протоколом.
один сервис работал бы по какому-нибудь условному X-Mail,
другой по своему HyperMail, третий Mail3 и т.д. При этом
между собой они бы вряд ли коммутировались (привет
всратые ватсапы, вайберы, телеграммы, шлаки и т.д.)
Слышал я много лет назад байку про то, что всякие там "всратые" провайдеры типа AOL и всякие другие (какие у них там в США тогда были) именно такие собственные какие-то там почтовые протоколы своим клиентам и предлагали, а потом как-то "победила" обычная электронная почта, которую сейчас мы все сейчас совместимо друг с другом и используем.
А в конце 90-х годов у нас на узле интернет ещё была поддержка почты UUCP. Во прикол был. :-) Но она тогда поддерживалась на узле в качестве просто поддержки пользователей, которые с почтой могут работать только в виде UUCP и нами считалась устаревшей и доживающей свой век.
Идея платности для охлаждения спамерского пыла у меня тоже была.
Вот есть сейчас на сайтах страницы с контактами.
Ну там на них указаны — телефоны, формы обратной связи, емайлы уже серьёзные люди на сайтах не указывают.
Если кому-то надо серьёзно связаться, он берёт и сразу звонит — ну если дело настолько важное, что нужна гарантия обмена сообщениями, а не просто "отправил форму обратной связи и гадай — прочитали её или не прочитали".
Так вот: звонок по телефону является делом обычно платным для вызывающей стороны. И ничего — это не проблема для тех, кому связаться и поговорить действительно нужно.
Аналогично можно делать платной и отправку формы обратной связи. Цену делать символической — хоть 10 рублей, хоть рубль. Серьёзным людям этих денег будет не жалко, а спамер миллион сообщений по рублю за каждое рассылать уже не будет.
Письма обычные бумажные народ платно отправляет и не возмущается.
Письмо электронное ничем не хуже бумажного. По крайней мере плату можно брать для отправки письма по адресу, владельцы которлшл ещё не отменили платность приёма писем для конкретного отправителя.
Например, хочет кто-то отправить предложение о сотрудничестве по адресу, по которому он ещё ничего не посылал. Платит 10 рублей и его письмо доставляется. Если получатель думает, что от этого отправителя все следующие письма можно принимать бесплатно, то разрешает ему отправлять следующие письма уже бесплатно. Как это сделать технически — это отдельная тема.
Если у человека есть смарт, то у практически наверняка
есть учетка либо от Гугла, либо от Apple. В которой есть почта.
Ей и нужно пользоваться в подобных случаях.
Бывает так, что хозяину мобилы аккаунт на ней заводит другой человек, а хозяину мобилы даже бесполезно про это что-то объяснять потому, что он всё-равно это не поймёт. Почта-то на такую мобилу придёт так, что её даже может получиться прочитать. Но вот когда надо переустановить мобилу, то пароль хозяин от аккаунта своей мобилы её хозяин сказать уже не сможет.
Чтобы не зависеть от владельцев систем обмена сообщениями.
Установили участники обмена сообщениями себе почтовые сервера и емайл-мессенджеры и обмениваются сообщениями свободно без учёта требований всех этих вацапов, инстаграмов и прочих систем, которые по праву "хозяин — барин" устанавливают правила своим пользователям.
Технически не вижу никаких проблем объединить
и почту и мессенджеры в рамках одного протокола
Такое объединение уже сделали в емайл-мессенджере Delta chat. Я его уже хотел, было, использовать, но оказалось, что он работает только с ящиками IMAP, а у меня ящики только POP3. В создании емайл-месседжеров для POP3 тоже нет никаких проблем, но пока для POP3 их никто не создал.
Проблема спама в электронной почте порождена тем, что кто попало может отправлять письма куда попало и никто это ему запретить не может. Это недостаток большой свободы.
Системы, которые имеют меньше свободы (фидо, вацапы, инстаграмы, соц.сети, телеграмы и всякие прочие современные мессенджеры да системы обмена сообщениями, в которых есть жёсткое регулирование правил), меньше подвержены спаму, т.к. в них есть возможность хотя бы блокировать спамеров, что, конечно, не избавляет такие системы от спама полностью, но немного уменьшает эту проблему.
При настройке дополнительного устройства приложение
должно передать историю ваших сообщений на это
устройство одноранговым способом, то есть по пирингу
Зачем обязывать выбирать способ передачи истории, если важен только резуультат? Ну понятно, что безоапсность важна, но эту часть настройки способа передачи можно уже разрешить делать хозяину аккаунта.
Если одно из устройств выброшено, потеряно или украдено,
у пользователя должна быть возможность запретить ему
дальнейший доступ к своим аккаунтам для обмена
сообщениями. Скомпрометированное устройство не должно
быть в состоянии захватить аккаунт.
Даже нескомпроментированное устройство не должно иметь возможности захватить аккаунт без доступа к некоторым внешним источникам такого захвата. Хочет, например, кто-то захватить аккаунт — пусть введёт код из СМС, отправленного на телефон хозяина аккаунта. А без такого дополнительного препятствия получается, что захватил кто-нибудь мобилу и может сразу же аккаунт захватить сам, если захваченную мобилу не успели объявить скоспроментированной, чтобы от аккаунта её отключить.
Каждой организации и коллективу, будь то большая корпорация
или маленький семейный круг, нужен сервис обмена сообщениями
только для своих, куда не поступает трафик извне.
Такая возможность же в электронной почте есть. Мы её у себя даже применяем:
Делается почтовый домен локальный, который интернету не известен. Например,
krutoy-zavod. Через собственные сервера DNS этот домен делается известным всем участникам почтового обмена.
Создаются этом домене адреса типа dirktor@krutoy-zavod, buhgalter@krutoy-zavod, ohrana@krutoy-zavod, planoviy-otdel@krutoy-zavod и так далее.
Ну и дальше труженики этого крутого завода шлют друг другу почту нормально. Спамеры из интернетов им почту не пришлют. Красота же!
MNM ставит перед собой две задачи:
2) добавить возможности, которых
не хватает нынешней почте:
форматирование сообщений и поддержка Markdown
Эта возможность в современной почте есть. Называется HTML. Ну а вообще любое (а не только HTML) содержимое, которое можно форматировать. Или этот способ объявлен костылём?
Воздушные штабы управления — это только чтобы продержаться всего несколько суток, а потом всё-равно нужна посадка на какой-нибудь адродром, хотя бы импровизированный. И проблема тут не только техническая (перебили всех дозапращиков, например, или закончилось машинное масло). Там же запасов продовольствия сильно много не возьмёшь. Да и всякие дела типа госпиталя в воздухе — это дела так себе.
Корабельные штабы в этом смысле немного лучше. Но зато корабли — это просто плавучие мишени для советского флота.
хотите увеличить велью — способствуйте,
запускайте ноду, к примеру
Разработчик сайта на своём сервере ноду-то запустит.
И после этого клиенты смогут вытаскивать файлы из каких нод? Только из ноды разработчика. А почем только из его ноды, а не с других? Потому, что другим нодам файлы его ноды не нужны и их там значит нет. А в таком случае и нода межпланетная не нужна, т.к. быстрее и проще файлы отдать прямо с веб-сервера через хттп.
Как сделать получение клиентами файлов не с одной ноды, а из множества нод? Для этого множество нод должно файлы с ноды разработчика себе накачать. А как заставить другие ноды выкачать файлы с ноды разработчика? Администраторы (управители) других нод наверно должны своим нодам дать соответствующие указания, чтобы их ноды начали выкачивать к себе файлы сперва из ноды разработчика, а затем эти же файлы и друг от друга, ну точнее — с любых нод, где они их только смогут нашукать.
Администраторы нод безпричинно не будут накачивать себе файлы из ноды разработчика какого-то сайта. Выкачивать файлы из ноды разработчика будут только заинтересованные в этом ноды. А заинтересованы в этом ноды только пользователей сайта. Но пользователи сами себе ноды устанавливать не будут. Для них сайт — это в лучшем случае то, что они увидели по ссылке в гугле, перешли на него, немного потусовались на нём да свалили с него. Какие им там ещё ноды? А в худшем случае сайтами современные пользователи называют вообще свои инстаграмские аккаунты. Так и говорят — у нас есть сайт в инстаграме.
Поэтому установка нод у пользователей — это дело непосредственно разработчика сайта.
Понятно, что на компьютеры пользователей разработчик сайта никакие программы не установит. Остаётся ему работать только в пространстве браузера. Была по этому поводу слабая надежда на то, что запустить ноду в загруженной браузером странице можно через джаваскрипт какой-нибудь хитро-командой, жизнь которой даёт либо подключенная тегом script src=… какая-нибудь ipfs-библиотека, либо существование таких готовых джава-скрипт-решений в браузере Brave, о котором недавно объявили, что он, дескать, начал уметь работать с IPFS. Но в этом направлении у разработчиков сайтов по прежнему остаётся какой-то туман вместо ясного представления и понимания о том, как из браузера можно загружать ресурсы не с веб-серверов, а из сети IPFS.
Пользоватерь может поставить узел у себя
и то что он смотрит через шлюз узла будет
кешироватся у него и раздаватся другим узлам.
Проблема в том, что пользователь сайта даже на сайт-то с трудом зайдёт потому, что нынче все пользователи разбежались по инстаграмчикам да телеграмчикам с вацапчиками впридачу. А уж заставить его установить к себе какую-то непонятную ему ноду — тем более проблематично. Так что вариант, в котором ноду себе поставит пользователь, мне видится почти невозможным.
Разработчик может встроить в сайт js-ipfs
узел и он запустится в браузере пользователя.
Вот это хороший вариант. Пользователя заставлять и даже просить не надо установить себе ноду. Вот таким способом я себе и представляю установку ноды в браузере пользователя разработчиком сайта.
Но как конкретно это делать?
Я думал, что надо подключить какую-то библиотеку типа
<SCRIPT SRC=библиотека-для-нод.js>
и затем джаваскриптом в браузере как_то_ноду.включить()
Ходил почитать про это куда-то в район js ipfs (точный адрес непомню), а там опять предлагают установить ноду на компьютер, а не подключить js-библиотеку к html-странице.
Я на перле раньше переменные тоже только объявлял, а значения им давал "когда-то потом". Но после того, как я начал применять FastCGI, неприсваивание значений переменным в месте их объявления стало приводить к неожиданным результатам — во время следующих запусков процедуры её внутренние переменные стали помнить свои прежние значения их прошлой жизни — из предыдущих запусков процедуры. С тех пор переменным значения даю сразу же в момент их объявления. На крайний случай просто обнуляю их, если реально нужных значений для них в момент объявления пока не существует. Но главное, чтобы в них не оказывались значения случайные, неожиданные.
Ну да. Наваяние любого нового протокола, предназначенного для замены старого, не отменит использование протокола старого потому, что старый протокол запретить невозможно и значит любой самый распрекрасный протокол будет не заменой, а действительно просто +1 протоколом.
Слышал я много лет назад байку про то, что всякие там "всратые" провайдеры типа AOL и всякие другие (какие у них там в США тогда были) именно такие собственные какие-то там почтовые протоколы своим клиентам и предлагали, а потом как-то "победила" обычная электронная почта, которую сейчас мы все сейчас совместимо друг с другом и используем.
А в конце 90-х годов у нас на узле интернет ещё была поддержка почты UUCP. Во прикол был. :-) Но она тогда поддерживалась на узле в качестве просто поддержки пользователей, которые с почтой могут работать только в виде UUCP и нами считалась устаревшей и доживающей свой век.
Идея платности для охлаждения спамерского пыла у меня тоже была.
Вот есть сейчас на сайтах страницы с контактами.
Ну там на них указаны — телефоны, формы обратной связи, емайлы уже серьёзные люди на сайтах не указывают.
Если кому-то надо серьёзно связаться, он берёт и сразу звонит — ну если дело настолько важное, что нужна гарантия обмена сообщениями, а не просто "отправил форму обратной связи и гадай — прочитали её или не прочитали".
Так вот: звонок по телефону является делом обычно платным для вызывающей стороны. И ничего — это не проблема для тех, кому связаться и поговорить действительно нужно.
Аналогично можно делать платной и отправку формы обратной связи. Цену делать символической — хоть 10 рублей, хоть рубль. Серьёзным людям этих денег будет не жалко, а спамер миллион сообщений по рублю за каждое рассылать уже не будет.
Письма обычные бумажные народ платно отправляет и не возмущается.
Письмо электронное ничем не хуже бумажного. По крайней мере плату можно брать для отправки письма по адресу, владельцы которлшл ещё не отменили платность приёма писем для конкретного отправителя.
Например, хочет кто-то отправить предложение о сотрудничестве по адресу, по которому он ещё ничего не посылал. Платит 10 рублей и его письмо доставляется. Если получатель думает, что от этого отправителя все следующие письма можно принимать бесплатно, то разрешает ему отправлять следующие письма уже бесплатно. Как это сделать технически — это отдельная тема.
Бывает так, что хозяину мобилы аккаунт на ней заводит другой человек, а хозяину мобилы даже бесполезно про это что-то объяснять потому, что он всё-равно это не поймёт. Почта-то на такую мобилу придёт так, что её даже может получиться прочитать. Но вот когда надо переустановить мобилу, то пароль хозяин от аккаунта своей мобилы её хозяин сказать уже не сможет.
Не. Он там по частями имел в виду части не письма, а части множества получателей.
Часть получателей — в To:
Часть — в Cc:
Часть — вообще в Bcc:
Чтобы не зависеть от владельцев систем обмена сообщениями.
Установили участники обмена сообщениями себе почтовые сервера и емайл-мессенджеры и обмениваются сообщениями свободно без учёта требований всех этих вацапов, инстаграмов и прочих систем, которые по праву "хозяин — барин" устанавливают правила своим пользователям.
Такое объединение уже сделали в емайл-мессенджере Delta chat. Я его уже хотел, было, использовать, но оказалось, что он работает только с ящиками IMAP, а у меня ящики только POP3. В создании емайл-месседжеров для POP3 тоже нет никаких проблем, но пока для POP3 их никто не создал.
От миллиона-то мессенджеров не защитит никакая альтернатива кроме альтернативы, в которой создавать миллионы мессенджеров станет невозможно.
Проблема спама в электронной почте порождена тем, что кто попало может отправлять письма куда попало и никто это ему запретить не может. Это недостаток большой свободы.
Системы, которые имеют меньше свободы (фидо, вацапы, инстаграмы, соц.сети, телеграмы и всякие прочие современные мессенджеры да системы обмена сообщениями, в которых есть жёсткое регулирование правил), меньше подвержены спаму, т.к. в них есть возможность хотя бы блокировать спамеров, что, конечно, не избавляет такие системы от спама полностью, но немного уменьшает эту проблему.
Зачем обязывать выбирать способ передачи истории, если важен только резуультат? Ну понятно, что безоапсность важна, но эту часть настройки способа передачи можно уже разрешить делать хозяину аккаунта.
Даже нескомпроментированное устройство не должно иметь возможности захватить аккаунт без доступа к некоторым внешним источникам такого захвата. Хочет, например, кто-то захватить аккаунт — пусть введёт код из СМС, отправленного на телефон хозяина аккаунта. А без такого дополнительного препятствия получается, что захватил кто-нибудь мобилу и может сразу же аккаунт захватить сам, если захваченную мобилу не успели объявить скоспроментированной, чтобы от аккаунта её отключить.
Такая возможность же в электронной почте есть. Мы её у себя даже применяем:
Делается почтовый домен локальный, который интернету не известен. Например,
krutoy-zavod. Через собственные сервера DNS этот домен делается известным всем участникам почтового обмена.
Создаются этом домене адреса типа dirktor@krutoy-zavod, buhgalter@krutoy-zavod, ohrana@krutoy-zavod, planoviy-otdel@krutoy-zavod и так далее.
Ну и дальше труженики этого крутого завода шлют друг другу почту нормально. Спамеры из интернетов им почту не пришлют. Красота же!
Эта возможность в современной почте есть. Называется HTML. Ну а вообще любое (а не только HTML) содержимое, которое можно форматировать. Или этот способ объявлен костылём?
Не почему-то, а закономерно и логично:
Кто управляет алгоритмом поиска, тот управляет и сортировкой результатов в этом алгоритме.
Какие поля тут имеются в виду? OG? Или какие-то другие поля?
Воздушные штабы управления — это только чтобы продержаться всего несколько суток, а потом всё-равно нужна посадка на какой-нибудь адродром, хотя бы импровизированный. И проблема тут не только техническая (перебили всех дозапращиков, например, или закончилось машинное масло). Там же запасов продовольствия сильно много не возьмёшь. Да и всякие дела типа госпиталя в воздухе — это дела так себе.
Корабельные штабы в этом смысле немного лучше. Но зато корабли — это просто плавучие мишени для советского флота.
Разработчик сайта на своём сервере ноду-то запустит.
И после этого клиенты смогут вытаскивать файлы из каких нод? Только из ноды разработчика. А почем только из его ноды, а не с других? Потому, что другим нодам файлы его ноды не нужны и их там значит нет. А в таком случае и нода межпланетная не нужна, т.к. быстрее и проще файлы отдать прямо с веб-сервера через хттп.
Как сделать получение клиентами файлов не с одной ноды, а из множества нод? Для этого множество нод должно файлы с ноды разработчика себе накачать. А как заставить другие ноды выкачать файлы с ноды разработчика? Администраторы (управители) других нод наверно должны своим нодам дать соответствующие указания, чтобы их ноды начали выкачивать к себе файлы сперва из ноды разработчика, а затем эти же файлы и друг от друга, ну точнее — с любых нод, где они их только смогут нашукать.
Администраторы нод безпричинно не будут накачивать себе файлы из ноды разработчика какого-то сайта. Выкачивать файлы из ноды разработчика будут только заинтересованные в этом ноды. А заинтересованы в этом ноды только пользователей сайта. Но пользователи сами себе ноды устанавливать не будут. Для них сайт — это в лучшем случае то, что они увидели по ссылке в гугле, перешли на него, немного потусовались на нём да свалили с него. Какие им там ещё ноды? А в худшем случае сайтами современные пользователи называют вообще свои инстаграмские аккаунты. Так и говорят — у нас есть сайт в инстаграме.
Поэтому установка нод у пользователей — это дело непосредственно разработчика сайта.
Понятно, что на компьютеры пользователей разработчик сайта никакие программы не установит. Остаётся ему работать только в пространстве браузера. Была по этому поводу слабая надежда на то, что запустить ноду в загруженной браузером странице можно через джаваскрипт какой-нибудь хитро-командой, жизнь которой даёт либо подключенная тегом script src=… какая-нибудь ipfs-библиотека, либо существование таких готовых джава-скрипт-решений в браузере Brave, о котором недавно объявили, что он, дескать, начал уметь работать с IPFS. Но в этом направлении у разработчиков сайтов по прежнему остаётся какой-то туман вместо ясного представления и понимания о том, как из браузера можно загружать ресурсы не с веб-серверов, а из сети IPFS.
Проблема в том, что пользователь сайта даже на сайт-то с трудом зайдёт потому, что нынче все пользователи разбежались по инстаграмчикам да телеграмчикам с вацапчиками впридачу. А уж заставить его установить к себе какую-то непонятную ему ноду — тем более проблематично. Так что вариант, в котором ноду себе поставит пользователь, мне видится почти невозможным.
Вот это хороший вариант. Пользователя заставлять и даже просить не надо установить себе ноду. Вот таким способом я себе и представляю установку ноды в браузере пользователя разработчиком сайта.
Но как конкретно это делать?
Я думал, что надо подключить какую-то библиотеку типа
и затем джаваскриптом в браузере как_то_ноду.включить()
Ходил почитать про это куда-то в район js ipfs (точный адрес непомню), а там опять предлагают установить ноду на компьютер, а не подключить js-библиотеку к html-странице.
Я на перле раньше переменные тоже только объявлял, а значения им давал "когда-то потом". Но после того, как я начал применять FastCGI, неприсваивание значений переменным в месте их объявления стало приводить к неожиданным результатам — во время следующих запусков процедуры её внутренние переменные стали помнить свои прежние значения их прошлой жизни — из предыдущих запусков процедуры. С тех пор переменным значения даю сразу же в момент их объявления. На крайний случай просто обнуляю их, если реально нужных значений для них в момент объявления пока не существует. Но главное, чтобы в них не оказывались значения случайные, неожиданные.
Так можно же в DOSBox'е носталигировать?
В школе — в какие годы? Во 2-й половине 80-х в школах на "Информатике" учить начинали с Бейсиков.