integrate more feedback.

ROADMAP.md

@@ -18,7 +18,9 @@ leverage the vast ecosystem of go-libp2p modules.
 By running a *single instance* of the daemon per machine, co-local applications
 can leverage the libp2p stack to communicate with peers, interact with the DHT,
 multiplex protocols, etc. no matter the language they are developed in, nor
-whether a native libp2p implementation exists in that language.
+whether a native libp2p implementation exists in that language. Running
+*multiple instances* of the daemon is also possible, and specially useful for
+testing purposes.
 
 When establishing connections, the daemon handles transport selection, security
 negotiation, and protocol and stream multiplexing. Streams are mapped 1:1 to
@@ -54,6 +56,8 @@ please open a [Github issue](https://github.com/libp2p/go-libp2p-daemon/issues).
 - 🚧 Subsystem: DHT interactions.
 - 🚧 Subsystem: Pubsub interactions.
 - Subsystem: Circuit relay support.
+- Subsystem: Peerstore operations.
+- Connection notifications.
 - Enabling interoperability testing between libp2p implementations.
 - Go binding.
 - Python binding.
@@ -66,8 +70,8 @@ please open a [Github issue](https://github.com/libp2p/go-libp2p-daemon/issues).
 - Multi-tenancy, one application = one identity = one peer ID.
 - app <> daemon isolation; trust-less scenario; programs should not be able to 
   interfere or spy on streams owned by others.
-- Shared-memory local transport between apps and the daemon: more efficient 
-  than unix sockets.
+- Shared-memory local transport between apps and the daemon: potentially more
+  efficient than unix sockets.
 - Extracting local transports as go-libp2p transports.
 - Allowing "blessed" applications to act on behalf of the daemon.
 - Global services implemented in the user space.