9 Home
maren edited this page 2023-12-28 21:18:00 +00:00

💡 needs work! for now it's not a wiki, just chaotic brainstorming

Things to consider

  • Write the go service
    • Turns out it's actually a client not a server?
    • Poll-based vs webhook-based behavior configurable with parameter
  • Get everyone on twilio account
    • Done!
  • Write deployment stuff (make, docker, helm, etc.)
  • Document:
    • How to deploy
    • config options
    • Special:
      • Document creating compliant sms marketing campaign on twilio
      • Document other twilio setup (sort of unknown complexity right now)
        • HIGH PRIORITY: confirm billing policies to ensure there isn't a secret clause where they can just let us rack up a bill and invoice us later in case of some kind of catastrophic failure or spam influx
  • Signal groups getting large feature updates early 2024, this may change the process dynamically
    • Others: i.e. Discord, WhatsApp, Telegram APIs likely relevant
    • SMS is important for non-smartphone users and less cross-platform stuff
    • Can Twilio manage the queue for us?
      • Get request to API url - how to edge trigger instead of purposeful Gets
        • Rate limits/Verify seems to be the relevant factor here

Twilio dev console:

Pin these things: "Phone numbers" "Messaging" No Incoming Messages for Early Rave itself (!) Code Conventions Written in Go SQLite database backend - longer term goal for expansion capabilities JSON Blob payloads to Twillio flows for actual call and SMS process Go federation backend being dev'd by bspar's company Binaries for ARM and X86 on windows, linux, mac Is queue a priority concern up front? bspar: yes, because it can have heavy impact on compute speed/resource weight If queue is easy to implement in binary or container, there is unlikely to be any practical reason to avoid bspar: should be super simple, simple code - maren wants to learn this GRPC - HTTP2 (bound to HTTP3 for speed) Outgoing > incoming > outgoing could lead to blocking issues Go piping exists - is this practical? Webhooks likely relevant Dani: Is it possible to completely circumvent HTTP? bspar: will require higher reliance on Twilio CRM/Flow process Twillio Conversations - allow for deeper customization/offloading of different request calls/responses maren: what is the cost overhead on this possibility? bspar: there is an upcharge, adds up at scale Inbound is same cost as outbound, bad actors could potentially hike costs Blocking/mitigation possibilities: Opt-Out data: See Link 1 in Random Links heading Verify Fraud Guard: Link 2 in Random Links Webhooks seem preferred based on the quickstart: https://www.twilio.com/docs/messaging/quickstart/go?code-sample=code-respond-to-an-incoming-text-message&code-language=Go&code-sdk-version=1.x Possibly do both? GORM + SQLite for databasing, and queue maren: I want to avoid pulling in unnecessary/extraneous libs as much as possible to reduce bloat - these seem functionally appropriate i.e. no fastHTTP for no functional reason Container/self-host/k8s cluster hosting considerations

Assignments:

  • Twilio Investigation - SMS Flow process correct, testing to confirm cost and/relevance to use case
    • maren: Twilio Studio may be redundant/unnecessary, can this be API?
    • bspar: would have fun putting Woman™ in Go bin (lol, but also serious)
    • maren: docs indicate basic requirements for compliance under SMS regulations - 10DLC (10 Digit Long Code - full length localized phone #, faster than 800 free number)
    • calls cost money - cancelled
    • how to tell Twilio to talk to endpoint without flow
  • ATP message service - link 3 (and sub) in Random Links
  • Licensing - need to settle
    • (A)GPL (v3)
    • MIT
    • Apache?
    • NVPL - no because it generally leads to inflammatory/reactionary responses and the goal is to have this project be used as widely as possible
    • Further discussion warranted
  1. Store Opt-Out data on Twilio with Functions and Sync
  2. Verify Fraud Guard | Twilio
  3. Programmable Messaging | Twilio - the docs for how to make twilio talk to our go service in the most basic/inexpensive way possible