Какой универсальный API должен быть у P2P библиотеки?

Блокчейн не имеет отношения к p2p

Блокчейн не имеет отношения к p2p

А кто говорил, что имеет? А для _распределенного_ блокчейна P2P (в какой-то форме) понадобится.

«Какой универсальный API должен быть у Internet-библиотеки?» — вопрос где-то из этой области :)

P2P бывают совершенно разными, с разными целями и функционалом.

Какие функции и реализуемые юзкейсы должны быть в generic P2P API?

в общем случае достаточно апи адресации и отправки «надежных» (ха ха насколько это можно) но медленных сообщений, и ненадежных но быстрых сообщений,

можно прикрутить распределенную хеш таблицу (в рамках всей сети) + заодно подумать как распределено хранить данные пира

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

Какие функции и реализуемые юзкейсы должны быть в generic P2P API?

1) Массовые сообщения для всех

Сообщения для всего окружающего роя. В них указан только источник и данные. Это могут быть поисковые запросы или уведомления о подключении/отключении. Для ограничения флуда применять параметр «глубина», при отхождении на шаг от источника, уменьшать глубину, и так до нулевой глубины. Также рассылать массовые сообщения только от доверенных по веткам доверия с «положительными» узлами.

2) Сообщение заданному абоненту через массы

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

3) Сообщение заданному абоненту через определенн(ого,ых) сосед(а,ей)

Если известно за какими соседями стоит искомый адресат, то можно слать только через этих соседей, а не через всех соседей. Т.е. это как бы ограниченный второй метод. Для его хорошей работы узлы должны строить таблицы маршрутов на основе сообщений 1-го и 2-го типов. И уже адресные сообщения слать согласно этим маршрутам.

4) Прямое подключение и обмен

Возможно только при известном физическом адресе абонента. Любая p2p-сеть начинается с инициализации некоторого количества именно таких прямых соединений (выше я их назвал соседями).

На базе этих 4х методов коммуникации (которые могут содержать: запрос, ответ, уведомление, медиапакет) можно построить p2p-сеть любого назначения.

Кое-что есть в документации к Пандоре, к-ю я пишу несколько лет (как минимум с 2012 года):
https://github.com/Novator/Pandora/tree/master/doc
например: https://github.com/Novator/Pandora/raw/master/doc/guide.ru.pdf

универсальный API должен быть у P2P библиотеки?

3) Сообщение заданному абоненту через определенн(ого,ых) сосед(а,ей)

API

API

или клиенты библиотеки должны таблицу маршрутизации составлять и минимальное дерево покрытия сети строить?

3) ... Для его хорошей работы узлы должны строить таблицы маршрутов на основе сообщений 1-го и 2-го типов.

ок, раз ты не понял разжую вопрос: «клиенты библиотеки» или «сама библиотека»

Спасибо, есть над чем подумать.