Timmy_Foundation/timmy-config
16
0
Fork 0
Code Issues 57 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

[COMMS] Reconcile live Nostr relay endpoint and client support truth #179

New Issue
Closed
opened 2026-04-04 23:08:36 +00:00 by Timmy · 2 comments
Timmy commented 2026-04-04 23:08:36 +00:00
Owner
Copy Link

Follow-on from Allegro + Ezra Nostr deployment race:

We now have three different truths in circulation:

  • Allegro comment #28367 on issue #138 says relay is ws://143.198.27.163:2929 and recommends Nostur
  • Ezra comment #28369 says clean endpoint is wss://alexanderwhitestone.com/relay/ and also recommends Nostur
  • live probe from the current session confirms a working HTTP response on http://167.99.126.228:2929/ from timmy-relay, while 167.99.126.228:7777 and :3334 are not the onboarding target

We need one canonical operator-facing truth for:

  • which relay URL Alexander should add to a client today
  • whether Nostur actually supports the group flow we expect
  • whether 0xchat is still the practical NIP-29 client while Nostur remains a sovereign operator edge
  • what endpoint should appear in all docs and issue comments

Acceptance criteria:

  • one canonical relay URL for current operator onboarding is documented
  • Nostur capabilities vs limitations are stated plainly
  • if 0xchat is the practical NIP-29 client, that is stated plainly
  • stale/conflicting issue comments are superseded by a newer visible truth comment
Follow-on from Allegro + Ezra Nostr deployment race: We now have three different truths in circulation: - Allegro comment #28367 on issue #138 says relay is `ws://143.198.27.163:2929` and recommends Nostur - Ezra comment #28369 says clean endpoint is `wss://alexanderwhitestone.com/relay/` and also recommends Nostur - live probe from the current session confirms a working HTTP response on `http://167.99.126.228:2929/` from `timmy-relay`, while `167.99.126.228:7777` and `:3334` are not the onboarding target We need one canonical operator-facing truth for: - which relay URL Alexander should add to a client today - whether Nostur actually supports the group flow we expect - whether 0xchat is still the practical NIP-29 client while Nostur remains a sovereign operator edge - what endpoint should appear in all docs and issue comments Acceptance criteria: - [ ] one canonical relay URL for current operator onboarding is documented - [ ] Nostur capabilities vs limitations are stated plainly - [ ] if 0xchat is the practical NIP-29 client, that is stated plainly - [ ] stale/conflicting issue comments are superseded by a newer visible truth comment
allegro was assigned by Timmy 2026-04-04 23:08:36 +00:00
ezra was assigned by Timmy 2026-04-04 23:08:36 +00:00
Timmy self-assigned this 2026-04-04 23:08:36 +00:00
Rockachopa commented 2026-04-04 23:11:05 +00:00
Owner
Copy Link

We already have an entry in digital ocean for the relay. Lets take down the redundant lesser work and continue on one focused thread. We dno't need two nostr relays, and I do want to use the domain not the IP

We already have an entry in digital ocean for the relay. Lets take down the redundant lesser work and continue on one focused thread. We dno't need two nostr relays, and I do want to use the domain not the IP
Timmy commented 2026-04-04 23:32:46 +00:00
Author
Owner
Copy Link

Closing this as resolved for the operator onboarding path. Alexander has now confirmed the working relay path in Nostur on both phone and Mac. Canonical operator-facing relay remains wss://alexanderwhitestone.com/relay/. Remaining work moves to #181 (build the Nostur → Gitea ingress bridge) and #166 (Matrix/Conduit private operator surface).

Closing this as resolved for the operator onboarding path. Alexander has now confirmed the working relay path in Nostur on both phone and Mac. Canonical operator-facing relay remains `wss://alexanderwhitestone.com/relay/`. Remaining work moves to #181 (build the Nostur → Gitea ingress bridge) and #166 (Matrix/Conduit private operator surface).
Timmy closed this issue 2026-04-04 23:32:47 +00:00
Timmy removed their assignment 2026-04-05 02:12:08 +00:00
allegro was unassigned by Timmy 2026-04-05 02:12:08 +00:00
perplexity was assigned by Timmy 2026-04-05 02:12:08 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Dispatched to Kimi via OpenClaw
 claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 enhancement
epic
kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 research
velocity-engine
Auto-generated by velocity engine
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok groq hermes kimi manus perplexity
No Assignees perplexity ezra
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#179
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?