at_client_sdk: Dart Access to the Atsign Platform

What at_client_sdk Covers for Dart and Flutter

at_client_sdk is the main repository for libraries used to build applications on the Atsign Platform. It is aimed at developers who need to embed Atsign capabilities in Dart command-line applications, headless services, Internet-of-Things devices, and Flutter applications for mobile or desktop.

The repository separates its work into SDKs, reusable libraries, and Flutter widgets. That structure matters because an application does not need to treat every part of the repository as one undifferentiated package. The core `at_client` package owns the atSign lifecycle and returns an `AtClient` after operations such as `open`, activation, and enrollment. It also covers collections, synchronization, notifications, and encryption.

The Flutter layer is separate. `at_client_flutter` sits on top of `at_client` and adds onboarding and authentication dialogs plus device-keychain storage. Flutter web is explicitly not a supported target. For application teams, the repository is therefore both an SDK entry point and a collection of protocol, cryptography, configuration, and user-interface building blocks.

The at_client Lifecycle and Core Data Flow

The documented lifecycle starts by constructing an `Atsign` and opening or operating it through verbs that include `open`, `activate`, and `enroll`. These operations return an `AtClient`, which is the application-facing client used after the lifecycle step.

The repository documentation assigns several lower-level responsibilities to supporting packages. `at_auth` contains the protocol layer beneath lifecycle verbs, including CRAM activation, APKAM enrollment handshakes, `.atKeys` key stores, and the registrar client. `at_lookup` provides the low-level direct implementation of Atsign Protocol verbs and is used by `at_client` and `at_client_flutter`.

`at_chops` supplies cryptographic and hashing operations such as encryption, decryption, signing, and hashing, including post-quantum primitives. `at_commons` supplies shared types for keys, metadata, atSign validation, root-domain parsing, protocol verb builders, and exceptions. This division gives an application a path from lifecycle management to protocol operations and shared data types without requiring all of those layers to be implemented by the application itself.

The post-quantum capability is opt-in per client according to the README. The excerpt begins with a preference setting, but the repository excerpt does not provide the complete setting name or value, so the configuration cannot be reproduced safely from the available documentation.

Choosing at_client, at_auth, or at_client_flutter

Package selection is the first practical design decision. `at_client` is the platform-neutral Dart SDK and is the documented choice for command-line apps, headless services, and Internet-of-Things devices. An application that only needs Atsign lifecycle and data operations should start there unless its user experience requires Flutter-specific facilities.

`at_client_flutter` is not an independent replacement for the core client. The repository describes it as a Flutter layer on top of `at_client`, adding onboarding and authentication dialogs as well as device-keychain storage. Flutter applications should account for that dependency boundary when planning package versions and test coverage.

Other packages have narrower roles. `at_contact` persists contacts across different Atsign Platform applications. `at_policy` provides scaffolding for policy-management services that communicate with enforcement endpoints through the Atsign Protocol. `at_server_status` logs the status of a root server and an atServer for a selected atSign. `at_cli_commons` wraps flag parsing, key loading, and creation of an authenticated `AtClient`, which can reduce setup code for CLI or server programs.

The README also identifies several reusable Flutter feature packages, but it says most of the listed `at_*_flutter` packages are being deprecated in favor of adapting the example application at `packages/at_client_flutter/example/todos`. A Flutter package name should not be assumed to be the preferred starting point for a new feature.

Installation Path and First at_client Use

The repository README directs developers to `pub.dev` for packages published by `atsign.org`. It does not provide a complete installation command or dependency configuration snippet, so no install command can be copied from the README without guessing. The documented package source is the publisher page at `https://pub.dev/publishers/atsign.org/packages`.

The first lifecycle use described by the repository begins with `Atsign('@alice')`. The README states that `.open`, `.activate`, and `.enroll` return an `AtClient`. An application should therefore start by identifying which lifecycle operation it needs, obtain the resulting `AtClient`, and then build its data operations on that client.

The repository excerpt does not show the complete executable example, including imports, authentication input, enrollment state, or error handling. It also does not document a command for creating an atSign. For Flutter work, the repository gives a concrete starting point instead: read `packages/at_client_flutter/example/todos` and adapt it. The README recommends that example because most reusable `at_*_flutter` packages are being deprecated.

Flutter Support, Widget Deprecations, and Operational Limits

The strongest boundary stated by the repository is platform support. `at_client_flutter` is intended for mobile and desktop apps, while Flutter web is not supported. A team targeting the web therefore cannot treat the Flutter package as a general cross-platform solution based on the README.

There is also a migration boundary within the Flutter ecosystem. The README says most `at_*_flutter` packages are in the process of being deprecated. `at_common_flutter` is already deprecated in favor of `at_client_flutter`, `at_backupkey_flutter` is deprecated in favor of exporting keys with `FileAtKeysIo`, and `at_invitation_flutter` is deprecated in favor of `AtClientInvitations` in `at_client`. The packages may continue to publish until migration completes, but continued publication does not make them the recommended architecture for new work.

The README does not document rollback procedures, server provisioning, environment setup, or a complete configuration tutorial. It identifies registrar, activation, enrollment, and key-store responsibilities, but it does not state how an operator provisions those services. Those details must be checked in the package-specific documentation and relevant Atsign services before deployment.

Maintenance, Licensing, and Upgrade Surface

The repository is not archived, and its last push was on 2026-10-16. The README does not provide a separate maintenance policy. The listed releases are v3.0.77 dated 2024-07-31, v3.0.76 dated 2024-06-17, and v3.0.73 dated 2024-01-19. The gap between the recent push and the displayed release records means version selection and release contents should be checked directly rather than inferred from the latest listed release.

The repository uses the BSD-3-Clause license. Teams adopting the code must review the repository's `LICENSE` and any package-specific notices as part of their own compliance process. The README does not provide legal interpretation of the license, dependency obligations, or distribution requirements.

Upgrade cost is concentrated in package boundaries. The core lifecycle, protocol layer, cryptographic operations, Flutter layer, and feature widgets are separate packages. Changes in enrollment handshakes, `.atKeys` handling, registrar behavior, or deprecated widget packages can require more than a single dependency bump. The repository's organization gives a useful map for that review, but the README does not specify a compatibility matrix for the displayed releases.

Editorial conclusion

Adopt at_client_sdk when a Dart command-line program, headless service, Internet-of-Things device, or supported Flutter application must use Atsign Platform services without reimplementing the client lifecycle. Do not choose it for Flutter web, and verify package selection, platform support, key storage, enrollment requirements, and the deprecation status of individual Flutter packages before implementation. The repository's last push was on 2026-10-16, so its current code is recent, but release history listed in the repository includes v3.0.77 from 2024-07-31.

Frequently asked questions

Official sources

1. atsign-foundation/at_client_sdk on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases