A Terraform Provider for the ATmosphere

The AT Protocol is an open and decentralized social networking protocol which is being adopted by Bluesky (a Twitter competitor) and other social networks like Tangled (a GitHub competitor). The whole protocol evolves around records being stored in your own personal data store (PDS) which are then polled by a Relay server to be federated to the different app servers like Bluesky or Tangled.

You could already create these records using the client apps of Bluesky or Tangled. Or you could call the REST API of your PDS to create / update or delete records. However, if you want to manage these records declaratively, as code, there was not yet a way to do it until today.

Announcing my terraform provider for the AT Protocol! You can find it on the terraform registry.

With this provider, you can now manage your AT Protocol records using terraform. For example, if you want to follow Barack Obama on Tangled, you can now add the following snippet to your terraform configuration:

provider "atproto" {
  handle       = "example.com"
  app_password = "m54s-q9r3-4w8n-6x7v"
}
data "atproto_account" "barack_obama" {
  handle = "barackobama.bsky.social"
}
resource "atproto_tangled_follow" "barack_obama" {
  subject = data.atproto_account.barack_obama.did
}

Why?

Following users on Tangled is probably not something you'll likely do using Terraform. However, there are some other use cases I can imagine for which Terraform might be useful.

Tangled access control

First off, for Tangled, you can set up your own knot. That is a server that actually hosts your codebase. You can use Terraform to declare this knot and limit who can use your knot. This could potentially be linked to other Team setup you might have configured in Terraform, which makes adding or removing users to your knot (and other infra you might have) very easy and declarative.

data "atproto_account" "accounts" {
  for_each = toset(["alice.example.com", "bob.example.com"])
  handle = each.key
}
resource "atproto_tangled_knot_member" "member" {
  for_each = data.atproto_account.accounts

  subject = each.value.did
  domain  = "knot.example.com"
}

You could use similar code to give someone access to your Tangled repository. (Note that this currently doesn't work yet due to a bug in Tangled)

Lexicon publishing

Another use case of this Terraform provider could be to manage a lexicon definition using the Terraform provider. Reading in the json files using Terraform and updating the version published in your PDS. This could run in CI to automatically publish new versions whenever something changes.

There is currently not yet a specific terraform resource for this, but you can use the generic atproto_record resource to create or update any record you want.

resource "atproto_record" "lexicon" {
  collection = "com.atproto.lexicon.schema"
  rkey = "com.entropitor.blog.read"
  record = {
    defs = {
      main = {
        key = "tid"
        type = "record"
        record= {
          properties = {
            createdAt = {
              format = "datetime"
              type = "string"
            }
            subject = {
              format = "uri"
              type = "string"
            }
          }
          required = ["createdAt", "subject"]
        }
      }
    }
    id = "com.entropitor.blog.read"
    description = "My lexicon"
  }
}

First step towards a static PDS

Streamplace (a Twitch / YouTube competitor) has made the case for a static PDS, comparable with a static website, where you would generate your AT Protocol records and could then serve them in a light-way fashion. This terraform provider could be used to manage these records in a declarative way, and push them to a normal PDS. It's not yet a truly static PDS but you still get the benefit of generating your records using code.

And you?

What are you gonna build with the Terraform provider for the AT Protocol?

If you want to learn more about how this was built, you can read my other blog post