@Piet I finally got to read the readme carefully. Looks good! Great job at readme-first development. Here are a few comments, but even if the comments aren't considered, you're already on a good track.

Set maximum number of peers to connect to.

It could be a problem that your sbot never connects to your very close friend because it's already connected to N other (not so close) friends. While in principle it sounds reasonable to limit the number of connected peers, we need to consider the corner cases. I'd say for now, use a very large max number, and then later we could discuss about this problem. Maybe Dominic finds some clever distributed algorithm in some paper, for this.

Provides a stream of peers with errors. Useful for another module to decide which peers should be forgotten and which could be retried occasionally with low priority.

This is very good! To me it's a new idea, I think it enables a lot of modularity.

Which led me to realize that perhaps this module could be split into a few modules. It's heading towards becoming a large and important module. I think we could identify an unopinionated core, made of connection tactics:

• Encapsulate the peers data structure (add/remove peer, set peer priority)
• Connect individually to peers (like current gossip plugin sbot.gossip.connect(peer))

Then have some other module made of connection strategies:

• With the API "startConnecting()" without specifying which peers
• With the API "startInitialSync()"

Hopefully modularizing like this will help to avoid making another monolith gossip plugin. Then it would be easy to maintain a simple core "connection plugin" and on top of that different plugins (each with different opinions) for managing multiple connections.