a step by step process into an appview

or, at least, what i had to do to spin up bsky, from a fresh clone towards a smol appview that you can Do Things With

you will need

• linux server
• linux shell skills
• docker (but podman should work)
• a wildcard certificate for your domain, say *.asky.ln4.net
  • certbot dns-01
• a wildcard certificate for the users of your domain, say *.pds.asky.ln4.net
  • you could go without wildcard certs but it gets much annoying
  • if you're spinning up the system outside of internet access, you're able to still use certbot. spin a small vps, run certbot on it, then extract the certificate out to your deployment

plc #

• everything depends on the plc to function, so it must be first
• git clone https://github.com/did-method-plc/did-method-plc
• setup plc. you can't use their ghcr images as they're locked behind auth
• docker build -t bsky-plc . -f packages/server/Dockerfile
• configure a postgres. not going into too much detail
• NOTE: if you've used yarn run start, the env var for the database is actually a json rather than database uri
• expose as pds.asky.ln4.net

here's my docker-compose file as a reference

services:
  pds:
    image: bsky-plc:f96c898
    network_mode: "host"
    environment:
      - "DB_CREDS_JSON={\"username\": \"bsky_plc\", \"password\": \"...\", \"port\": \"5432\", \"host\": \"localhost\", \"database\": \"bsky_plc\"}"
      - "DB_MIGRATE_CREDS_JSON={\"username\": \"bsky_plc\", \"password\": \"...\", \"port\": \"5432\", \"host\": \"localhost\", \"database\": \"bsky_plc\"}"
      - "PORT=32990"
      - "DEBUG_MODE=1"
      - "LOG_ENABLED=true"
      - "LOG_LEVEL=debug"
      - "LOG_DESTINATION=1"

relay #

• relay depends on plc for things like scraping new plcs
• everything else builds on top of it, it is core atproto infrastructure

pds #

• we can put everyone in a single pds
• in https://bsky.app, that's https://bsky.social (as entryway, but i won't setup via entryway)

appview #

• appview is composed of 3 parts
  • dataplane
    • has a "reference implementation" we'll use that uses postgresql
    • the bluesky pbllc one is (at the moment) closed source but scales better via scylladb, more info on the index
  • image proxy
    • proxies PDSes images
  • appview itself
• i deploy each separately for maximum understanding of how it glues together
• in https://bsky.app, that's https://public.api.bsky.app and https://api.bsky.app

appview (dataplane) #

TODO

appview (image) #

TODO

appview (appview!) #

TODO

social-app #

• the frontend you load on https://bsky.app
• it talks to appview, appview is what serves it
• currently this requires manual patching, which sucks a looot.

TODO

feedgen #

• from internal conversations with others, it seems appview already provides some basic feedgen services. (TODO: after configuring appview, see if default feeds work)
• either way, you may want to spin up your own feedgens for shenanigans. good thing is that external feedgens are already a part of the protocol and somewhat easy to spin up
• in https://bsky.app, that's feed generators

ozone #

• not required, but
• in https://bsky.app, that's moderators

jetstream #

• a more friendly relay, https://docs.bsky.app/blog/jetstream
• more and more applications are requested to migrate to jetstream for lexicon filtering
  • even more information regarding scaling the current bsky.app relay: https://github.com/bluesky-social/atproto/discussions/3036