diff --git a/Design:-Enhancements-to-Split-Join-nodes.md b/Design:-Enhancements-to-Split-Join-nodes.md
index 11339db..9b2769a 100644
--- a/Design:-Enhancements-to-Split-Join-nodes.md
+++ b/Design:-Enhancements-to-Split-Join-nodes.md
@@ -6,10 +6,12 @@ The Split can handle Strings, Arrays, or Objects - and returns one msg for each
 The Split node takes a single message and (currently) creates multiple messages. 
 *Note* - currently that is the simple way to think of it... 1 in multiple out...
 
+
 #### Proposal 1
 
 Add support for Buffers to be split - let the split "target" be able to be specified as an array format - eg ["0x02","0xf2"] sort of thing (that is itself then parsed into a buffer) to use with buffer.indexOf...
 
+*implemented in enhanced split/join branch* - Add ability to split a binary buffer object on a char or another buffer (specified by and array or string as above) - Keeps any remainder left over for next packet to arrive . As a result it can't provide a total number of parts in advance, but can provide a count. Provides a count when there is zero remainder.
 
 ### Join Node
 
@@ -49,17 +51,21 @@ In addition if a msg does arrive with a `msg.completed` property - then the accu
 ### Proposal 1b - Accumulate key/value pairs mode
 Similar in to proposal 1, this should also be the equivalent but for the **key/value** mode of operation - ie allow use of a msg property (like the topic) to create the properties - this would be even simpler than Proposal 1a above for use with UI nodes, and general msgs that just have a topic and payload (for example MQTT inputs)
 
-### Potential implementation
+### Potential implementation 
+
 These could be implemented, 
  - either as stand alone modes of operation. IE Accumulate objects and Accumulate key/value pairs. (see below)
  - or as a sub mode of the exiting modes - for example by allowing a "special" use of a count of zero inputs to indicate "infinite" (ie send every time).
 
+Currently the first of these is implemented in enhanced split/join branch. (IE separate discrete mode of operation)
+
 ![](http://g.recordit.co/SQMEE8pJmD.gif)
 
 ### Proposal 2
 
-In the **key/value** mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same).
+In the **key/value** mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same).  *implemented in enhanced split/join branch*
 
 ### Proposal 3
 
-Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here.
\ No newline at end of file
+Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here.
+*implemented in 0.17 branch - as it was this that exposed the dashboard namespace issue*
\ No newline at end of file