{"id":20749823,"url":"https://github.com/relay-network/bridge","last_synced_at":"2026-05-10T05:12:31.175Z","repository":{"id":178822346,"uuid":"659948287","full_name":"relay-network/bridge","owner":"relay-network","description":"An application server or proxy for XMTP.","archived":false,"fork":false,"pushed_at":"2023-08-12T18:21:02.000Z","size":245,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-06-04T02:58:16.754Z","etag":null,"topics":["encryption","ethereum","nodejs","privacy","typescript","xmtp"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/relay-network.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":"roadmap/2023-05-31.checkpoint.md","authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-06-28T23:18:47.000Z","updated_at":"2023-08-16T01:11:21.000Z","dependencies_parsed_at":null,"dependency_job_id":"2c80d29d-2608-4f42-878a-90794b04330c","html_url":"https://github.com/relay-network/bridge","commit_stats":null,"previous_names":["relay-network/xmtp-bridge","relay-network/bridge"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/relay-network/bridge","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/relay-network%2Fbridge","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/relay-network%2Fbridge/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/relay-network%2Fbridge/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/relay-network%2Fbridge/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/relay-network","download_url":"https://codeload.github.com/relay-network/bridge/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/relay-network%2Fbridge/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":268333915,"owners_count":24233782,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-02T02:00:12.353Z","response_time":74,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["encryption","ethereum","nodejs","privacy","typescript","xmtp"],"created_at":"2024-11-17T08:24:39.813Z","updated_at":"2026-05-10T05:12:29.448Z","avatar_url":"https://github.com/relay-network.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Overview\n\nDeploy XMTP adapters for HTTP APIs.\n\n# Architecture Overview\n\n**API Server**\n\nA simple HTTP server that is responsible for managing the state of the system.\nFor example, you use the API server to sign up for the platform.\n\n**Bridge Instances**\n\nA bridge instance is an XMTP client that is configured to respond to messages\nfrom various addresses in different ways. Right now, there are three message\nhandlers:\n\n- forward proxy (listen to XMTP messages and forward them to an HTTP endpoint)\n- reverse proxy (listen to XMTP messages from the API server's XMTP identity\n  and then forward them to their destination XMTP identity).\n- canary (listen to XMTP messages from a specially-designated XMTP identity and\n  call the canary endpoint on the API server).\n\n**Auxiliary Components**\n\n- Postgres database for storing state\n- Nginx for ingress\n- LetsEncrypt (using nginx-proxy) for TLS automation\n\n# Project Overview\n\nThe entire project, from development to production, is designed in such a way\nthat you can step through the development process, make changes, validate the\nchanges, open a PR, merge changes, and deploy to production without ever needing\nto ask anyone for help (in theory 😁, please ask questions). Start with the next section.\n\n# Development\n\n`npm run test:dev` and follow the error messages.\n\n# Validate Changes\n\nIf the GH workflow defined in `.github/analyze.yaml` passes, then you're good to\nrequest a code review.\n\n# DevOps\n\n- The goal is for everything to fail very fast and very loudly. If you're\n  running the system and don't see any errors, you should have very high\n  confidence that everything is working. The way we will accomplish this is by\n  being extremely explicit about what are the system's entrypoints. We will have\n  some very strong invariants that we uphold for all entrypoints.\n- Every script needed to run the system is in `package.json`. These scripts are\n  the project's \"entrypoints\".\n- Every script sources `shell/env.sh` to get its environment variables. This env\n  file should have tons of documentation, error handling, validation, and\n  testing.\n- There is a corresponding `env.ts` source file. This source file should be\n  extremely obnoxious in the same way that `env.sh` is. `env.ts` must correspond\n  to each other. We need to test this correspondence.\n- There should be a primary test file for each environment. Right now, that\n  means we have:\n  - dev.test.ts (for validating a dev environment)\n  - docker.test.ts (for validating a docker environment)\n  - prod.api.test.ts (for validating the prod API server)\n  - prod.bridge.test.ts (for validating the prod bridge instances)\n\n# Effects, Services, and Events\n\nThe TypeScript compiler provides lots of guarantees about the correctness of our\ncode. We define an \"effect\" as any part of the system that is not covered by the\nTypeScript compiler. One way to think about an effect is it's a part of the\nsystem that is likely to fail. We want to be extremely explicit about what are\nthe effects in our system and how we handle them. An effect has the following\nshape:\n\n```typescript\ntype Effect = {\n  app: string;\n  env: string;\n  instance: string;\n  service: string;\n  feature: string;\n  event: string;\n  id: string;\n  metadata: string;\n};\n```\n\nWe manage effects by defining services that wrap a bunch of effects. Most of\nthe time, these services are represented by some library or sdk (for example,\nthe `prisma` library wraps all of the effects related to the database). We\nheavily instrument every service in such a way that we have a very high\nresolution view into the effects that are happening in the system.\n\nFor every service we are take extreme care to instrument the following events\nand their failure modes:\n\n- boot\n- register\n- request\n- handle\n- response\n- success\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frelay-network%2Fbridge","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frelay-network%2Fbridge","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frelay-network%2Fbridge/lists"}