flutter pub add at_events_flutter根據套件公開資料產生的選型評估，僅供參考。
at_events_flutter 是一個 Flutter 插件，可使用 atPlatform 實現事件管理——處理時間、地點和參與者。它透過 atSign 生態系統實現設備間的安全、去中心化事件協調，確保資料同步與隱私保護。此套件專為跨平台使用設計，可無縫整合至 Android 與 iOS 應用中。透過 atClient 支援即時更新與安全分享事件細節，確保使用者之間可靠且加密的通訊。
以下為關聯原始碼儲存庫的 README 原文快照，最新內容請造訪原始碼儲存庫。
The main repository for libraries used to build applications on the Atsign Platform. Three categories: SDKs, libraries, and Flutter widgets.
Atsign('@alice').open,
.activate and .enroll hand back an AtClient — as well as
collections, sync, notifications and encryption.at_client, for mobile and desktop apps.
Adds onboarding / authentication dialogs and device-keychain
storage. Flutter web is not a supported target.
Dart libraries for building Atsign Platform applications. All are published on pub.dev.
at_client's lifecycle verbs: CRAM activation, the APKAM
enrollment handshakes, the .atKeys key stores and the registrar
client. Applications reach it through at_client.at_client. Wraps the boilerplate of
parsing flags, loading keys, and producing an authenticated
AtClient.at_client
and at_client_flutter.at_register and at_activate command-line tools for registering,
activating and enrolling atSigns, and a small library for programs
that drive the same flows headlessly.
Status: Most of the
at_*_flutterpackages listed below are in the process of being deprecated. Over the next few months they'll be replaced by example application code rather than reusable widget packages. The recommended path for new Flutter work is to read the example app atpackages/at_client_flutter/examples/todosand adapt it directly. The packages will continue to publish until that migration completes.
FileAtKeysIo as the
at_client_flutter README
shows.at_client_flutter.at_contacts_flutter.at_client_flutter snippet.The SDK can protect everything an adversary could record today — data shared between atSigns, an atSign's own data, and the secrets an enrollment approval hands a new device — with post-quantum key establishment, and can authenticate with a post-quantum signature. It is opt-in per client, through one setting:
final preference = AtClientPreference(posture: PqPosture.pqReady)
..namespace = 'todos';
| Posture | Authentication | Data written | Reads post-quantum data |
|---|---|---|---|
PqPosture.legacy (default) |
RSA-2048 | legacy encryption | no |
PqPosture.pqReady |
ML-DSA-65; publishes a key package and this atSign's namespace keys | legacy encryption, so pre-quantum peers read it | yes |
PqPosture.pqActive |
ML-DSA-65, and an ML-DSA-65 data signing key | post-quantum by default; legacy writes refused | yes |
Under the hood, each namespace an atSign owns gets a key-establishment
keypair — the X-Wing hybrid (ML-KEM-768 + X25519) by default, pure
ML-KEM-1024 on request — published as a signed advertisement; a writer
establishes a content key to the recipient's namespace key and encrypts
the record with AES-256-GCM, and a sender follows whatever the recipient
advertised. An enrollment submitted under a post-quantum posture
advertises a key package, and the approving client seals the atSign's
secrets to it rather than wrapping them with RSA. A client whose posture
asks for a stronger authentication key than its enrollment holds
re-enrolls itself at its first start, filing the new enrollment in the
same keys store beside the legacy fields. ML-DSA authentication needs an
atServer that verifies it; a legacy client makes no such demand.
The default posture moves one stage per major of at_client — 3.x
legacy, 4.x pqReady, 5.x pqActive — because a record may only be
written in a scheme every reader of it supports, so the stage that reads
post-quantum data rolls out before the stage that writes it by default. An
app on 3.x names pqReady or pqActive to move first.
The developer's view, the goals and the ladder are in the
at_client README;
the design is under docs/projects/pq/.
Applications talk to at_client (3.x, a minor release), so most need no
code change: the new lifecycle verbs sit beside AtClientManager, whose
setCurrentAtSign is deprecated rather than removed. The packages that
take a major are the ones that used to hand at_auth's types to an app:
AuthService and
FlutterEnrollmentService are gone; the dialogs take the atSign, the
keys store and the preference, and hand back the AtClient. Nothing
from at_auth is re-exported. The table is in the
at_client_flutter README.at_activate names its command
(at_activate onboard -a @alice), --posture replaces
--signingAlgoType, and AtOnboardingService keeps authenticate()
and atClient while onboard, enroll and close become
Atsign.activate, Atsign.enroll and atClient.stop(). The table is in
the at_onboarding_cli README.AtAuth and its request and response objects
are gone; activation is activateAtSign(...), logging in and every
enrollment decision are at_client's. The table is in the
at_auth README.If you happen to import at_onboarding_cli or at_auth directly — which
almost no application does — the short version is: replace the call that
built your client with Atsign('@alice').open(keys: ..., preference: ...),
.activate(...) or .enroll(...), drop the import, and read everything
else off the AtClient you get back.
Each package's own README and pub.dev page have the installation details. Click any of the links above.
The at_client_skills package gives AI agents accurate, up-to-date knowledge of
at_client and at_client_flutter — covering AtCollection<T>, auth flows,
querying, sub-collections, testing patterns, and common pitfalls.
# Add to your project
dart pub add --dev at_client_skills skills
# Install the skill into your IDE
dart run skills get
Works with Claude Code, Cursor, GitHub Copilot, Cline, and any agent supporting the agentskills.io specification.
依賴清單 13 項
^3.7.0^3.3.0^2.1.0^5.5.0^3.0.9^4.0.16^4.0.17^3.1.14^3.0.49^3.0.19^8.2.20.9.1^2.0.0+1暫無相關資料。