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

Design Decisions #1

Open
DavidBuchanan314 opened this issue Feb 25, 2024 · 1 comment
Open

Design Decisions #1

DavidBuchanan314 opened this issue Feb 25, 2024 · 1 comment

Comments

@DavidBuchanan314
Copy link
Owner

DavidBuchanan314 commented Feb 25, 2024

Goals

  • Single-user (but potentially multi-repo) PDS. Although perf-wise it could probably handle many users, being single-user means we can skimp on moderation and admin features.
  • Low system requirements - should be comfortably deployable on a raspberry pi (for example), with room to spare.
  • "production grade" - whatever that means, lol (Edit: concretely, it should be deployable, maintainable (consider how updates should work), backup-able, etc.)
  • Correctness (in terms of conformance to relevant specifications)
  • Security

Non-Goals

  • Multi-threading - everything we need should be achievable on a single thread (with async)
  • High performance. Even a power-user isn't going to be creating records faster than about 1 per second, and we don't need crazy performance stats to keep up with that, although latencies should be kept under control for a good user experience (note: this is not at odds with the low system requirements goal)

Data encode/decode

atmst and dag-cbrrr will handle the heavy lifting in terms of atproto internals, handling MST wrangling and DAG-CBOR respectively.

JSON encode/decode will be handled by msgspec (can msgspec can also be leveraged to perform lexicon validation???) (Edit: honestly there's no good reason not to just use the stdlib, for now)

Database

Sqlite, of course. The big question is how to lay things out (#4). For repo writes, sqlite multi-file commits can be used to keep the per-user db in lockstep with the central db.

apsw looks interesting and might make it easier to manage transactions correctly.

Is it worth using an ORM or should I just do raw queries?

Crypto[graphy]

Exactly the same as picopds I imagine - pyca/cryptography plus pyjwt

https://github.com/hynek/argon2-cffi for password hashing

HTTP

I'm probably going to use aiohttp, because it has both server and client support (convenient for appview proxying) and websocket support (important for subscribeRepos).

An open question is how to package everything for deployment. The short answer is "it runs behind nginx", but how does the end-user install, configure, and launch it? I imagine systemd units will be involved. Are there any similar projects I can look at, for reference?

I can imagine having some kind of millictl CLI tool for basic admin ops.

@DavidBuchanan314
Copy link
Owner Author

DavidBuchanan314 commented Nov 8, 2024

See also: bluesky-social/atproto#2350 "What does a PDS implementation entail?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

1 participant