P2P блоги, вики - F2F сеть

Решено

Fri, 18 Jan 2008 05:58:02 GMT

P2P блоги, редактируемый в реальном времени P2P веб... Нагло заявляю, что проблема мной решена. Реализовать такую систему - вполне просто и обозримо, вопрос только возможно ли уложиться в JavaScript или придётся хачить на уровне браузера (extensions, embedding, etc).

Время, время, время

Sat, 15 Dec 2007 14:38:17 GMT

Google Reader приделали функцию Share with friends. Вот вам и F2F блоги! Вот вам и Паранойя!
Мы живём в мире, где горячие идеи нужно думать очень быстро!

Неофициальная международная конференция по web 2.0

Sat, 15 Sep 2007 08:48:34 GMT

BlogCamp - это "неконференция" для стран СНГ и Балтии по новым медиа, блогам, веб 2.0 и всем, что с этим связано. Киев 13-14 октября (суббота-воскресение) 2007 года.

Работает wiki сайт http://blogcamp.com.ua , ЖЖ сообщество http://community.livejournal.com/blogcamp
На сайте http://blogcamp.com.ua можно посмотреть темы докладов и записаться в участники.

Прошу прощения за оффтоп.

Tue, 03 Jul 2007 08:42:16 GMT

Мне понравились ваши посты (пришел сюда с Хабра) и мы как раз сей час пишем некую реализацию соц. надстройки над интернетом. И нам нужны талантливые программисты на PHP и технологи SW. Кому интересно - просите у меня инвайты на гуглгруп просить сюда: nicholas.korobko[sobachka]gmail[dot]com

Кстати, мы будем рады реализовать прогрессивные и интересные идеи. У нас уже есть небольшая команда: СЕО, менеджеры и пара программистов. Пока мы работаем на энтузиазме, потому и хотим, что б проект окупился и начал приносить деньги.

Вопросы разработки

Thu, 21 Dec 2006 11:16:27 GMT

В паранойе есть сейчас такая проблема - у меня удаленные источники закачиваются всякий раз, даже при переходе на следующую страницу Моих Новостей. Соответственно, если RSS-источников много, надо со многими удаленными сайтами установить связь, скачать их файл и все такое - тратится много времени. Эту проблему я оставил в тылу, но вот пришло время к ней снова обратиться, потому что меня самого стали временные лаги раздражать :). Веб-сервер видимо сам как-то кеширует, конечно, потому что временной лаг самый большой при первом заходе на страницу после большого перерыва, но это слабое утешение.

В RSS есть такая возможность - там прописывается дата последнего обновления его (lastBuildDate), чтобы можно было не закачивать всякий раз, а только когда обновился. Я собираюсь сейчас ее начать использовать, а то очень долго все загружается при переходе со страницы на страницу, а надо чтобы один раз загрузилось.

Вопрос 1) что надо делать, если эта дата не задана (варианты - загружать всегда, загружать с периодичностью по умолчанию, загружать только первый раз)
Вопрос 2) чтобы эту дату получить, все равно надо часть удаленного файла скачать (тратится время на установку соединения и все такое) - стоит ли сделать задержку по умолчанию - например, раньше чем через 5 минут после последнего обновления все равно информацию с удаленного узла (например, ЖЖ) не грузить?

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

(еще бы, конечно, просто обработать ответ веб-сервера "403 Not Modified", но я удаленный RSS открываю простой функцией открытия файла, она не умеет это обрабатывать)

Кросс-пост в http://kormitigrov.livejournal.com/25516.html

Планы по прикручиванию к Паранойе

Sat, 16 Dec 2006 08:19:02 GMT

1. Раздавать как можно больше всего по RSS, в том числе и комментарии, только как интересно? Кто-нибудь знает, как в RSS раздавать комментарии, чтобы популярные RSS-читалки их подхватывали именно как комментарии? Хотя, собственно, я тут подумал, чего это я? Я и так уже раздаю комментарии, просто все в отдельном канале. Надо сделать раздачу френд-ленты с комментариями, и еще подумать как отделить раздачу собственно сообщений пользователя для всех, кто хочет их получить, от раздачи сообщений пользователя со всеми комментариями сообщества, как она видна на вебе. Короче, задумался :)
2. Раздавать корректную последнюю дату обновления у всех RSSов, чтобы люди их могли не закачивать.
3. Как-то кешировать все закачиваемые RSS, видимо складывать куда-нибудь, и проверять только дату последнего обновления. Сейчас даже при переходе на следующую страницу новостей все источники закачиваются заново (но реально, видимо из-за кеширования самим серваком, закачивание второй раз выполняется моментально)

кросс-пост в http://kormitigrov.livejournal.com/24110.html

Описание и Инструкция к Паранойе

Sat, 09 Dec 2006 19:13:45 GMT

Написал и выложил Описание к Паранойе с картинками. Картинки получились хреновые, но пока лучше ничего не придумалось, а лучше что-то, чем ничего. Говорят ближе к концу текста картинки становятся более понятными.
Еще наконец-то процесс документироваться догнал процесс разработки :), и я переделал и выложил Инструкцию для нового пользователя, описывающую и объясняющую что там можно делать и что как работает. Надеюсь более понятно стало.

Про Бульон и с чем его едят

Wed, 29 Nov 2006 15:11:34 GMT

Как работает Бульон?

Когда Вы запрашиваете страницу в Бульон, Ваш автоматический агент опрашивает максимально доступную социальную окрестность, чтобы собрать мнения о странице, её кусочках, их релевантности и версиях. При этом учитывается репутация участников. Все запросы и ответы распространяются по сети Jabber - от друга к другу.

В результате вы получаете страницу, составленную с учётом мнений людей, которым Вы доверяете. Это позволяет сохранять среду Бульон максимально открытой, но в то же время защищённой от спама и мусора.

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

Почему это будет работать?
Предполагается, что социальный граф человечества имеет в диаметре примерно 6 шагов. Из этого следует предположение, что ценные изменения будут распространяться в сети Бульон очень быстро (одно промежуточное подтверждение может продвинуть изменение на два-четыре шага). Также, предполагая безмасштабные свойства социального графа, для того, чтобы некоторый материал стал доступен линейной пропорции участников - напр., 50%, его должны увидеть и подтвердить геометрическая пропорция хабов ("законодателей мод", сильносвязанных узлов) - напр. N^0.5, т.е. тысяча для миллиона, десять тысяч для ста миллионов. Подробнее см. диссертацию.

Особенности oc-co движка
С технической стороны, Бульон - это граф oc-co движков. (oc-co это девиз проекта: "open control, controlled openness".) Движок соответствует одному пользователю. Движок производит асинхронную обработку сообщений, обеспечивающую операцию востробования кусочков страниц из социальной окрестности. Сам oc-co движок, выполненый на Java, довольно прост - ок. 500 строк кода, использует Berkeley DB JE. Движки соединены между собой "трубами", по которым идёт XML. Технологическая реализация "трубы" несущественна - сейчас используется XMPP, но по соображениям распределения нагрузки в планах добавление прямых P2P-соединений. Движки различных пользователей могут как группироваться на сервере, так и выноситься на пользовательские машины. Возможен и комбинированный вариант, когда серверный движок обеспечивает постоянное присутствие в сети, а одновременно используемый клиентский - вычислительные ресурсы. Отдельный движок можно запускать несколькими нитями (параллелить). Вообще, в архитектуре Бульон все сообщения асинхронны, а значит и возможности распараллеливания практически неограничены.

Чего хотим достичь?
Цель проекта - усилить вики-эффект, создать среду для общего пользования - "гибрид Word и IE". Возьмём Википедию - это место, где простым языком и по порядку написаны интересные вещи и ключевые ссылки. У википедии есть ограничения - исключено отражение частных мнений, основное содержимое - лёгкий контент (текст), иначе лопнет; нет контента локальной ценности.

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

Неограниченно масштабируемый растущий коралловый риф структурированной информации - такое примерно видение.

Ссылки
Как работает Бульон? (требуется логин, юзер foaf - пароль foaf)
Сценарий: база знаний в Бульон (англ) (гибрид wiki, форума, bug tracking system и базы знаний; цель - минимизация "переключения контекстов" и необходимости в поиске/обходе мест)

Доктор, меня игнорируют! Нет, уважаемый пациент, это просто форум так работает

Tue, 28 Nov 2006 10:01:15 GMT

Только что залил на сервак Paranoia обновление скриптов, содержащее ваще убойную штуку, такой точно ни у кого нет и никто еще не догадался :). Я о ней говорил недавно.

Теперь сообщения (и свои и полученные от других на странице "Мои Новости") можно комментировать! А фишка состоит в том, что, во-первых, мои комментарии будут храниться на моем узле (вместе с другими моими сообщениями, просто в канале comments), а во-вторых, другие их будут получать по тому же самому принципу, что и все остальные сообщения - то есть те люди, которые тебе не доверяют (или просто про тебя не знают), твои комментарии не получат.

Как вам такая функциональность? Это получается форум, где одно и то же сообщение-тему могут обсуждать две группы и даже не видеть друг друга! :). А какой-то бедный чувак будет постить и постить свои комментарии, и видеть их среди общих комментариев, - но будет иметь абсолютно полное впечатление того, что его старательно игнорируют :))). Я даже сам еще не до конца понимаю, как оно должно работать, и оставил в тылу многие не очень понятные мне моменты.

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

Таким образом свои комментарии хранятся на своем узле, никуда не уходят и всегда доступны. Они вписываются в существующую архитектуру, являясь по сути теми же самыми сообщениями в отдельном канале, просто система при выводе их специальным образом обрабатывает (группируя к тем сообщениям, на которые они ссылаются).

Дальше идет неструктурированное обсуждение

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

Mon, 27 Nov 2006 08:38:18 GMT

Исходные данные: у каждого пользователя есть сообщения, которые раздаются в формате RSS, где каждому сообщению соответствует элемент item, у которого есть подэлементы guid, pubDate, title, link, description, comments, category, и что там еще? Одна из главных задач паранойи состоит в том, чтобы отслеживать, что одно и то же сообщение встретилось у многих пользователей, и увеличивать тогда его рейтинг.
Давно я думал уже как решать проблему уникальности сообщений. Тут было, собственно, два выхода - или придумывать какое-то нечеткое сравнение текста, или делать это сравнение строгим. Когда я посмотрел на формат RSS, решение пришло само собой - два сообщения считаются одинаковыми, если у них совпадают поля GUID. Поле description при этом не рассматривается. Если сообщение с однаковым GUID встретилось у многих пользователей, то текст сообщения для показа А будет взят от случайного пользователя их всех друзей А (потом это можно переделать, не суть).
Соответственно возникает проблема - как быть с подтверждением авторства сообщения, если сам текст сообщения можно менять (GUID менять нельзя - иначе это будет уже другое сообщение)? Ведь сколько не вычисляй хеш текста сообщения (общей md5, или каким-нить методом, использующим приватный ключ автора), его как-то надо будет подсоединить к сообщению, например, в виде отдельного подэлемента для элемента item! Соответственно, плохому дяде ничего не помешает оставить GUID как есть, а и сообщение, и подпись сделать другими (но соответствующими друг другу!).
Одно из возможных решений - вставлять хеш сообщения в сам GUID!. Если каждый узел будет сразу отбрасывать (при соответствующих настройках) те сообщения, у которых вычисленный им хеш не совпадает с хешем, встроенным в GUID, то проблема определения уникальности сообщения (но не авторства!) будет решена - сообщение с заданным GUID нельзя будет изменить, не изменяя GUID.
Другая проблема, которая здесь возникает, связана с тем, что пользователи, забирая друг у друга сообщения (то есть переопубликуя их самостоятельно в процессе совместной фильтрации), иногда хотят добавлять свой текст, например, "взял у Васи", а тут они не смогут этого сделать.

Ну вот, все в сборе, или Попытка обозреть необозримое

Fri, 24 Nov 2006 05:52:44 GMT

Для начала несколько ссылок по теме:

Давно существующее комьюнити по пиринг-блоггингу, которое я только что случайно обнаружил - p2p_blog.
Техтребования, или вопросы к ТЗ на F2f в комьюнити "Нейросоциум" - .
Мое ИМХО относительно п.1 ТТ - протокола поиска отдельных машин в Сети - Kademlia - это наше фсе.
Статья-заметка уважаемого В.Грищенко P2P и загрузка бэкбонов (она там между другими заметками запрятана).

Теперь существенное о себе - что schegloff знает и умеет в обсуждаемой теме.

Пользовательский опыт: Fido, форумы, ЖЖ, muTorrent, eMule (совсем чуть-чуть), RSS (со вчерашнего дня).
Программистский опыт: PHP/denver - написал 1 веб-приложение типа скрипта, Python - написал пару приблуд для работы с ЖЖ, FoxPro - пишу для себя уже лет 15 все что ни попадя (начинал с учета товарооборота).
Концептуальный опыт: две статьи по нейросоцу, к теме особо не относящиеся.

Ну и наконец о делах наших скорбных. Разрабатываем продукт.

Пользовательское описание. Кликнул, скачал, поставил. Прописал доверенным приложением в файрволле. Нажал кнопку "соединиться с p2p-блогосферой". Получил окошечко "17 servers, 364 peers". Среди "servers", разумеется, LiveJournal, npj и так далее - тоже ведь блогосфера. Нажал кнопку "Зарегистрироваться", заполнил форму, сохранил на дискету уникальное юзеринфо и все такое прочее. Получил поздравление "теперь вы в блогосфере" и первые мордашки в трее "френдов" - то ли роботов-наставников, то ли риал-юзеров учителей. Нажал кнопку "Импортировать меня", ввел ники, запустил процесс импорта с разных там ЖЖ, NPJ, blogger.com и т.д. Через 1-2-3 часа-дня-года получил поздравление "теперь вы весь в блогосфере", а также окошко с интегральной френд-лентой. Нажал кнопку "новый текст", натаскал туда цитат, по поводу которых текст, сохранил. Нажал кнопку "новый френд", добавил. Нажал кнопку "искать текст", нашел. Нажал кнопку "редактировать текст", исправил. Нажал кнопку "искать френда", нашел....

Ну и дальше такая же лабуда километрами. Выделю основную, на мой взгляд, пользовательскую характеристику продукта. Легкость перехода с других блогов - то есть поставив себе ЭТО, человек должен обнаружить, что какие-то вещи в любимом ЖЖ ему стали удобнее (френд-лента в свернутом режиме, просмотр последних 100 или 200 записей по каждому френду, ну и так далее), плюс весь функционал сохранился. Плюс новый добавился, но об этом пользователь потом узнает, не сейчас. То есть - совместимость, совместимость и еще раз совместимость.

Внутреннее описание. Выделю основные ПРОБЛЕМЫ:

- проблема "клиент-сервер". ЭТО должно работать на всем - от выделенного веб-сервера с постоянным IP и десятью крутящимися на нем же сайтами до PDA/смартфона. Таким образом, по крайней мере две категории "машин" в сети выделить придется - машина, хранящая контент (сервер) и машина, являющаяся терминалом (собственного контента не хранящая).

- проблема "онтологии". У ЭТОГО должна быть простая и понятная модель мира - вот я написал кусок текста, или подцепил картинку/музыку/видео, что с этими кусками дальше будет? куда они попадут, как там будут болтаться, как их обратно вытащить, поменять, удалить, помаркировать, перемаркировать, посмотреть кто как их откомментировал, и кто как откомментировал то, к чему они относились, и так далее, и тому подобное. Ключевой проблемой здесь, на мой взгляд, выступает -

- проблема "авторского права". Грубо говоря, может ли автор удалять контент, на который уже сделано Х ссылок? Если может, мы получаем пространство, заполняющееся висячими ссылками. Если нет (а это моя пока что позиция), мы получаем очень строгую "ответственность за базар". Поскольку процедура удаления должна прописываться в протокол маршрутизации на довольно низком уровне (одно дело, "найти N первых сохраненных копий текста", и совсем другое - "найти ВСЕ сохраненные копии текста"), мне она представляется наиболее важной.

Это пока все, думаю, этого холодного ведра за шиворот энтузиастам будет вполне достаточно.

Приложение чтение-запрос

Fri, 24 Nov 2006 03:27:45 GMT

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

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

Но главный вопрос такой -- на чем это приложение писать? Не пересылки, протоколы или там хранения. А запрос+добавление.

Феномен френдленты

Thu, 23 Nov 2006 09:42:32 GMT

На мой взгляд, одной из важных функций блога, как его привыкли понимать пользователи ЖЖ, является
френдлента - интегрированная лента не только постов тех пользователей, которых мы хотим читать, но и всяких
RSS-фидов.

Фактически - это персональная газета, собираемая из самых разных источников новостей.

Многие пользуются локальными программмами RSS-агрегаторами, которые позволяют получить такую же "газету" непосредственно в своём браузере (или вообще в спецпрограмме, или в почтовом ящике).

Но, на мой взгляд, эти программы лишены одного важного достоинства френдленты ЖЖ - френдлента публична.

Т.е. она доступна не только её владельцу, но и любому другому посетителю сайта.

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

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

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

С другой стороны, многие пользователи хотят оперативной нотификации о появлении важных новостей.

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

Задачу оперативного оповещения хорошо решает Jabber. Вообще ёе и электронная почта (rss2email) тоже решает. Вопрос в том, какой из клиентов - почтовый или IM у вас с большей вероятностью постоянно запущен, и на какой вы скорее обратите внимание.

Соответственно, не исключено что иметь интеграцию френдленты на web-сайте с pubsub-сервисом в Jabber было бы неплохо. Хотя вообще про интеграцию блогов и Jabber нужно отдельный пост писать. Поскольку и то, и другое - средства общения в сообществах, но с принципиально разной оперативностью.

Cсылки на мои посты по теме.

Tue, 21 Nov 2006 14:51:56 GMT

Все мои посты по теме распределенной блогосферы помечены тэгом distributed-blog

Список постов с краткими комментариями:

21 Дек 2004 - первый мой пост на эту тему - сравнение ЖЖ как централизованного сервиса с другими сервисами общения (FIDOnet, Jabber)

2 Июл 2005 Реакция на события связанные с флэшмобом про натовца и созданием http://lj.rossja.org

26 Окт 2006 Развернутое описание протоколов взаимодействия, на базе которых, на мой взгляд, должна создаваться распределенная блогосфера.

27 Окт 2006 Крик души на тему - сначала надо сделать блог, чтобы работал, а потом уже думать о p2p, DHT и прочих наворотах.

F2F сеть - P2P блоги, вики

Tue, 21 Nov 2006 13:17:31 GMT

Цель данного сообщества - объединить размышления русскоязычных пользователей LJ о P2P платформе для блогов, wiki и подобного. О технической стороне вопроса и разных преимуществах и недостатках подхода.
Конечная цель общения - разработка практически применимого и полезного ПО, соответствующих социальных правил/норм и процессов.