Refine motivation

Signed-off-by: Alexander Simmerl <a.simmerl@gmail.com>
radicle-dev · Jun 15, 2021 · 5059870 · 5059870
1 parent 39f4a70
commit 5059870
Showing 1 changed file with 16 additions and 12 deletions.
diff --git a/docs/rfc/0696-p2p-node.adoc b/docs/rfc/0696-p2p-node.adoc
@@ -13,18 +13,17 @@
 
 == Motivation
 
-So far long-running binaries running a link p2p daemon came in two
+So far long-running binaries providing a link p2p daemon came in two
 incarnations, the *radicle-upstream* proxy and the *radicle-bins* seed node.
 With the former being the main subject of experimentation of higher-level
-non-core protocols (e.g. requesting new identities on the network)  it also
-developed into a monolith due to its locality close to the upstream project and
-a constant push to reflect highly specific product needs to drive the UI. While
-beneficial to validate the feasibility of the general ideas of the link
-protocol it now presents the reality that there is no simple way to run the link
-p2p stack without the idiosyncrasies of the application specific proxy. This is
-a massive hindrance for further adoption and recomposition in other contexts and
-needs to be addressed to enable the development of a healthy ecosystem, esp. for
-clients.
+non-core protocols (e.g. requesting new identities on the network) it developed
+into a monolith due to its locality close to the upstream project and a constant
+push to reflect highly specific product needs to drive the UI. While beneficial
+to validate the feasibility of the general ideas of the link protocol it now
+presents the reality that there is no simple way to run the link p2p stack
+without the idiosyncrasies of the application specific proxy. This is a massive
+hindrance for further adoption and recomposition in other contexts and needs to
+be addressed to enable the development of a healthy ecosystem.
 
 == Overview
 
@@ -35,8 +34,9 @@ it tries to prove that all daemons are made equal and only distinct with regards
 to the configuration given (e.g. tracking behaviour) and lifetime of the process
 (i.e. socket-activated or long-running).
 
-Furthermore it presents possible approaches to drive the *PubSub* part of the
-new architecture.
+It also strives to recommend APIs and mechanisms - in the form of non-core
+protocols - which remove the need for online requests made by clients to a
+running node.
 
 == Terminology and Conventions
 
@@ -162,6 +162,10 @@ peer-id: bstr
 port: uint
 ----
 
+== Protocols
+
+_TODO_
+
 == PubSub
 
 _TODO_