having preferences of plugins, e.g. wanting to interact with an ebt plugin, but falling back to legacy replication if no connection to an ebt plugin can be set up.

a depject approach could be more than just a dependency specification. rather than saying "i need plugin X", you say "i need interface X" or "i give interface X". we would have a defined set of core interfaces (the core API basically), like connection creator or connection manager or replication or whatever. defining these abstract interfaces will be non-trivial, but if we get our abstractions right then we can have situations where many plugins implement the same interface and we want the first one that works (e.g. legacyReplication and ebtReplication plugins both give replication service, we only need one), or where many plugins implement the same interface and you want all of them as a list (e.g. many connection creators: local network connections, bluetooth connections, pub connections, relay-p2p connections, dht-p2p connections, etc), or where many plugins implement the same interface and you want all of them combined as one (e.g. connection manager could be like this).