Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Воистину гениальный хакер! Искренне восхищаюсь такими людьми и по-хорошему им завидую. Для того чтобы обладать такой продуктивностью, нужно ну очень хорошо уметь полностью погружаться в задачу, причем не от случая к случаю, а стабильно каждый день.
Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
С передачей аргументов интересная тема. Исторически передача без квалификаторов означала передачу по значению через стек, хотя на самом деле передача по ссылке или еще как-то ничуть не хуже. Ваша идея отказа от неявного синтаксиса передачи сложных объектов и явного требования указания квалификаторов довольно интересна. Кстати, а почему "copy" а не какой-нибудь спецсимвол типа "@" ? Можно вообще составить список возможных способов передачи и проанализировать, что там есть.
Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
Да, TUI очарователен в своей олдскульности) И хорошо что у него осталась небольшая ниша в виде софта для ssh/терминалов. А фактически, из современных TUI IDE с классическим (не vim/emacs) интерфейсом - только FreePascal? Ничего универсального нет?
Хабр, а что с географическими ограничениями-то? Я предлагал сделать какой-то механизм, позволяющий видеть хотя-бы заголовки таких статей (и чтобы при открытии вместо статьи выводилась плашка об ограничении). Но пока я такого не видел, из чего можно сделать вывод - или таких статей пока нет, или вы сделали так что их вообще не видно. Такие статьи сейчас есть?
Конкретно для меня отличия минимальны:) И там и там есть текст (причем объем этого текста примерно одинаковый и в посте, и в комментарии), возможность прикрепить медиафайлы, возможность ставить лайки. Если сравнивать с форумами, то отличие лишь в том, что пост - первое сообщение темы, комментарий - не первое.
Децентрализованность подразумевает отсутствие центра. Платить - очевидно через предоставление своих ресурсов для вычислений. Т.е. человек предоставляет свой комп для работы сети, ему за это начисляется какая-то внутренняя децентрализованная крипта, которой он расплачивается за взаимодействие с самой сетью.
Я прекрасно понимаю огромную сложность этой задачи. Особенно - как связать математическую строгость proof of work с распределенными нейросетевыми вычислениями... Но хочется верить что гении найдутся.
Ну что можно сказать... Нам, Сообществу, определенно нужен децентрализованный свободный ИИ, неподконтрольный никакому государству. Понимаю, что это задача колоссальной сложности, но все же не невозможная. Обучение - на Либгене, Сайхабе и интернет-ресурсах, заслуживающих доверие (типа Хабра). Схема работы - чем больше участник предоставляет своих вычислительных ресурсов, тем выше его приоритет в обработке запросов.
Возможно вы и правы, про "продвижение" я даже не подумал (и по хорошему вообще не знаю что это такое:) ). В любом случае, вдруг эта идея понравится топикстартеру в качестве "цели"?
У меня есть идея, как использовать websocket для практических целей. Сейчас распространены браузерные расширения-прокси. Но иногда нужно использовать прокси не только из браузера, но и из других программ. Да, можно озаботиться независимым прокси-сервером или VPN, но почему не использовать эти многочисленные браузерные расширения?
Например, в соцсети VK есть группы, которые не удалены, а заблокированы по региональному признаку. Я сейчас в рамках изучения Go пишу пет-проект, позволяющий скачивать из VK интересующую меня информацию с помощью vkapi в локальную БД sqlite и работать с ней через веб-интерфейс на локалхосте. Но проблема в том, что vk-токен привязан к ip-адресу. Т.е. если токен получен с некоторого ip, то и использовать его можно только с этого ip. Токен получается в браузере, а используется в стороннем приложении на Go. Пока работаем с реального ip, всё хорошо. Но если браузер использует прокси-расширение, соответственно и стороннему приложению необходимо как-то использовать то же самое прокси-расширение... Но расширение функционирует только в браузере!
Идея в следующем. Что если написать еще одно расширение, которое будет выступать как прокси-сервер, доступный в системе через websocket? С ним связывается программа на Go, которая с другой стороны работает как обычный локальный прокси. То есть получаем связку "браузерное прокси-расширение <-> браузерное websocket-расширение <-> локальный прокси <-> приложение, использующее прокси". Вот такая идея.
Кстати о стене. Я тут экспериментирую с VK API, и наткнулся на очевидную кривизну реализации этих самых стен. Там есть понятие "пост" и "комментарий". И оказалось, что "комментарии" запрашиваются отдельными функциями, вообще не являются постами и скорее всего даже хранятся в отдельной таблице. Возможно, это артефакт того самого знаменитого изменения "стены".
Для юзера и группы есть функция "получить посты", которая возвращает JSON постов упорядоченный по дате. Если мы хотим получить локальную копию стены, то логично делать так: сначала скачать посты группы, а затем просто докачивать новые: как только пришел пост с датой, которая уже скачана, прекращать скачивание. Получается вполне нормальная синхронизация.
А вот с комментариями так не получится. Есть аналогичная функция "получить комментарии", но она требует id конкретного поста. То есть, чтобы получить обновления комментариев стены, нужно проверять КАЖДЫЙ пост на стене.
Как было бы правильно: посты и комментарии хранить в единой таблице, упорядоченной по дате добавления. Каждая запись имеет дополнительное поле parent_id, содержащий 0 для поста и id поста для комментария. Соответственно, функция VK API тоже одна. Однако, чтобы это сделать надо перелопатить всю архитектуру VK и поменять всю базу, так что вряд ли кто на это пойдет)))
В языке много интересного и полезного, но есть и странное: return из лямбды по умолчанию возвращает управление из объемлющей функции! Я вот реально удивился такому. Естественно, такую лямбду нельзя возвратить, она оказывается как-бы гвоздями прибита к объемлющей функции.
Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Воистину гениальный хакер! Искренне восхищаюсь такими людьми и по-хорошему им завидую. Для того чтобы обладать такой продуктивностью, нужно ну очень хорошо уметь полностью погружаться в задачу, причем не от случая к случаю, а стабильно каждый день.
Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
С передачей аргументов интересная тема. Исторически передача без квалификаторов означала передачу по значению через стек, хотя на самом деле передача по ссылке или еще как-то ничуть не хуже. Ваша идея отказа от неявного синтаксиса передачи сложных объектов и явного требования указания квалификаторов довольно интересна. Кстати, а почему "copy" а не какой-нибудь спецсимвол типа "@" ? Можно вообще составить список возможных способов передачи и проанализировать, что там есть.
Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
Очевидно, готовятся к тому, чтобы блокировать каналы, неугодные правящему режиму.
Да, TUI очарователен в своей олдскульности) И хорошо что у него осталась небольшая ниша в виде софта для ssh/терминалов. А фактически, из современных TUI IDE с классическим (не vim/emacs) интерфейсом - только FreePascal? Ничего универсального нет?
Хабр, а что с географическими ограничениями-то? Я предлагал сделать какой-то механизм, позволяющий видеть хотя-бы заголовки таких статей (и чтобы при открытии вместо статьи выводилась плашка об ограничении). Но пока я такого не видел, из чего можно сделать вывод - или таких статей пока нет, или вы сделали так что их вообще не видно. Такие статьи сейчас есть?
Конкретно для меня отличия минимальны:) И там и там есть текст (причем объем этого текста примерно одинаковый и в посте, и в комментарии), возможность прикрепить медиафайлы, возможность ставить лайки. Если сравнивать с форумами, то отличие лишь в том, что пост - первое сообщение темы, комментарий - не первое.
Децентрализованность подразумевает отсутствие центра. Платить - очевидно через предоставление своих ресурсов для вычислений. Т.е. человек предоставляет свой комп для работы сети, ему за это начисляется какая-то внутренняя децентрализованная крипта, которой он расплачивается за взаимодействие с самой сетью.
Я прекрасно понимаю огромную сложность этой задачи. Особенно - как связать математическую строгость proof of work с распределенными нейросетевыми вычислениями... Но хочется верить что гении найдутся.
Ну что можно сказать... Нам, Сообществу, определенно нужен децентрализованный свободный ИИ, неподконтрольный никакому государству. Понимаю, что это задача колоссальной сложности, но все же не невозможная. Обучение - на Либгене, Сайхабе и интернет-ресурсах, заслуживающих доверие (типа Хабра). Схема работы - чем больше участник предоставляет своих вычислительных ресурсов, тем выше его приоритет в обработке запросов.
Возможно вы и правы, про "продвижение" я даже не подумал (и по хорошему вообще не знаю что это такое:) ). В любом случае, вдруг эта идея понравится топикстартеру в качестве "цели"?
В каждой клавише по карману?
У меня есть идея, как использовать websocket для практических целей. Сейчас распространены браузерные расширения-прокси. Но иногда нужно использовать прокси не только из браузера, но и из других программ. Да, можно озаботиться независимым прокси-сервером или VPN, но почему не использовать эти многочисленные браузерные расширения?
Например, в соцсети VK есть группы, которые не удалены, а заблокированы по региональному признаку. Я сейчас в рамках изучения Go пишу пет-проект, позволяющий скачивать из VK интересующую меня информацию с помощью vkapi в локальную БД sqlite и работать с ней через веб-интерфейс на локалхосте. Но проблема в том, что vk-токен привязан к ip-адресу. Т.е. если токен получен с некоторого ip, то и использовать его можно только с этого ip. Токен получается в браузере, а используется в стороннем приложении на Go. Пока работаем с реального ip, всё хорошо. Но если браузер использует прокси-расширение, соответственно и стороннему приложению необходимо как-то использовать то же самое прокси-расширение... Но расширение функционирует только в браузере!
Идея в следующем. Что если написать еще одно расширение, которое будет выступать как прокси-сервер, доступный в системе через websocket? С ним связывается программа на Go, которая с другой стороны работает как обычный локальный прокси. То есть получаем связку "браузерное прокси-расширение <-> браузерное websocket-расширение <-> локальный прокси <-> приложение, использующее прокси". Вот такая идея.
Кстати о стене. Я тут экспериментирую с VK API, и наткнулся на очевидную кривизну реализации этих самых стен. Там есть понятие "пост" и "комментарий". И оказалось, что "комментарии" запрашиваются отдельными функциями, вообще не являются постами и скорее всего даже хранятся в отдельной таблице. Возможно, это артефакт того самого знаменитого изменения "стены".
Для юзера и группы есть функция "получить посты", которая возвращает JSON постов упорядоченный по дате. Если мы хотим получить локальную копию стены, то логично делать так: сначала скачать посты группы, а затем просто докачивать новые: как только пришел пост с датой, которая уже скачана, прекращать скачивание. Получается вполне нормальная синхронизация.
А вот с комментариями так не получится. Есть аналогичная функция "получить комментарии", но она требует id конкретного поста. То есть, чтобы получить обновления комментариев стены, нужно проверять КАЖДЫЙ пост на стене.
Как было бы правильно: посты и комментарии хранить в единой таблице, упорядоченной по дате добавления. Каждая запись имеет дополнительное поле parent_id, содержащий 0 для поста и id поста для комментария. Соответственно, функция VK API тоже одна. Однако, чтобы это сделать надо перелопатить всю архитектуру VK и поменять всю базу, так что вряд ли кто на это пойдет)))
Интересно, а как обстоят дела с созданием живых организмов,
в основе ДНК которых лежат на аденин/гуанин/тимин/цитозин, а что-то еще
в основне которых лежит не ДНК или РНК а что-то еще
в основе которых лежит не углерод, а скажем кремний
Такое вообще возможно?
В языке много интересного и полезного, но есть и странное: return из лямбды по умолчанию возвращает управление из объемлющей функции! Я вот реально удивился такому. Естественно, такую лямбду нельзя возвратить, она оказывается как-бы гвоздями прибита к объемлющей функции.
ОК, еще могу с флэшки загрузиться:)