On Tue, 2019-12-17 at 18:56 +0000, Gix, Brian wrote: > Hi Michał, > > On Tue, 2019-12-17 at 19:47 +0100, Michał Lowas-Rzechonek wrote: > > On 12/17, Michał Lowas-Rzechonek wrote: > > > I would like to discuss possible solutions to this. > > > > > > One of the ideas is to give the application some time to successfully > > > Attach() itself to the new node, otherwise it gets removed. > > Not all nodes need to be attachable... For instance, a node that is only used for friendship, relaying or > beaconing can exist without ever being attached to... so requiring an Attach() shouldn't be a requirement. I think one piece of functionality that we have *not* yet tested is Node Reset. If a Config Client sends a Node Reset to an "Orphaned Node", using that nodes Device Key, the daemon should be cleaning up all of it's storage. > > > > Another possibility would be to remove "created but never attached" nodes on > > > daemon restart. > > > > Or maybe change the token flow a bit and instead of straight return, > > make the daemon call JoinComplete in all 3 cases, expecting a call > > return from the application? > > > > If JoinComplete call fails, node could be dropped. > > > > I think the Application does need to take responsibility for the token, once it receives it... If the call > (or > response) that delivers the token to the App fails, the node should be deleted, but the token is considered > sensitive enough that we lock down access to it as tight as possible. If it is inadvertantly leaked, then > whoever gets it has all the abilities of the node, so we minimize who sees it. > >
