You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A partial solution to eliminate the need of restarting the Node while Generating/Recovering Wallets during the Node startup is to redefine the trigger of the startup of Neighborhood and Accountant.
This could be achieved using an already in use message called StartMessage.
This message is used for two unrelated purposes.
After the ActorSystemFactory has finished binding all the Actors with BindMessage,
it sends a StartMessage to the Neighborhood so that it can start trying to connect the new Node
to the Network.
After the Neighborhood is successfully connected to the Network well enough to begin
routing messages, the Neighborhood sends another StartMessage to the Accountant, which uses
the StartMessage as a signal to begin running its regular scans.
These sequence of events can be understood as:
ActorSystemFactory -> Neighborhood -> Accountant
We can modify this sequence of events so that the ActorSystemFactory sends a message to the Configurator, and then the Configurator sends another message to the Accountant.
This sequencing allows the Configurator to verify whether wallets are present or not.
The Configurator performs this check using information provided by BootstrapperConfig. Here’s how it works:
BootstrapperConfig prepares ConfiguratorConfig, indicating whether wallets are present or not.
If wallets are present in the ConfiguratorConfig, the Configurator immediately sends a message to the Neighborhood upon receiving the StartMessage. If wallets are not present, it notifies the user to generate/recover wallets and waits for the user to complete this action.
Note: There's another idea that we haven't discussed much about. It involves building a separate utility to generate/recover wallet.
The text was updated successfully, but these errors were encountered:
I do root for what was roughed out in the premier comment. (Maybe because I was leading the effort to design it this way - look at it, what an awesome example of human vanity haha)
Back to work...
I'm here as I just brushed some of these thoughts off and on my journey seeking this card I stumbled a couple of times over some other cards at least distantly resembling these. And so I'd like to mention them:
A partial solution to eliminate the need of restarting the Node while Generating/Recovering Wallets during the Node startup is to redefine the trigger of the startup of
Neighborhood
andAccountant
.This could be achieved using an already in use message called
StartMessage
.This message is used for two unrelated purposes.
ActorSystemFactory
has finished binding all the Actors withBindMessage
,it sends a
StartMessage
to theNeighborhood
so that it can start trying to connect the new Nodeto the Network.
Neighborhood
is successfully connected to the Network well enough to beginrouting messages, the
Neighborhood
sends anotherStartMessage
to theAccountant
, which usesthe StartMessage as a signal to begin running its regular scans.
These sequence of events can be understood as:
We can modify this sequence of events so that the ActorSystemFactory sends a message to the Configurator, and then the Configurator sends another message to the Accountant.
This sequencing allows the Configurator to verify whether wallets are present or not.
The new sequence of events can be understood as:
The Configurator performs this check using information provided by
BootstrapperConfig
. Here’s how it works:BootstrapperConfig
preparesConfiguratorConfig
, indicating whether wallets are present or not.ConfiguratorConfig
, the Configurator immediately sends a message to theNeighborhood
upon receiving theStartMessage
. If wallets are not present, it notifies the user to generate/recover wallets and waits for the user to complete this action.Note: There's another idea that we haven't discussed much about. It involves building a separate utility to generate/recover wallet.
The text was updated successfully, but these errors were encountered: