https://www.ics.uci.edu/~eppstein/pubs/EppGooUye-SIGCOMM-11.pdf
это как раз про наш случай.

а merge это просто добавление диффа или там какая-то сортировка происходит?
btw, пулл вытягивает всю эху целиком или все-таки инкрементально?

btw, offtop - этот кодстайл меня убивает. я многое могу простить, но не среднюю длину переменной в три буквы.

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

это я по аналогии с гитом.
ладно, проехали, это я глупость сказал.

Видится мне в этом грядущая проблема с длинными эхами. В поиске диффа между эхами на разных нодах, например.

requests умеет оба.

>большие эхи надо делить
как их предполагается делить "на лету"? И на ком будет за это отвечать - тоссер?

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

> юзеры. пишут, пишут, потом бах - а пойдёмте все в эху "новый префикс"
постфикс, ты хотел сказать.
в этом меня смущает следующий момент - нод-опам придется постоянно обновлять списки обрабатываемых эх. следовательно, на мой взгляд, нужны какие-то методы их автообновления, замены старых эх новыми.

> то, что я тут собрал, мне нравится
мне нравится общая идея, но не очень нравится реализация.
и вот как раз в тему - какой ты видишь модель распространения изменений(новых сообщений)? я не был в фидо, так что могу не знать чего-то, что тебе кажется очевидным и общеизвестным.
так вот, я вижу навскидку два основных варианта, назовем их "каскад" и "меш".
"каскад" - организованный вариант: для каждой эхи есть группа нод N1, N2, ..., NK, которые можно назвать корневыми. ноды второго уровня, например, N11 и N21, которые знают, что эту эху нужно и пуллить, и пушить в/из N1 и N2 соответственно. ноды третьего уровня делают аналогичное с нодами второго уровня, etc.
то есть, для каждой эхи нода, кроме корневой, знает, куда пушить и откуда пуллить новые сообщения, а корневые ноды объединены в пуш- или пулл-кольцо. в этом случае достаточно легко минимизировать траффик внутри сети.

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

впрочем, это очевидный оверкилл. хотя очень интересно, очень.

эээ. где у тебя 9кб гет-запроса? Оо

> у нас тут сейчас всё на get-запросах - отправка сообщения это тоже такой большой get-запрос
ой, как печально. ну пост же для этого придумали. =)

> requests, смотрю, это внешняя библиотека.
pure python, в т.ч. зависимости, apache2 license, 625kb wheel со всеми зависимостями. полагаю, что работает.

у меня сердце кровью обливается. ну nih-синдром же во все поля.
вот что стоило взять нормальный markdown, в который можно запилить своих обработчиков к тому же, и который нормально читается даже в тексте?..
и, например, стандартный multipart/form-data как вариант для сообщений с аттачами, который и в консоли распаковывается без особых проблем
ну или вот абсолютно фиксированный формат сообщения - почему было не взять привычные http-like заголовки?.. просто и расширяемо же.

моя не понимать.

> небонные эхи
это типа очень локальные?