Думал я на эту тему... глядь, а у Вас уже все продумано :)
Я бы, правда, кое-что предложил сделать чуть иначе:
1) Все-таки видел бы такую сеть чуть больше как организацию (с участниками и правилами), чем как набор протоколов. В частности, мне кажется целесообразным иметь в ней адресацию по идентификаторам, а не по самим ключам (как это сейчас сделано для обычных веб-адресов) - и центральный реестр таких идентификаторов. При этом реальное опознание участников делать через ключи - а реестр должен просто удостоверять, что данному имени сопоставлен данный открытый ключ. Тогда в сети можно ввести сплошную "человекопонятную" адресацию; можно заменять ключи в случае их утери - например, при условии, что замену ключа признает две трети ранее зарегистрированных френдов данного растяпы... или по предьявлении второго ключа, созданного одновременно с первым - и который используется только при общении с реестром и потому его сложнее украсть... Но главное, ИМХО, что адресация будет проще. Злоупотребления держателя реестра, ИМХО, маловероятны - особенно если (равноправных) копий реестра будет несколько.
2) ИМХО, нельзя полагаться на естественное дублирование контента через узлы публикации френдов. Оно будет работать только для свежей части ленты - а чужие архивы без необходимости у себя никто хранить не будет. Система получается уязвимой - удар по одному узлу не помешает распространению свежих порций, но может безвозвратно угробить архивы. Можно было бы сделать так: транспорт между узлами публикации организовать как многосвязный граф, в котором каждый узел связан с несколькими соседними (скажем, от десятка до трех десятков, как договорятся) - и по полиси каждый узел обязан полностью дублировать контент со всех напрямую связанных с ним узлов. Вот такую штуку разрушить будет уже очень тяжело... и положить будет практически невозможно - поскольку каждый узел принимает запросы только от своих постоянных соседей. А схему роутинга можно считать хоть на узлах, хоть на выделенных серверах - как кому удобнее. И, для полного счастья, некоторые узлы публикации могут находиться в тор-сети. Получим стопроцентную неподцензурность и абузоустойчивость.
3) Я бы постарался на первом уровне разработки протокола - абстрагироваться от структуры блогового контента (постинги, комментарии etc.); предположим, что узел публикации раздает абстрактную последовательность xml-документов, каждый из которых имеет уникальный адрес (в потоке данных данного публикатора). А как их интерпретировать, после получения и расшифровки - должно решаться уже на следующем уровне. Дело в том, что такая система прекрасно подходит не только для блогов - но, например, для организации абузоустойчивых литбиблиотек, бессерверных торрент-сетей; может быть, сетей распределенного семантического поиска, может быть, даже для обычной интернет-коммерции - есть у нее некоторые преимущества перед простым вебом... Но, конечно, для различных неблоговых надобностей структура xml должна быть разной. И нужно продумать организацию адресного пространства внутри потока данных пользователя - скажем, зарезервировать в ней "статическую" область, адреса в которой предназначены для целей, определяемых протоколами следующего уровня - ну и для нужд описанного уровня тоже (список френдов с правами, насколько я понимаю).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2007-12-13 06:27 pm (UTC)Я бы, правда, кое-что предложил сделать чуть иначе:
1) Все-таки видел бы такую сеть чуть больше как организацию (с участниками и правилами), чем как набор протоколов. В частности, мне кажется целесообразным иметь в ней адресацию по идентификаторам, а не по самим ключам (как это сейчас сделано для обычных веб-адресов) - и центральный реестр таких идентификаторов. При этом реальное опознание участников делать через ключи - а реестр должен просто удостоверять, что данному имени сопоставлен данный открытый ключ. Тогда в сети можно ввести сплошную "человекопонятную" адресацию; можно заменять ключи в случае их утери - например, при условии, что замену ключа признает две трети ранее зарегистрированных френдов данного растяпы... или по предьявлении второго ключа, созданного одновременно с первым - и который используется только при общении с реестром и потому его сложнее украсть... Но главное, ИМХО, что адресация будет проще. Злоупотребления держателя реестра, ИМХО, маловероятны - особенно если (равноправных) копий реестра будет несколько.
2) ИМХО, нельзя полагаться на естественное дублирование контента через узлы публикации френдов. Оно будет работать только для свежей части ленты - а чужие архивы без необходимости у себя никто хранить не будет. Система получается уязвимой - удар по одному узлу не помешает распространению свежих порций, но может безвозвратно угробить архивы. Можно было бы сделать так: транспорт между узлами публикации организовать как многосвязный граф, в котором каждый узел связан с несколькими соседними (скажем, от десятка до трех десятков, как договорятся) - и по полиси каждый узел обязан полностью дублировать контент со всех напрямую связанных с ним узлов. Вот такую штуку разрушить будет уже очень тяжело... и положить будет практически невозможно - поскольку каждый узел принимает запросы только от своих постоянных соседей. А схему роутинга можно считать хоть на узлах, хоть на выделенных серверах - как кому удобнее. И, для полного счастья, некоторые узлы публикации могут находиться в тор-сети. Получим стопроцентную неподцензурность и абузоустойчивость.
3) Я бы постарался на первом уровне разработки протокола - абстрагироваться от структуры блогового контента (постинги, комментарии etc.); предположим, что узел публикации раздает абстрактную последовательность xml-документов, каждый из которых имеет уникальный адрес (в потоке данных данного публикатора). А как их интерпретировать, после получения и расшифровки - должно решаться уже на следующем уровне. Дело в том, что такая система прекрасно подходит не только для блогов - но, например, для организации абузоустойчивых литбиблиотек, бессерверных торрент-сетей; может быть, сетей распределенного семантического поиска, может быть, даже для обычной интернет-коммерции - есть у нее некоторые преимущества перед простым вебом... Но, конечно, для различных неблоговых надобностей структура xml должна быть разной. И нужно продумать организацию адресного пространства внутри потока данных пользователя - скажем, зарезервировать в ней "статическую" область, адреса в которой предназначены для целей, определяемых протоколами следующего уровня - ну и для нужд описанного уровня тоже (список френдов с правами, насколько я понимаю).