Describe the bug
After CacheableSecondaryAddressFinder implementation, root server should be hit only once to fetch secondary address.
But currently there are many hits to root server since findSecondary in at_lookup creates a new instance of CacheableSecondaryAddressFinder.

To Reproduce
Steps to reproduce the behavior:

1. Create a sample at_client to execute any verb
2. Enable log level to finer
3. Check for this text in the client logs
   "AtLookup.findSecondary got answer:"
   This will occur multiple times which implies root server is hit more than once

Expected behavior
Root server should be hit only once to find the secondary url. Only if the address expires from cache, subsequent connection to root server should be made

Is your feature request related to a problem? Please describe.

See atsign-foundation/at_client_sdk#756 and #235

Describe the solution you'd like

Incorporate the signing library into the overall at_chops library

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

• Onboarding requires certain unnecessary parameters and also returns at_client instance which is not necessary
• No proper way to safely close/kill the onboarding_service instance
• No check to assert that provided downloadPath directory exists
• keys are updated into secondary first and then written into the file. In case writing to file fails, keys are updated to secondary but we do not have a copy of those keys as writing to file has failed
• fix the above issues and release a new version

Describe the solution you'd like

• Simplify the onboarding process by removing the involvement of at_client that removes the need for unnecessary onboarding preferences
• introduce a wrapper that serves as a simple activation tool accepting command-line args
• introduce a close method to safely kill the onboarding_service instance
• allow the passing of custom atKeys file name when activating an atsign(to generate atKeys file with custom name provide file name through atKeysFilePath instead of downloadPath)
• check: if downloadPath directory exists, create the directory if one does not already exist
• change in onboarding flow: first create atKeys file, then update keys to secondary. This way if the process fails mid-way we already have a persisted instance of the atKeys file

Is your feature request related to a problem? Please describe.
Update TLS connection to optionally output TLS keys to file. This allows you to "see" inside the TLS packets using WireShark and diagnose issues.

Describe the solution you'd like
Open to suggestions on implementation but it would be nice just to include a dev low level library that includes this feature. So testing can be done by including a dev library in pubspec.yaml. This would dump the TLS keys in the directory where the binary is being run.

The additional lines of code required to do this are :-

In at_lookup_impl.dart

      var secConConnect = SecurityContext();
       var keyfile = File('keysfile');
       secConConnect.setTrustedCertificates('caroot/rootcacert.pem');
      var secureSocket = await SecureSocket.connect(host, int.parse(port), context: secConConnect, keyLog: (line) => keyfile.writeAsStringSync(line, mode: FileMode.append));

And in monitor_client.dart

var secConConnect = SecurityContext();
       var keyfile = File('keysfile');
       secConConnect.setTrustedCertificates('caroot/rootcacert.pem');
      var secureSocket = await SecureSocket.connect(host, int.parse(port), context: secConConnect, keyLog: (line) => keyfile.writeAsStringSync(line, mode: FileMode.append));

replacing the secureSocket connection with no SecurityContent()

It would be nice to abstract the SecureSocket.connect so only one change would effect both lines of code and then that abstraction could be used in the secondary server code as well perhaps.

Describe alternatives you've considered
I did consider pushing all the way through via command line options or by adding a method options but that I think holds the danger of leaving it in place before going to a prod build.. But open to them or other ideas..

Additional context
Screen shot of the resulting Wireshark diagnostics

Describe the bug

The at_onboarding_cli functional_tests that are part of at_libraries GitHub actions are failing. Specifically, the test_for_env_readiness check is failing after retrying for 5 mins. This is causing the actions to terminate and abort after this test fails.

Steps to reproduce

1. Run GitHub actions in at_libraries
2. The at_onboarding_cli/functional_tests fail

Expected behavior

The actions and tests should successfully pass

Screenshots

Smartphones

No response

Were you using an atApplication when the bug was found?

No response

Additional context

Since the tests are not able to confirm the env readiness, the assumption is that the test secondaries are unavailable (or) the actions are unable to connect to the test secondaries.

Describe the bug

When sending an at_talk message from @atgps01 to @atgps02 messages never arrive. When running with -v the following message appears in the log:-

'SEVERE|2023-01-27 09:09:43.059190| atTalk |Invalid argument(s): Unsupported block type for private key: 17'

This was the first time that these two atSigns communicated. This issue does NOT happen everytime in fact I have not seen it at all with other atSigns communicating.

But I also see no way to correct the error from a dev point of view.

Steps to reproduce

1. First I run two at_talk commands to communicate between atgps01 and atgps02 then send message from atgps01
2. Message is never received
3. And then I run the same command but with -v and see the error message

Expected behavior

Never to have a miss managed key if that is what the issue is.

Screenshots

No response

Smartphones

code used is the nosync branch which uses the at_chops lib

https://github.com/atsign-foundation/at_talk/tree/nosync

Were you using an atApplication when the bug was found?

at_talk

Additional context

I was testing to ensure that newly created atSigns can communicate without a problem using chops and notification (this used to have other issues in that the RSA key was not in place)

Describe the bug
On pub.dev the Repository (GitHub) link points to https://github.com/michaelspiss/dart-utf7 rather than https://github.com/atsign-foundation/at_libraries/tree/trunk/dart_utf7

The usage example also imports the upstream utf7 rather than the at_utf7 (Null safety) fork.

Expected behavior

• directory should be named at_utf7 rather than dart_utf7 (fix this first)
• pub.dev should link back to this repo
• example should have correct import

Is your feature request related to a problem? Please describe.
As described in this document, there is an opportunity to provide an end-to-end encrypted, peer-to-peer, surveillance free notification service.

Describe the solution you'd like
The approach needs to be discussed in the architecture call.
Adding to the backlog so we can plan accordingly.

Describe alternatives you've considered
This could be accomplished as a widget only, but a library for sending notifications for IoT or other applications may also makes sense.

Describe the bug

• AtLookupImpl._process() does a few things - authenticates if necessary, sends a command, reads a response
• The intent is that all of that should happen as a single atomic group
• However there is no mutex guaranteeing that. As a result, for example, a caller can receive the response from a different request.

To Reproduce

• Have one piece of code for atSign_1 which is in a loop which calls AtClient.put() twice in rapid succession with two different keys, key1 and key2, which are sharedWith atSign_2, then waits for a second before doing it again
• Have another piece of code for atSign_2 which has subscribed to notifications, and in the notification callback calls AtClient.get() for whichever key (key1 or key2)

Expected behaviour

• No race condition

Fixed by #139

Is your feature request related to a problem? Please describe.
The current directory structure creates bad links on pub.dev for Example content.
For example, clicking on the example/at_server_status_example.dart link on the at_server_status Example tab returns a 404 response because it references the root of the at_libraries repo and not that of the package itself.

Describe the solution you'd like
Rumor has it that adding a "packages" subdirectory from root resolves this for pub.dev. We need to test and validate this is true and then add the subdirectory if it works.

Describe alternatives you've considered
The other option would be to create separate repos for each package that we want to publish to pub.dev

Additional context
Add any other context or screenshots about the feature request here.

• Right nav bar under documentation API Reference requires content review (samples and examples)
• Is documentation link pointing to the correct location?

Please check libraries link as well (current, samples and examples)
LIBRARIES

• at_server_status
• at_status_impl

• Right nav bar under documentation API Reference . Check for any missing documentation (samples and examples)
• Do we need a link for documentation?

Please review library links as well (current, samples and examples)
LIBRARIES

• at_lookup

Describe the bug
The latest version of at_lookup includes a line in at_lookup_impl.dart that prints outs the PKAM challenge signature to the console

To Reproduce
Steps to reproduce the behavior:

1. First I wrote a small onboarding cli app
2. Then I saw the signature printed to screen!
3. And then investigated why
4. Trunk does not have this bug so its been cleared up but the pub.dev lib has not been updated.
5. Needs to be

Expected behavior
No prints in production code

Screenshots
NA

Smartphone (please complete the following information):

• Dart/Flutter

Additional context
Add any other context about the problem here.

line 381 of at_lookup_impl.dart
print(signature);

Review at_contact readme package version (example the package version is 2.0.3, but the readme description says - dependencies: at_lookup: ^1.0.0)

• Action: remove this section from README and maybe add any other relevant information. We can remove the entire Installation section from README.

Describe the bug

• As part of the github action checks, unit tests are only running for at_lookup package (and only because I just added a job specifically for that)
• If I run the unit tests locally for at_contact, at_onboarding_cli and at_server_status, the tests do not all pass cleanly for any of those packages

Steps to reproduce

• Create a PR - unit tests will only run for at_lookup
• Run the unit tests for at_contact, at_onboarding_cli and at_server_status locally - no package will run green

Expected behavior

• All unit test packs should be run
• And they should all pass

Screenshots

No response

Smartphones

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Were you using an atApplication when the bug was found?

No response

Additional context

No response

Describe the bug

The client keeps waiting even after the getting server responses. This is an intermittent issue.

To Reproduce
Steps to reproduce the behavior:

1. First I '...'
2. Then I '...'
3. And then '...'

Expected behavior
The client should process the server responses.

Screenshots
If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

• Device: [e.g. iPhone11]
• OS: [e.g. iOS14.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 59]

Were you using an @‎application when the bug was found?

• [e.g. @‎buzz, @‎tmosphere]

Additional context
Add any other context about the problem here.

Describe the bug

Client will be able to call at_onboarding_service --> onboard multiple times.

First time onboard is called for an atsign, cram auth will be done to server and keys will be persisted to local secondary.

If client calls onboard again, with current logic cram will be unnecessarily attempted to server and would fail (cram secret will be deleted from secondary during first onboard)

Implement a method isOnboarded and check whether cram should be attempted to server.

Steps to reproduce

• call onboard multiple times from client app

Expected behavior

• cram should not be attempted again to server
• onboard method should return true if atsign is already onboarded
• _isAtsignOnboarded flag must be set based on whether keys are set in local secondary. Not based on cram auth result.

Screenshots

No response

Smartphones

No response

Were you using an atApplication when the bug was found?

No response

Additional context

No response

Describe the bug
If the authenticate(String? privateKey) in AtLookupImpl is called twice in quick succession, then the requests and responses for the two could become intermingled, whereas the expectation is that the entire authentication flow should complete atomically

Expected behavior

1. Employ a mutex, similar to how the _process method works
2. Within the critical section of code, add a check to begin with of the boolean which tells us whether the connection has already been authenticated should be

Unlist the following packages ~ @nickelskevin to provide further details

• at_server_status

Describe the solution you'd like

Per the guidance from dart-lang/lints:

in each pubspec.yaml:

-  pedantic: ^1.11.0
+  lints: ^1.0.1

and in each analysis_options.yaml:

-include: package:pedantic/analysis_options.yaml
+include: package:lints/recommended.yaml

Background:

I was writing documentation for sshnp on the dev site, then I realized the first step was to prepare two atSigns and their .atKeys files.

Getting the atSigns is the easy part, but for somebody who wants to use something like ssh no ports and want nothing to do with our apps or ecosystem, it may be hard for them to onboard their atSigns and generate the .atKeys files.

Problem:

For headless tools/systems like sshnp, there should be an easy way to generate the .atKeys files without having to write dart code or download our apps.

Proposal:

Using at_onboarding_cli, create a binary called "onboard."

./onboard <email> <atSign> // arguments can be figured out more in detail later

This binary could be released with the sshnp binaries, or just remain as a release or file in at_libraries/at_onboarding_cli

Random Ideas:

We could also have a register binary for skipping the atSign purchasing process altogether; the goal is for the person using sshnp to focus on using sshnp and not the atSign portion. (But if we want them to be involved in our atPlatform ecosystem, I could see why this is not an angle we want to take; but I believe we should make it easy for devs to use sshnp to avoid scaring them away, even if it means they don't know what an atSign really is)

The goal of having the register binary would be to steer them away from the complexities of what an "atSign" is. After all, the developers primary concern is to ssh without open ports and things would ideally just work.

Is your feature request related to a problem? Please describe.

I don't know if this is a feature already, but:

I'd like to import a base 64 encoded private/public rsa key manually.

If this is a feature, I wasn't able to find any documentation/examples easily in the readme and pub.dev

Describe the solution you'd like

Documentation on how to import keys in various ways for writing rsa decrypting/encrypting/signing/verifying code.

• reading .atKeys file
• manually hard coding the base64 encoded key strings

Describe alternatives you've considered

No response

Additional context

No response

Scores tab is missing follow documentation: (as of 8/4 error message on page - awaiting analysis to complete)

• provide documentation
• support multiple platforms

Review at_lookup readme package version (example the package version is 2.0.3, but the readme description says - dependencies: at_lookup: ^1.0.0)

• Action: remove this section from README and maybe add any other relevant information. We can remove the entire Installation section from README.

Review at_server_status readme package version (example the package version is 2.0.3, but the readme description says - dependencies: at_lookup: ^1.0.0)

• Action: remove this section from README and maybe add any other relevant information. We can remove the entire Installation section from README.

Is your feature request related to a problem? Please describe.

md5 is prone to collisions and should not be used.

Describe the solution you'd like

Change the algorithm to SHA512

Describe alternatives you've considered

No response

Additional context

No response

Unlist the following packages ~ @nickelskevin to provide further details

• at_contact

Scores tab all require documentation:

• provide documentation
• support multiple platforms

As discussed on Monday, June 21st in the Engg. stand, we dont want to duplicate information on the dev site. The best way to do it is to have one source of info either from Git or Pub.dev. We need a script that pulls the relevant info to the Dev site on a regular basis.

Is your feature request related to a problem? Please describe.

At the moment, users need to provide inputs for the following fields:

• isLocalSecondaryRequired
• commitLogPath
• hivePath
• downloadPath
• atKeysFilePath

Describe the solution you'd like

Instead of asking for the user's input for the above fields; use to default the path for all of these directories to HOME_DIRECTORY/.atsign. This would simplify the user experience and also make the behaviour uniform with all of the other atRepositories/tools.

Task Checklist

• Implementation
• Testing
• Update documentation
• Release

Describe the bug
During onboarding flow, AtLookup throws error

To Reproduce
Steps to reproduce the behavior:

1. First I installed both atmosphere-pro and wavi on iPad
2. Then I tried to onboard an atsign
3. Onboarding flow failed with CERTIFICATE issue

Expected behavior
Onboarding flow should work as on any other device

Screenshots

Smartphone (please complete the following information):
Device: iPad mini
OS version: 9.3.5

Were you using an @‎application when the bug was found?

• atmosphere-pro
• wavi

Additional context
Captured some more information via the dev tools and console.

The network calls:

App log:

Checking the secondary:

Support multiple platforms dropdown missing documentation for the following:

• Follow dart file conventions
• Support multiple platforms
• Pass static analysis

• Right nav review API reference missing documentation (samples and examples)
• Is the documentation link pointing to the correct location?

Please look at the library links too (current, samples and examples)
LIBRARIES

• at_contact

Pub.dev content and (source)s - CHECKLIST OF TO DO's BELOW

All the content shown on pub.dev and where it comes from.
Example: Shelf (will point to one of our own once completed)

• Package name, version <pubspec.yaml>

• Published date (generated)

• Platform support (generated based on project structure)

• Tabbed navigation

  • Readme (note: initial content comes from readme.md)
  • Changelog example: firebase_auth
  • Example (github repo)
  • Installing (generated)
  • Versions (generated) <pubspec.yaml>
  • Scores (generated)
  • **Admin (generated)
  • **Activity log (generated)

• Right column

  • Scores (generated)
  • Publisher (generated)
  • Metadata <pubspec.yaml description>
  • Homepage <pubspec.yaml>
  • Repository (generated)
  • View/report issues (generated)
  • Documentation (generated)
    • Documentation url <pubspec.yaml>
    • API reference
  • License (github repo)
  • Dependencies (generated)
  • More (generated)

All items to be completed:

• Package should be implemented with rSDK
• Include an example (sample) app based on at_app skeleton
• Add example.md to explain how to run the sample app
• Ensure the readme.md follows the best practice template (WIP)
• Make sure and add in terms that will help get this package to the top of the search results
• Update changelog.md with clear description of the update
• Bump the version as appropriate in pubspec.yaml for the package
• Bump the version as appropriate in pubspec.yaml for the example
• Check that the description is accurate in pubspec.yaml for the package
• As appropriate, add a documentation link to atsign.dev for the package

Describe the bug

Two minor issues, that should be corrected with a single update:

1. Link to example in README is to a branch on GitHub (rather than trunk), but it should probably be to the example tab in pub.dev anyway.
2. Metadata still refers to @ sign rather than atSign

Expected behavior

1. Example link should go to example tab in pub.dev
2. Use atSign in metadata

Below is a list of the issues and enhancements that have been identified while testing the most recent version of the Register CLI.

Issues

Bugs

• While running the tool from the code base, when my atSign was activating I saw multiple lines of "Connecting to secondary...." on attempt resulted in 14 lines of this and another attempt resulted in 100s of lines as this went on for a few minutes until I terminated it.
• If someone already has 10 free atSigns registered to their email and they try to get another one using the tool, it is displaying the correct message however it is then proceeding to throw an unhandled exception. Please proposed steps for handling this on page 2 of the wording doc [DONE]
• If someone runs the tool with an option that doesn't exist, eg -r, we are getting an unhandled exception. This should be handled in the same way as when someone runs the tool without entering any options. [DONE]
• If someone runs the tool with the correct -e option but no email address, we are getting an unhandled exception. This should be handled in the same way as when someone runs the tool without enter any options. [DONE]
• If someone runs the tool with the correct -e option but the email address is not in the correct format eg hhhhhhhhh, we are getting the correct message saying unable to run , you have entered an invalid email etc but then the tool proceeds to get an atSign and attempts to send the verification code to null and we get an unhandled exception. After displaying the unable to run Register Cli message, the tool should stop and prompt the person to enter their email address again [Action Required] Enter your email address: [DONE]

Wording/Visual

• After using the tool successfully the final log displayed after letting me know where my atKeys are stored says "SEVERE|2022-12-8 10:44:12.082697|OnboardingCli}Killing current instance of at_onboarding_cli". If this is meant to signify the successful end of the process then could we replace this with something a little friendlier? SEVERE implies something has gone wrong. Maybe [Information] Your atSign Registration has been completed.
• When asked to enter my verification code, if I press enter without typing anything it says "Enter you verification code", but it should be "Enter your verification code" [DONE]
• When it's activating the atSign it says "Activating you atSign: @tinashe404", but it should be "Activating your atSign: @tinashe404". This line also appears twice instead of only once.
• When generating the keys it says "Generating you encryption keys and .atKeys file", but it should be "Generating your encryption keys and .atKeys file"

Enhancements

• Provide the Register CLI in the form of a downloadable binary. I attempted to access it using "dart pub global..." and although activation was successful, I was not able to run it. I got "Could not find an option or flag -e" after running "dart pub global at_register -e myemailaddress"
• Since this tool will be used by the general public, we dont want them to have access to staging/dev and should therefore not give them the -n and --environment usage instructions [DONE]

Update Github documentation for to be unlisted pub.dev package at_contact.

Review at_contact readme.md, changelog.md and look for standard archetype template updates to make current. Repo will remain active even though it will be unlisted on Pub.dev.

• Review for current logo
• Add badging
• Does text body map to current standard archetype for consistency (dependency on archetype update)
• Update readme.md
• Update changelog.md

Is your feature request related to a problem? Please describe.

• Isolate cryptographic operations to a separate interface that can be reused

Describe the solution you'd like

• develop a new package at_chops (cryptographic and hashing operations)

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug
The key of concern public:publickey@atsign is being created with proper syntax while activating/onboarding but the key stored on the local secondary does not follow proper correct syntax which is being synced to the remote secondary.

To Reproduce
Steps to reproduce the behavior:

1. Use at_onboarding_cli to activate an atsign.
2. Look at the logs. One can observe that public:publickey is overwriting public:publickey@atsign and is being synced to remote_secondary where the prior syntax is wrong.

Expected behaviour

1. Either the update from local secondary concerning public:publickey should append the current atsign at the end.
2. The other alternative is that public:publickey should not be synced from local secondary to remote secondary.

Device (please complete the following information):

• Laptop running Ubuntu 22.04 LTS.

Were you using an @‎application when the bug was found?

• NA (since this a command-line interface it will be run on the Linux Terminal)

Additional context
For more context please refer to atsign-foundation/at_server#820.

Tasks:

• Investigate why this issue is only being encountered now (what changed in the working of dependencies that is triggering this issue).
• Correct the syntax that the CLI used to persist keys to local secondary.

Describe the bug

When a timeout exception is thrown by the OutboundMessageListener when waiting for responses from the server, it calls async method _closeConnection - but without using await. As a result, the exception is thrown before the OutboundConnection is closed and marked as inValid. And a result of that, code which immediately tries to reissue whatever command timed out may result in AtLookupImpl's check of OutboundConnection isInvalid() returning true, and therefore result in AtLookupImpl's writing to a connection with a dead socket, and hanging for a very long period of time as a result.

Steps to reproduce

Race condition, very difficult to reproduce except via unit tests, which is what #251 largely consists of, to prevent regression

Expected behavior

After a timeout exception, the connection should be recreated before AtLookupImpl executes any other command

Screenshots

No response

Smartphones

No response

Were you using an atApplication when the bug was found?

No response

Additional context

No response

• Change the current @developer logo to @ dev to make it consistent across Github
• 'Now for a little internet optimism' needs to change to whatever we decide is our new tagline for messaging
• Revisit descriptions across libraries - see if it makes sense to use @protocol vs. @platform

Update Github documentation for to be unlisted pub.dev package at_server_status.

Review at_server_status readme.md, changelog.md and look for standard archetype template updates to make current. Repo will remain active even though it will be unlisted on Pub.dev.

• Review for current logo
• Add badging
• Does text body map to current standard archetype for consistency (dependency on archetype update)
• Update readme.md
• Update changelog.md

People have noticed that their contacts are not consistent across the apps.

Examples of the issue:

1. On a new atsign, someone added contacts into @Mosphere pro. The contacts appeared in @buzz but they did not appear in @Mosphere or @rrive
2. Has contacts in @Mosphere but had to add them all individually into @Mosphere pro using the same atsign

Expected behavior
The contacts should be sync'd across the apps

Smartphone:
Reported on iphones

Were you using an @Application when the bug was found?
@buzz, @rrive, @Mosphere, @Mosphere pro

Is your feature request related to a problem? Please describe.
A library which implements the design which was worked on during PR46, to enable easy addition of cryptographic signatures to AtData as well as to ad-hoc data, and easy verification of those signatures.

Describe the solution you'd like
Design a tool that accepts AtValue and necessary keys and digitally signs and returns the AtValue. Similarly, the tool should also provide a way to verify this previously created signature. The digitally signing and then the signature verification should be built on an asymmetric encryption architecture

Additional context

• More details in https://github.com/atsign-company/google-travelers-workshops/issues/1
• This library will be taken up in the POC once complete. See atsign-foundation/at_client_sdk#735

Further tasks

• - testing the implementation thoroughly
• - unit tests
• - readme and other documentation
• - publish at_commons with data_signing

LInk to issue https://github.com/atsign-company/google-travelers-workshops/issues/42

Summary

Now that auto activation is a feature in the registrar, sometimes activating the atSign will take a while. Code may go straight to onboard() with the cram key however the secondary address is not initialized. This may become a problem if CLI code tries to onboard too quickly.

Steps to reproduce

1. Activate an unactivated atSign via the web API
2. Web API will give you a cram key, but the secondary address is still null.
3. Try to onboard immediately upon receiving the cram key
4. You will receive a secondary not found because the atSign's secondary was not initialized quickly enough

Hotfix

Simply pause your code until the secondary address can be found.

/// Hot fix in case activating the atSign takes too long (if the person does not press the orange "Activate" button on their atSign, then the secondary was not initialized just yet. Just run this method with async/await and it will pause your code until the secondary is successfully initialized.)
  Future<void> runUntilSecondaryExists(String rootUrl, String atSign, {timeoutIterations = 10000000}) async {
  List<String> s = rootUrl.split(':');
    String rootDomain = s[0];
    int rootPort = int.parse(s[1]);
    late SecondaryAddress sAddress;
    bool exists = false;
    int timeout = timeoutIterations;
    int count = 0;
    do {
      count++;
      try {
        sAddress = await CacheableSecondaryAddressFinder(rootDomain, rootPort).findSecondary(atSign);
        exists = true;
      } catch (e) {
        // ignore
      }

    } while(!exists && count < timeout); 
    if(sAddress.host.length > 2) {
      print('Secondary address found! ${sAddress.host}:${sAddress.port} | Iterations: $count/$timeout');
    } else {
      print('Secondary address not found after $count/$timeout iterations');
    }
    throw Exception('Secondary address not found after $count/$timeout iterations');
  }

Hotfix use example:

// 1. 
// get the cram key from via the web api 
// (will actually give a non-null valid cramkey despite secondaryUrl not addressable).
String? cram = await apiUtil.authenticateAtSignValidate(atSign, otp);

// 2. 
// pause code until secondaryUrl is addressable
await apiUtil.runUntilSecondaryExists(rootUrl, atSign);

// 3. 
// onboard with the cram key (this function ultimately looks for secondaryUrl.. 
// if the pause code above were to be excluded, then it would immediately jump 
// into this code block and look for a non-existent secondaryUrl).
bool onboarded = await onboard(atSign, rootUrl, cram);

Describe the bug

When using

var onboard = await onboardingService.authenticate();

My expected result was true if onboarded and false if the onboarding fails. But if there is for example no Internet connection then this call hangs and does not return or throw an exception. If the Internet comes back online then the onboarding seems to continue, but this await never returns true.

Steps to reproduce

1. First I set up a VM that I can console into (so dropping the internet does not cut me off!)
2. Then switch off the connection to the Internet
3. And then run att_talk or similar that uses the var onboard = await onboardingService.authenticate(); call
4. Watch the logs and see the call is hung
5. Bring back the Internet connection and see a partial recovery but the var onboard = await onboardingService.authenticate(); never returns the future

Expected behavior

Expected that a false would return if the onboarding fails for some reason (e.g. secondary lookup fails or network check fails). Or perhaps an exception to be thrown ?

Either would be fine but a hang is problematic

Screenshots

Smartphones

-Linux Dart
2.17.6

Were you using an atApplication when the bug was found?

at_talk - branch nosync

Additional context

No response

Describe the bug
If a device is offline then at_lookup can cause the application to crash rather than wait for connectivity to come back. Looks to be a failure in name lookup in this case but if the network is down nothing @ should crash it should wait until network is available..

To Reproduce
Steps to reproduce the behavior:

1. Create a small app that connects to a secondary (ColinSnippets/ssh_control works)
2. Then run the program whilst having no network connection
3. And then watch

Expected behavior
@ apps should never crash and should handle being offline gracefully and reconnect when possible

Screenshots

pi@raspberrypi:~/Colin-snippets/ssh_control $ bin/ssh_control
initializing storage
INFO|2022-03-31 03:00:52.990549|HiveBase|commit_log_f15959d1046b21a3e727245571dcd5c697956835e967a0a273db44d5681ac682 initialized suc
cessfully

AtServer.getHiveSecretFromFile file found
INFO|2022-03-31 03:00:53.003552|HiveBase|f15959d1046b21a3e727245571dcd5c697956835e967a0a273db44d5681ac682 initialized successfully

SEVERE|2022-03-31 03:00:53.016314|AtLookup|AtLookup.findSecondary connection to root.atsign.org exception: SocketException: Failed h
ost lookup: 'root.atsign.org' (OS Error: Temporary failure in name resolution, errno = -3)

Unhandled exception:
Exception: Secondary server not found
#0      AtLookupImpl.createConnection (package:at_lookup/src/at_lookup_impl.dart:270)
<asynchronous suspension>
#1      AtLookupImpl._sendCommand (package:at_lookup/src/at_lookup_impl.dart:550)
<asynchronous suspension>
#2      AtLookupImpl.authenticate (package:at_lookup/src/at_lookup_impl.dart:415)
<asynchronous suspension>
#3      AtOnboardingServiceImpl.authenticate (package:at_onboarding_cli/src/at_onboarding_service_impl.dart:187)
<asynchronous suspension>
#4      main (file:///home/pi/Colin-snippets/ssh_control/bin/ssh_control.dart:29)
<asynchronous suspension>
pi@raspberrypi:~/Colin-snippets/ssh_control $

Additional context
This is critically important for IoT use cases and also for mobile apps