DOCSEARCHbyAlgolia
Submit Docs

at_client_sdk

repository·trunk·Indexed 23 days ago

https://github.com/atsign-foundation/at_client_sdk

Central repository for building applications on the Atsign Platform. It provides Dart SDKs, foundational libraries, and Flutter-specific components for secure, decentralized communication and identity. Key packages include at_auth for onboarding and authentication, at_chat_flutter for chat UI components, and at_chops for cryptographic key generation and encryption (AES, RSA, X25519, ML-KEM, ML-DSA, and X-Wing).

Tokens
103.7K
Snippets
187
Records
474
Agent score
77%

What's inside at_client_sdk

  1. Overview of at_client_sdk components

    trunk

    The at_client_sdk repository contains the core building blocks for developing applications on the Atsign Platform. It is organized into three main categories:

    1. SDKs

    • at_client: A platform-neutral Dart SDK designed for command-line applications, headless services, and IoT devices.
    • at_client_flutter: A Flutter layer built on top of at_client for mobile and desktop applications. It provides onboarding/authentication dialogs and device-keychain storage. Note: Flutter web is not supported.

    2. Libraries

    Foundational Dart libraries published on pub.dev. Key libraries include:

    • at_auth: Core logic for onboarding, authentication, and APKAM enrollment.
    • at_chops: Cryptographic operations (encryption, decryption, signing, hashing).
    • at_commons: Foundational types (keys, metadata, atSign validation, protocol verb builders).
    • at_contact: Persistent contact management across applications.
    • at_cli_commons: Helpers for Dart CLI/server programs to reduce boilerplate when loading keys and authenticating AtClient instances.
    • at_onboarding_cli: Tooling for registering and enrolling atSigns, ideal for headless/IoT use cases.

    3. Flutter Packages

    UI components and feature-specific widgets. Important Migration Note: Most at_*_flutter packages are being deprecated. Instead of using individual widget packages, the recommended approach for new Flutter development is to adapt the code from the official example application: packages/at_client_flutter/examples/todos.

  2. Introduction to at_policy

    trunk

    The at_policy library provides generic scaffolding for building policy management services. These services are designed to communicate with policy enforcement endpoints via the Atsign Protocol. By using this library, your policy management services inherit the core benefits of the Atsign Protocol:

    • Outbound communication only: Simplifies network configuration and enhances security.
    • End-to-end encryption: Ensures data privacy between the management service and enforcement endpoints.
    • atSign addressing: Uses atSigns for identity and routing instead of traditional IP addresses.

  4. Overview of at_contacts_flutter features

    trunk

    The at_contacts_flutter package simplifies contact management within Flutter applications. It integrates with the at_onboarding_flutter widget to ensure secure management of secret keys (replacing traditional usernames and passwords).

    Key Features:

    • Create new contacts
    • Delete contacts
    • Block/Unblock contacts
    • Fetch and display existing contact lists

    Available UI Components:

    • ContactsScreen: Mobile/tablet contact list.
    • BlockedScreen: Blocked contacts list.
    • DesktopContactsScreen: Contact list optimized for desktop applications.

  5. Overview of at_contacts_group_flutter

    trunk

    The at_contacts_group_flutter package provides Flutter developers with group management capabilities on the atPlatform. It builds upon the at_contact Dart package to provide CRUD (Create, Read, Update, Delete) features for contact groups.

    Key features include:

    • Decentralized Data Access: Cryptographic control via personal data stores.
    • No Backend Required: Operates on the atPlatform edge computing model.
    • End-to-End Encryption: Only the data owner holds the keys.
    • Privacy: Surveillance-free connectivity.

  6. Overview of at_contact

    trunk

    The at_contact package is designed for Flutter developers who need to persist contacts within an atPlatform application. It provides the necessary functionality to add, update, and delete contacts directly on the atPlatform.

    As part of the atPlatform ecosystem, it follows a decentralized, edge computing model characterized by:

    • Cryptographic control of data access via personal data stores.
    • No requirement for an application backend.
    • End-to-end encryption where only the data owner holds the keys.
    • Private and surveillance-free connectivity.

  8. Overview of at_auth capabilities

    trunk

    The at_auth package is the platform-neutral core for onboarding, authentication, and APKAM (App-level Pkam Key Authentication Mechanism) enrollment in the Atsign Protocol. While most developers should use higher-level packages like at_onboarding_cli or at_client_flutter, at_auth provides the following low-level entry points:

    • CRAM-based initial onboarding: AtAuth.onboard(AtOnboardingRequest, cramSecret)
    • PKAM authentication: AtAuth.authenticate(AtAuthRequest)
    • APKAM enrollment (request side): AtEnrollment.submit(...)
    • APKAM enrollment (approve side): AtEnrollment.approve(...) or AtEnrollment.deny(...)
    • Free atSign registration: RegistrarService (used to fetch a CRAM key by email)

  9. Overview of at_client_skills coverage

    trunk

    The at_client_skills package provides specialized knowledge for AI agents on the following at_client topics:

    • Data Management: AtCollection<T> (CRUD, CItem<T>, Query<T>), sub-collections, read receipts, and event streams.
    • Querying: wherePath and PathField<T> typed predicates.
    • Observables: watchWithTree and watchWithSub for multi-level hierarchies.
    • Authentication: at_client_flutter auth flows (CRAM, atKeys file, device keychain, and APKAM).
    • Setup & Patterns: AtClientManager post-auth setup, package selection, and domain-object patterns (toJson/fromJson, registerFactory, typeTag).
    • Testing & Architecture: Unit testing without a live atServer using collections_test_hooks.dart, and architectural guidance for AtCollection<T> vs Notifications + SQLite.
    • Deprecations: Guidance on AtCollectionModel, at_common_flutter, and at_backupkey_flutter.

  10. Understand the D1 Implementation Plan and Project Structure

    trunk

    The D1 implementation plan is a prescriptive execution plan for making Atsign Protocol messaging post-quantum-safe via a single-tier nskey data path. The project is organized into four distinct package-domain tracks to allow concurrent development and minimize file collisions:

    • Track A (Crypto Primitives & Providers): Managed in at_chops (stateless core + HPKE) and provides the nskey data path providers (at/nskey + at/symmetric/AES/GCM), secret_sharing/, and crypto/group/.
    • Track B (Key Management): Managed in at_auth. It involves extending AtKeys in place, AtKeysIo runtime persistence, and the WASM barrel split to support the PQ enrollment-conveyance key.
    • Track C (at_client Crypto Seam & Migration): Managed in at_client. It owns crypto.dart, crypto_runtime.dart, and legacy/, handling the publish ladder and AtClientPreference.
    • Track D (Storage, Platform & Consumers): Manages LocalKeystoreAtKeysIo, the updatable .atKeys file path, and consumer tools like at_onboarding_cli, at_client_flutter, and at_cli_commons.

    Note on File Partitioning: Within at_client/crypto/, Track C owns the runtime and legacy files, while Track A owns the new crypto/group/ and crypto/nskey/ files to ensure low collision by construction.

  11. Understand the scope and structure of the PQ design documentation

    trunk

    The design.md file serves as a technical reference for the post-quantum (PQ) cryptography implementation within the at_client_sdk. It focuses on the detailed mechanics and build-level implementation steps for the D1 (nskey data path) and the secret-sharing substrate.

    It is important to distinguish this document from others in the repository:

    • For project sequencing, dependencies, and critical paths, refer to implementation-plan.md.
    • For use-case catalogues and test harnesses (Given/When/Then), refer to acceptance.md.
    • For design rulings and decision timelines, refer to decisions.md.
    • For high-level concepts, migration philosophy, and roadmaps, refer to roadmap.md.

  12. Overview of the Client Substrate (SS-0)

    trunk

    The client substrate (SS-0) provides the foundational capabilities for secret sharing and key management within the at_client_sdk. Key features include:

    • X-Wing Secret Sharing: Uses pqSeal/pqOpen (HPKE + AES-256-GCM) for __ssenv envelopes, utilizing HKDF info 'at_client/secret_sharing/v1'.
    • Envelope Security: Implements per-envelope APKAM signing and a 'verify-before-decrypt' pattern. Verification precedes the open operation.
    • Addressing: Uses kpid addressing for envelopes and fan-out, keyed by the key-package kid.
    • Key Management: Supports per-APKAM KeyPackage keyed by (enrollmentId, apkamId) with crypto-agile parsing via bestKeyFor.
    • Secret Operations:
      • requestSecret(name) and waitForSecret for requesting/serving secrets.
      • pushSecretToNamespaceMembers(Secret, {exclude}) for distributing secrets.
      • shareAllSecretsWithEnrollment for approval paths (deduplicated by kpid).
    • Secret Storage:
      • SecretStore.putIfNewer ensures monotonic-version ordering.
      • namespaceAuthorizes supports suffix and * matching.
      • Transport includes put, sync listeners, and optional wake-up notifications via receivedSecrets and _consume.