Skip to content

x: treat add_conversation_keys UNAUTHORIZED_REQUESTING_USER as final (2.8.1) #728

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
santiagomed wants to merge 1 commit into
base: main
Choose a base branch
from
+8 −3
Open

x: treat add_conversation_keys UNAUTHORIZED_REQUESTING_USER as final (2.8.1) #728

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion third_party/x/.cursor-plugin/plugin.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
{
"name": "x",
"displayName": "X",
"version": "2.8.0",
"version": "2.8.1",
"minClientVersions": {
"cursor": "3.13.0"
},
Expand Down
5 changes: 5 additions & 0 deletions third_party/x/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,11 @@

All notable changes to this plugin will be documented here.

## 2.8.1 — Stop on UNAUTHORIZED_REQUESTING_USER from add_conversation_keys

- `UNAUTHORIZED_REQUESTING_USER` from `add_conversation_keys` means the other person can't receive encrypted chats from the owner, almost always because they don't follow the owner. It is final for that conversation for the session: don't re-post, re-prepare keys, or send. Tell the owner the other person has to follow them first, and both accounts need X Chat keys.
- A prepared `add_conversation_keys` body is single-use and must never be saved and re-posted.

## 2.8.0 — Livestreams

- Requested `broadcast.read` and `broadcast.write` so agents can manage the owner's X livestreams on `https://api.x.com/mcp`.
Expand Down
4 changes: 2 additions & 2 deletions third_party/x/skills/x-api-mcp-guide/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -261,7 +261,7 @@ Do not tell them to create a Project or App. Do not ask for a Bearer token. Afte

> I'll retry in a minute.

400 `invalid-request`: fix params, don't retry unchanged.
400 `invalid-request`: fix params, don't retry unchanged. A prepared `add_conversation_keys` body is single-use and must never be saved and re-posted.

5xx / **503** / **`get_usage_credits` missing while other X tools work**: backoff once or twice. Do not treat it as $0 credits, a missing app, or [error 2](#2-account-not-ready). Other endpoints may still work. Then say:

Expand Down Expand Up @@ -645,7 +645,7 @@ Do not accept while you are still paging the list.

**No conversation key yet** (first message, or only unencrypted messages): self + peer public keys (`public_key` = identity, `key_version` = `public_key_version`) → `session-encrypt` with `prepare` set → MCP `add_conversation_keys` (conversation `id` = thread id from inbox when known) → MCP `send_chat_message` → confirm.

If `add_conversation_keys` returns `UNAUTHORIZED_REQUESTING_USER` or similar: you likely cannot rotate/init keys for that conversation, or the peer is not on XChat — stop and report; do not send ciphertext under an unpublished key.
If `add_conversation_keys` returns `UNAUTHORIZED_REQUESTING_USER`, the other person can't receive encrypted chats from the owner, almost always because they don't follow the owner. This code is final for that conversation for this session: don't re-post, re-prepare keys, or send. Tell the owner the other person has to follow them first, and both accounts need X Chat keys.

### Chat safety

Expand Down
Loading