You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered:
Goals
Non-Goals
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.The text was updated successfully, but these errors were encountered: