Комментарии 43
Соедините торренты и социалки и все будет ОК, и люди потянутся. Кто кто первый это сделает и будет отцом распределенного Интернета.
Просьба к тем кто реально готов поучаствовать в разработке — написать в ЛС, обсудим.
Может быть действительно получится совместными усилиями что-то подобное реализовать.
Может быть действительно получится совместными усилиями что-то подобное реализовать.
Я думал тут про wi-fi mesh, чтоб без провайдеров обходиться…
А как/кем будет решатся проблема достоверности данных? Грубо говоря кто защитит от кучи мусорных песен/фильмов? Во времена всяких Napster/Kazza/Gnutella правообладатели любили загаживать сеть мусорным контентом. За что сейчас лично мне торренты и нравятся есть хоть кто то кто выступает гарантом что качаешь не мусор.
В предлагаемом варианте каждый пользователь хранит свои данные + только небольшую часть общих. Причем общие составляют сообщения и прочие мелочи.
Если правообладатель загрузит мусорный файл — то у него он и останется. Даже если его кто-то найдет в поиске — то увидев что это мусор — удалит. А так как при поиске файлы ранжируются в зависимости от кол-ва пользователей у которых файл есть — то мусор никогда не выйдет в топ.
По сути ничто не мешает распространять через такую сеть обычные торренты, более того, сами статьи с описанием постепенно «скопируются» в распределенную сеть, и даже если трекер закроют — доступ к контенту останется.
И кстати, в современных соц. сетях правообладатели точно также могут грузить мусор если захотят.
Если правообладатель загрузит мусорный файл — то у него он и останется. Даже если его кто-то найдет в поиске — то увидев что это мусор — удалит. А так как при поиске файлы ранжируются в зависимости от кол-ва пользователей у которых файл есть — то мусор никогда не выйдет в топ.
По сути ничто не мешает распространять через такую сеть обычные торренты, более того, сами статьи с описанием постепенно «скопируются» в распределенную сеть, и даже если трекер закроют — доступ к контенту останется.
И кстати, в современных соц. сетях правообладатели точно также могут грузить мусор если захотят.
Нужна модерация. У каждой темы/паблика/сайта должен быть владелец, который полностью контролирует контент, а юзеры сами выберут надёжные сайты.
Это верно. Я просто не стал все расписывать, текст и так разросся.
По любому, чтобы устроить обмен между сайтом и распр. сетью — нужно описывать шаблон, а значит есть люди которые занимаются именно этой площадкой, поддерживают актуальность шаблона, дорабатывают его и т.п. По сути работает принцип википедии — есть некая иерархия модераторов и программистов которые развивают сеть.
А владельцами сообществ, страниц и т.п. — являются их реальные владельцы. Потому что только они могут подтвердить право на страницу опубликовав на ней проверочный код (Шаг 2). И это важный момент так как иначе будет бардак — люди захотят присвоить чужие страницы, группы и т.п.
По любому, чтобы устроить обмен между сайтом и распр. сетью — нужно описывать шаблон, а значит есть люди которые занимаются именно этой площадкой, поддерживают актуальность шаблона, дорабатывают его и т.п. По сути работает принцип википедии — есть некая иерархия модераторов и программистов которые развивают сеть.
А владельцами сообществ, страниц и т.п. — являются их реальные владельцы. Потому что только они могут подтвердить право на страницу опубликовав на ней проверочный код (Шаг 2). И это важный момент так как иначе будет бардак — люди захотят присвоить чужие страницы, группы и т.п.
Это тока в рунете в торентах все классифицировано и рассортировано (невероятно круто на самом деле)
На пиратской бухте которой приходится пользоваться буржуям царит адский ад.
На пиратской бухте которой приходится пользоваться буржуям царит адский ад.
От этого достаточно просто избавится — сделать систему оценок.
Quiensabe, видимо, особо не использовал никаких распределенных сетей, нацеленных на обмен файлами и анонимность. Взять, к примеру, тот же Perfect Dark. Внутри программы есть подписи к файлам, так что сразу понятно, кто выложил этот файл, есть рейтинги (ты не можешь удалить скачанный файл, пока его не оценишь положительно, нейтрально или отрицательно), что отлично помогает бороться с фейками, есть встроенный форум и бегущая shout-строка. Пользователь должен дать программе как минимум 40ГБ места на HDD, сеть постоянно что-то качает и раздает. Таким образом, решена проблема отсутствия сидов в торренте — сиды в Perfect Dark есть практически всегда, т.к. файлы размазаны в сети и продублированы у большого количества пользователей.
Да и вообще, есть и просто проекты распределенных файловых систем, вроде Tahoe-LAFS, или новомодная OFS [1], [2]
Для децентрализованного обмена сообщениями есть тот же I2P-Bote, Bitmessage.
Quiensabe, видимо, особо не использовал никаких распределенных сетей, нацеленных на обмен файлами и анонимность. Взять, к примеру, тот же Perfect Dark. Внутри программы есть подписи к файлам, так что сразу понятно, кто выложил этот файл, есть рейтинги (ты не можешь удалить скачанный файл, пока его не оценишь положительно, нейтрально или отрицательно), что отлично помогает бороться с фейками, есть встроенный форум и бегущая shout-строка. Пользователь должен дать программе как минимум 40ГБ места на HDD, сеть постоянно что-то качает и раздает. Таким образом, решена проблема отсутствия сидов в торренте — сиды в Perfect Dark есть практически всегда, т.к. файлы размазаны в сети и продублированы у большого количества пользователей.
Да и вообще, есть и просто проекты распределенных файловых систем, вроде Tahoe-LAFS, или новомодная OFS [1], [2]
Для децентрализованного обмена сообщениями есть тот же I2P-Bote, Bitmessage.
Интересно, как решены такие проблемы:
1. Можно создать 100500 аккаунтов и с них оценить фейк-контент положительно.
2. Можно создать 100500 терабайтных файлов с псевдослучайным содержимым, которое не надо хранить на диске, а можно вычислить по seed-у любой файл с любого места и заспамить всю сеть этим мусором так, что 40ГБ всех юзеров будут забиты только этим.
1. Можно создать 100500 аккаунтов и с них оценить фейк-контент положительно.
2. Можно создать 100500 терабайтных файлов с псевдослучайным содержимым, которое не надо хранить на диске, а можно вычислить по seed-у любой файл с любого места и заспамить всю сеть этим мусором так, что 40ГБ всех юзеров будут забиты только этим.
1. Можно создать 100500 аккаунтов и с них оценить фейк-контент положительно.Аккаунтов там вообще нет, только подписи к файлам.
2. Можно создать 100500 терабайтных файлов с псевдослучайным содержимымНе знаю, но как-то точно борются.
НЛО прилетело и опубликовало эту надпись здесь
Вы не понимаете в чем проблема современного интернета без анонимности. Так проблему не решить, нужны более радикальные средства:
1. Беспилотные летательные аппараты с wifi. Или спутники.
2. Протокол соединения без фиксированной топологии сети и адресов устройств. А также передача информации без центральной точки(сервера).
3. Другая система ДНС. Или отсутствие ее.
А то что вы предлагаете, просто сменит вектор давления с корпораций напрямую на людей.
1. Беспилотные летательные аппараты с wifi. Или спутники.
2. Протокол соединения без фиксированной топологии сети и адресов устройств. А также передача информации без центральной точки(сервера).
3. Другая система ДНС. Или отсутствие ее.
А то что вы предлагаете, просто сменит вектор давления с корпораций напрямую на людей.
Вы сейчас изобрели mesh-сети :)
Не это не я. К сожалению :) просто процитировал развернуто. Вдруг человек не понимает в чем проблема.
Я понимаю в чем проблема, но я решаю другую задачу. Полная анонимность для всех сейчас недостижима в принципе, так как потребует огромных вложений, а тем у кого есть деньги — это не выгодно.
Я решаю задачу противодействия контролю над интернетом. Причем это решение должно быть простым для обычных пользователей, не должно мешать им, не должно менять привычный для них порядок работы и отдыха. Но должно дать им контроль над их данными и их «цифровой жизнью».
По моему этих целей достаточно чтобы задуматься.
Я решаю задачу противодействия контролю над интернетом. Причем это решение должно быть простым для обычных пользователей, не должно мешать им, не должно менять привычный для них порядок работы и отдыха. Но должно дать им контроль над их данными и их «цифровой жизнью».
По моему этих целей достаточно чтобы задуматься.
Я сейчас в фоновом режиме занимаюсь реализацией распределённой системы (форумы + блоги) на более привычной платформе. Среднего юзера очень сложно заставить установить себе что-то кроме браузера (реально это сразу снижает число желающих общаться в десятки раз). Поэтому я делаю систему, в которой база данных хранится в DVCS (соответственно, легко реплицируется между массой источников), данные откуда грузятся в привычные локальные БД на web-гейтах, на которых и сидят пользователи в привычных им классических форумах и блогах. Т.е. для простого пользователя ничего не изменится кроме двух вещей:
— При блокировках ресурсов ему достаточно будет переключиться на другой гейт и продолжить общение в привычной среде
— Любой гейт может без каких-то моральных проблем по запросу гос. органов блокировать доступ от себя к той или иной информации, что почти не усложнит доступ к ней пользователей — достаточно будет или зайти со стороннего гейта или вообще просто скачать всю базу сообщений. А физически удалить данные будет сложно, так как даже при формальном удалении из DVCS, данные останутся в истории.
Ну и мелкие бонусы, типа сильного усложнения подделки истории, возможность реализовать десктопные клиенты, работающие со своим экземпляром базы и т.п.
Подводные камни тоже есть (например, вопросы взаимного доверия гейтов с целью борьбы со спамом и т.п.), но понемногу процесс идёт :) Попробую для начала объединить 3-4 своих разнородных форума — если дело выгорит, приглашу желающих присоединиться в такую сеть :)
— При блокировках ресурсов ему достаточно будет переключиться на другой гейт и продолжить общение в привычной среде
— Любой гейт может без каких-то моральных проблем по запросу гос. органов блокировать доступ от себя к той или иной информации, что почти не усложнит доступ к ней пользователей — достаточно будет или зайти со стороннего гейта или вообще просто скачать всю базу сообщений. А физически удалить данные будет сложно, так как даже при формальном удалении из DVCS, данные останутся в истории.
Ну и мелкие бонусы, типа сильного усложнения подделки истории, возможность реализовать десктопные клиенты, работающие со своим экземпляром базы и т.п.
Подводные камни тоже есть (например, вопросы взаимного доверия гейтов с целью борьбы со спамом и т.п.), но понемногу процесс идёт :) Попробую для начала объединить 3-4 своих разнородных форума — если дело выгорит, приглашу желающих присоединиться в такую сеть :)
Идея с репозиториями мне понравилась. А как обстоят дела с производительностью? Насколько я понял, вы делаете периодические бекапы локальных БД коммитами в DVCS. Просто интересно, как происходит синхронизация гейтов, ведь коллизии неизбежны имхо
Вопрос с производительностью — это больное место :D Сейчас прирост объёмов самой активной группы форумов у меня составляет до 5Гб в месяц. Если резать по специализации (у меня широкий охват тем), то самая популярная группа (флот и судомоделизм) растёт примерно на 2Гб в месяц. Так что надо как-то это всё дробить.
Изначально я ориентировался на вариант «один репозиторий — один год». Получил что-то в районе нескольких гигабайтов (точно уже не помню) и под миллион файлов (для простоты синхронизации я храню данные в виде одно сообщение == один JSON-файл + первоначально думал о хранении человеко-читаемого .txt рядом для ручного просмотра тем). git и mercurial с таким справляются, в общем… Но очень грустно и безрадостно :D
Тогда порезал по месяцам. Стало намного веселее. И полная обработка репозитория шла порядка минут или даже десятков секунд (тоже уже не помню точных цифр). И добавление данных было шустрым (а вопрос в первую очередь в нём). Но тут я добавил в репозиторий аттачи… :D И всё снова стало плохо. Даже не в смысле производительности. Я хочу иметь возможность работать со свободными репозиториями типа github (это резко повысит простоту использования системы средним администратором, не потребуется разворачивать свои собственные репозитории). А это накладывает лимиты на объёмы. Скажем, на Гитхабе можно без проблем держать репозитории до гигабайта размером. Нарезка репозиториев на проекты помогает мало, как писал выше, флотский раздел жрёт по 2Гб в месяц (и величина ещё будет расти).
Это, в итоге, одна из проблем, над которой сейчас ломаю голову. Решения есть, но все мне мало нравятся:
1. Вынести работу с аттачами в отдельную систему. Скажем, BTSync. Это позволит обмениваться ими вообще без центрального сервера, полностью децентрализовано. Но эта идея мне нравится мало потому что хочется иметь все данные в одной корзинке — т.е. чтобы сообщения темы форума и её аттачи хранились в одной сущности. А то за 15 лет работы с форумами я насмотрелся на неоднократные потери файловых архивов даже когда оставались текстовые :)
2. Делать настраиваемую гранулярность и для особенно активных разделов форумов заводить новые репозитории хоть раз в неделю. Вариант не нравится какой-то чрезмерностью… Хотя индивидуальную гранулярность по проектам в любом случае полезно сделать, т.к. есть группы форумов, обновляющиеся редко и мало, там можно хоть раз в 10 лет заводить новую репу. Нет смысла нарезать каждый месяц несколько сотен сообщений…
3. Забить на проблему открытых DVCS-серверов и для больших проектов использовать собственные мощности. Самый «честный» метод, но он же и самый уязвимый.
Наверное, в целом, самый верный метод — первый. Но как не хочется распыляться по разным сущностям! :)
Изначально я ориентировался на вариант «один репозиторий — один год». Получил что-то в районе нескольких гигабайтов (точно уже не помню) и под миллион файлов (для простоты синхронизации я храню данные в виде одно сообщение == один JSON-файл + первоначально думал о хранении человеко-читаемого .txt рядом для ручного просмотра тем). git и mercurial с таким справляются, в общем… Но очень грустно и безрадостно :D
Тогда порезал по месяцам. Стало намного веселее. И полная обработка репозитория шла порядка минут или даже десятков секунд (тоже уже не помню точных цифр). И добавление данных было шустрым (а вопрос в первую очередь в нём). Но тут я добавил в репозиторий аттачи… :D И всё снова стало плохо. Даже не в смысле производительности. Я хочу иметь возможность работать со свободными репозиториями типа github (это резко повысит простоту использования системы средним администратором, не потребуется разворачивать свои собственные репозитории). А это накладывает лимиты на объёмы. Скажем, на Гитхабе можно без проблем держать репозитории до гигабайта размером. Нарезка репозиториев на проекты помогает мало, как писал выше, флотский раздел жрёт по 2Гб в месяц (и величина ещё будет расти).
Это, в итоге, одна из проблем, над которой сейчас ломаю голову. Решения есть, но все мне мало нравятся:
1. Вынести работу с аттачами в отдельную систему. Скажем, BTSync. Это позволит обмениваться ими вообще без центрального сервера, полностью децентрализовано. Но эта идея мне нравится мало потому что хочется иметь все данные в одной корзинке — т.е. чтобы сообщения темы форума и её аттачи хранились в одной сущности. А то за 15 лет работы с форумами я насмотрелся на неоднократные потери файловых архивов даже когда оставались текстовые :)
2. Делать настраиваемую гранулярность и для особенно активных разделов форумов заводить новые репозитории хоть раз в неделю. Вариант не нравится какой-то чрезмерностью… Хотя индивидуальную гранулярность по проектам в любом случае полезно сделать, т.к. есть группы форумов, обновляющиеся редко и мало, там можно хоть раз в 10 лет заводить новую репу. Нет смысла нарезать каждый месяц несколько сотен сообщений…
3. Забить на проблему открытых DVCS-серверов и для больших проектов использовать собственные мощности. Самый «честный» метод, но он же и самый уязвимый.
Наверное, в целом, самый верный метод — первый. Но как не хочется распыляться по разным сущностям! :)
Если речь заводить о проблемах, то ещё одна проблема, хотя более мелкая — UUID. Сообщений, топиков и т.п.
Если использовать «честные» UUID, то отпадает прямое использование классических форумных движков. Там почти везде ID целочисленные автоинкрементные.
Можно использовать для согласованных закрытых доверенных гейтов автоинкременты с договорным смещением. Но это усложняет расширение и снижает рабочие диапазоны ID.
Наконец, есть вариант, когда форум при импорте из DVCS прописывает собственный, не общесистемный ID а при экспорте задаёт UUID. Но такой вариант не позволит легко менять ссылки при смене гейта, при реимпорте базы может пропасть соответствие ID-UUID и т.п.
Я пока ориентируюсь на некий гибридный вариант — есть UUID в системе, есть целочисленный ID гейта. И есть патчи движков форумов, которые оперируют ссылками, содержащими в себе как ID, так и UUID. Не особенно изящно, но работоспособно :)
Если использовать «честные» UUID, то отпадает прямое использование классических форумных движков. Там почти везде ID целочисленные автоинкрементные.
Можно использовать для согласованных закрытых доверенных гейтов автоинкременты с договорным смещением. Но это усложняет расширение и снижает рабочие диапазоны ID.
Наконец, есть вариант, когда форум при импорте из DVCS прописывает собственный, не общесистемный ID а при экспорте задаёт UUID. Но такой вариант не позволит легко менять ссылки при смене гейта, при реимпорте базы может пропасть соответствие ID-UUID и т.п.
Я пока ориентируюсь на некий гибридный вариант — есть UUID в системе, есть целочисленный ID гейта. И есть патчи движков форумов, которые оперируют ссылками, содержащими в себе как ID, так и UUID. Не особенно изящно, но работоспособно :)
Мне кажется, выходом был бы гибрид из обычной репликации БД, например, по «кольцу» из гейтов, с более медленной периодической DVCS. При добавлении сообщения инсерт проходит по кольцу репликацией, обеспечивается доступность информации. А периодический гит-бекап позволяет в автоматическом режиме открывать новые гейты.
Ну, может, насчет кольца я загнул, ибо оно может быть реально огромным с соответствующими лагами. Так что это еще и задачка на топологию.
Ну, может, насчет кольца я загнул, ибо оно может быть реально огромным с соответствующими лагами. Так что это еще и задачка на топологию.
Не думаю, что репликация по кольцу будет так уж эффективнее. С одной стороны экспорт/импорт каждого сообщения через DVCS нагрузки большой не должен создавать, с другой — репликация накладывает сразу массу жёстких ограничений на инфраструктуру. Скажем, нельзя будет соединить в сеть форумы на разных движках. Нельзя будет реализовывать свои собственные особенности/расширения на каком-то из гейтов. А это тоже вопрос актуальный — так или иначе это всё ещё монетизировать нужно. Так что будет и вопрос конкуренции даже между гейтами в одной сети. Пока кто-то занимается разработкой и улучшениями своего гейта — это позволит привлекать ему посетителей и отрабатывать затраты хотя бы баннерной рекламой.
Тут пара парней сделали чаны на основе NNTP, ну и веб-интерфейс к ним, конечно. Они получаются и децентрализованные, и распределенные. Исходники точно открыты, но не знаю, где взять (сходу не нашел):
overchan.dlms.i2p/
slamspeechicukxu.onion/
sfjdg275q2ash3jt.onion/
overchan.dlms.i2p/
slamspeechicukxu.onion/
sfjdg275q2ash3jt.onion/
«могут в два клика установить наше расширение»
Уже на этом пункте всё и закончится, т.к. Google Store вполне централизованное хранилище,
которое ваше расширение просто удалит.
Установка расширений не из стора будет ещё больше затруднена, чтобы отсеять 95% пользователей по фактору лени.
По поводу локального хранения своих данных и чуточки чужих — смотрите проект Pandora на хабре от robux
Уже на этом пункте всё и закончится, т.к. Google Store вполне централизованное хранилище,
которое ваше расширение просто удалит.
Установка расширений не из стора будет ещё больше затруднена, чтобы отсеять 95% пользователей по фактору лени.
По поводу локального хранения своих данных и чуточки чужих — смотрите проект Pandora на хабре от robux
Расширение не нарушает правил стора, значит чтобы гугл его удалил — нужны веские «причины» со стороны политиков. А это возможно только если расширение станет действительно массовым…
В этом случае можно будет написать мини-клиент который будет запускаться и ставить расширение пользователю.
За наводку спасибо! Посмотрим обязательно.
В этом случае можно будет написать мини-клиент который будет запускаться и ставить расширение пользователю.
За наводку спасибо! Посмотрим обязательно.
Вот прямая ссылка на описание Пандоры (PDF, 380Kb).
Бурное обсуждение на Хабре и на ЛОРе.
Ну и сообщество вконтакте.
Бурное обсуждение на Хабре и на ЛОРе.
Ну и сообщество вконтакте.
Коммерческие социальные сети кровно заинтересованы, в том, чтобы пользователи хранили свои данные именно у них, поэтому, боюсь, они будут активно противодействовать сторонним клиентам с описанными возможностями. И проблем у них с этим не возникнет, поскольку сторонние клиенты вынуждены регистироваться для получения ключей доступа к API, а отозвать такой ключ можно в момент. И ваша кнопочка просто перестанет работать. Я не удивлюсь, если в правилах пользования для разработчиков такие пункты уже есть.
Боюсь, решение в таких условиях может быть только кардинальным — создание собственной распределенной соцсети. Вот только монетизацией тут особо не пахнет, а ресурсы на разработку и раскрутку потребуются немалые…
Боюсь, решение в таких условиях может быть только кардинальным — создание собственной распределенной соцсети. Вот только монетизацией тут особо не пахнет, а ресурсы на разработку и раскрутку потребуются немалые…
В статье описывается вариант когда API соц.сетей не используются. Информацию расширение получает через аккаунты самих пользователей, а их все не заблокировать.
При этом описываемая система фактически представляет собой распределенную соц. сеть. Думаю реализация в рамках OpenSource возможна. Так ли это, покажет время.
При этом описываемая система фактически представляет собой распределенную соц. сеть. Думаю реализация в рамках OpenSource возможна. Так ли это, покажет время.
Странно, что никто не написал про Diaspora
P.S. Линк вставить не могу по кармотехническим причинам. Гуглится легко.
P.S. Линк вставить не могу по кармотехническим причинам. Гуглится легко.
Выскажу пару соображений:
- «Соц. сети пойдут на всё, но не допустят такого
развития» — этот пункт во многом справедлив, так что напротив него я поставил одну из галочек в опросе. Проблема в том именно, что каждая нынешняя интернетовская социальная сеть не распределена, а централизована. Следовательно, существует колоссальных размеров груда серверов, на обслуживание её тратится гигантская куча деньжищщ, и попытка на этом попаразитировать (мощностями попользоваться, но прибыль перестать приносить) будет воспринята, я полагаю, негативно. Крайне негативно. Парадокс именно в том, что совокупная мощь компьютеров и мобильных устройств у пользователей — ещё больше; работоспособность Фидонета и тем более работоспособность торрентового файлообмена (который имеет дело с многотерабайтными объёмами данных на диске большинства пользователей, будь то поклонники телесериалов или поклонники аниме) являются наглядными тому свидетельствами, так что распределённая сеть вполне жизнеспособна. Но вот если она будет пробовать попаразитировать на существующей централизованной социальной сети, то сможет не только отпочковаться от неё, но и (в одном из вероятных сценариев) погубить её. И еврейские создатели социальных сетей знают об этом.
- «Власти пойдут на все, но не допустят такого
развития» — напротив этого варианта я не ставил галочку, так как нет оснований для уверенности в том, что власти могли успеть просчитать и начать воспринимать именно этот вариант развития как угрозу для себя. С другой стороны, власти могут не допустить этого варианта просто в рамках реализации какого-нибудь собственного проекта, имеющего более общее направление действий. Например, антиблогосферический закон, вступающий в действие 1 августа (осталось42 дня), если его будут реализовывать по наиболее жёсткому сценарию (белые спискиIP-адресов, принадлежащих очень немногим «зарегистрированным блогам», количество которых определяется сознательно созданною волокитою и прямыми отказами при регистрации, жёсткий запрет соединения со всем остальным Интернетом, включая зарубежный), немедленно поставит крест и на этой воображаемой распределённой социальной сети, и на существующем файлообмене, и на видеотелефонныхP2P-переговорах, и на P2P-чатниках, и на DVCS, и на Tor, и на VPN, и на I2P. Выходом из этой ситуации может стать тольконяш-меш: распределёнными, находящимися в собственности и под контролем у пользователей, должны стать и соединения между пользователями, а не одна только информация, ими накопленная.
Заголовок не соответствует содержанию. Интернет это не соц.сети.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Плавный переход к распределенному интернету?