Skip to content

[Feature]: X Post Bot Service #62

@snowdamiz

Description

@snowdamiz

Please describe the problem you are trying to solve, not only the shape of the solution.

Before you submit

  • I searched existing issues, docs, and examples for prior discussion or an existing workflow.
  • I explained the user problem or workflow gap this request is addressing.

Area

  • other (infrastructure/services)

Problem statement
We need a way to automatically post bounty notifications to X (Twitter) when new issues are created. Currently this is a manual process or requires integrating with third-party services. We want a simple, self-contained solution that can run on anything that supports docker.

Proposed solution
Build a stateless, serverless Go service that:

  • Runs as an always-on service on Fly.io
  • Exposes HTTP handlers to accept posting requests
  • Accepts payload with: ticker, CA address, issue URL link
  • Posts to X using X's pay-as-you-go API
  • Has a configurable message template with a sensible default

Default message format:

New bounty has been posted by $TOKEN! Solve the bug, submit your PR, get paid.
Follow the link below 👇

The service should be:

  • Written in Go
  • Stateless (no database persistence required)
  • Serverless design (each request is independent)
  • Configurable via environment variables (X API credentials, message template, etc.)

Alternatives considered

  • Using third-party Twitter/X automation services (adds cost and dependency)
  • Integrating into existing Mesher services (adds unnecessary complexity to core services)
  • Using different hosting providers (we already use Fly.io)

Expected impact

  • Automated bounty notifications reaching X followers in real-time
  • Reduced manual work for team members
  • Lower barrier for contributors to discover new bounty opportunities
  • Success measured by: increased PR submissions for posted bounties, reduced time between issue creation and X posting

Additional context

  • The service should be deployed to Fly.io with configuration to prevent sleep (likely using fly scale count 1 and proper health checks)
  • X API credentials will need to be configured as Fly secrets
  • Consider rate limiting from X API when designing the handler

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions