Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tracking SDK progress (indigo/atproto/*) #378

Open
3 of 7 tasks
bnewbold opened this issue Oct 6, 2023 · 0 comments
Open
3 of 7 tasks

tracking SDK progress (indigo/atproto/*) #378

bnewbold opened this issue Oct 6, 2023 · 0 comments
Assignees

Comments

@bnewbold
Copy link
Collaborator

bnewbold commented Oct 6, 2023

Sketching out what a more stable "golang atproto SDK" might look like.

  • atproto/syntax: syntax types for Handle, DID, NSID, AT-URI, TID
  • atproto/crypto: basically go-did pulled in to this monorepo, and DID-specific stuff removed. smaller API surface specifically for atproto, abstracting away most implementation details and config knobs
  • atproto/identity: combined handle and DID resolution. interface for caching/persistent services
  • atproto/data: runtime helpers for data model, possibly using go-ipld-prime. eg, for working with records and JSON when you don't know the schema. DAG-CBOR to JSON conversion.
  • atproto/lexicon: generic Lexicon helpers, and types for dealing with Lexicon schema JSON itself. likely runtime schema verification. the sort of utils which get referenced by codegen'd code
  • atproto/repo: MST and repository implementation, including CAR import/export, diff processing, verification, interfaces
  • atproto/client: generic HTTP client ("XRPC"), with ergonomic auth help. possibly generic stream (WebSocket) client helpers also. no codegen stuff for specific Lexicons.

Codegen tooling and codegen output (record types, client APIs, server handlers) would probably live elsewhere, at least for a while.

@bnewbold bnewbold self-assigned this Oct 6, 2023
@bnewbold bnewbold mentioned this issue Oct 6, 2023
7 tasks
bnewbold added a commit that referenced this issue Dec 26, 2023
This works around a current issue in prod where actions are failing to
persist because the session expires.

The real fix for the underlying issue (IMHO) is to re-implement
`xrpc.Client` to handle this in a more elegant and robust way. That is
sort-of tracked in #378

I was initially confused why this was only coming up when taking
actions, because the client is used for a number of reads (GET) as well.
Those GETs mostly use *admin* auth (a token in the HTTP Authorization
header), not login/session auth (which requires refresh), which explains
why it mostly works, then fails for actions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant