NAOMS Devlog

Building a sovereign, local-first memory & identity system โ€” in the open, honestly.

Codes that really get sent

GreenCheck's phone and email verifiers can now send real codes by text message (Vonage or Twilio) or email (SendGrid), and refuse by name when they cannot.

Product Teacher free October 29, 2026ยท2 min readยทcraft
TL;DR GreenCheck can verify that a phone number or email address belongs to someone by sending a real code. This step adds the senders, with the setup screen still to come.

How do you know the person who says "this is my phone number" is telling the truth? One simple way is to send a short code to that number and ask them to read it back. NAOMS now sends such codes for real.

What GreenCheck is

GreenCheck is how people in NAOMS verify things about each other, such as that a phone number or email address belongs to them. A verifier is a plugin that runs one kind of check. Verifiers record their results so others can rely on them without redoing the work.

The phone and email verifiers existed, but until now the part that actually sends the message was a stand-in that only wrote to a log. Nothing left the device. This step adds real senders.

What it can send

  • Text messages through two providers, Vonage and Twilio. Providers are companies that deliver messages for a fee.
  • Email through SendGrid.

The message carries a short code, in the form "Greencheck code: ...". The person reads it back and the check can pass.

Three rules shape how it behaves:

  1. A check cannot pass on a send that did not happen. Success is reported only when the provider itself accepted the message.
  2. Failures have names. If something goes wrong you see which one: sender_auth_rejected (the provider refused your key), sender_from_not_allowed, sender_no_balance, sender_unreachable, or sender_not_configured (no credentials set up).
  3. Secrets stay out of view. Keys travel in the request body or an authorization header, never in the web address, a log line or an error message. A provider's reply is read for a status and then dropped, because a provider can echo a key back.

A walk-through

Imagine a hive that wants to confirm its members' numbers. The person running the verifier connects their Twilio account and a "from" number, which must start with +. For email, SendGrid needs a from-address. A new member asks to verify, a text arrives, and the member reads back the code.

What's next

  • There is no setup screen yet. A design mock for a provider onboarding screen exists, but it is a mock, and the screens and operations that connect an account wait on decisions from the owner.
  • Other email routes are not built. Amazon SES, SMTP and Gmail refuse by name (sender_transport_not_built) instead of pretending.
  • No delivery receipts yet. The design wants receipts an outside auditor could check, and this step does not provide them. The health check also still reports "healthy" when no sender is set up.

Written by AI agents from real project logs; owned and edited by Mujo.

โ† more in Product   home โœฆ   all โ†’