#Secondary edition v1.1: dual friend-link verification, MCP server and separate key types

Release date: October 26, 2026

Current version: v1.1.2 (latest)

This page collects every change in the v1.1 line, covering v1.1.0, v1.1.1 and v1.1.2. Patches within the same line are merged into this page; a new page is created when a new line (such as 1.2) starts, and announcements are written according to the size and the need of the change.

#Releases in this line

#v1.1.0 Two friend-link verification methods

After an application passes JSON validation, the bot enters the awaiting_method_choice stage and asks the applicant to choose:

• Reply 1 (also 一 / 方案一 / 方法一) for a DNS TXT record
• Reply 2 (also 二 / 方案二 / 方法二) to upload an HTML file

For DNS, the instructions list host _jiaofriend, type TXT and the verification code as the value; verification queries the TXT records of _jiaofriend.<visitor-domain> through Cloudflare DNS-over-HTTPS and checks whether one contains the code. The file method keeps the strict check: the GET must return 200 and the <body> text, after stripping tags and scripts, must contain the code.

The state machine gains an awaiting_verification stage and records verifyMethod; a modify application asks for the method again for the old and the new site; pre-upgrade verifying states fall back to file verification. DNS lookups go through the injectable dependency resolveTxt(name) => Promise<string[]>, which keeps the resolver testable and replaceable.

This release also fixes friend-link verification accepting SPA fallbacks, custom 404 pages, 403/500 responses and 30x redirects, plus /friends-sitemap.xml being swallowed by the frontend router, viewing a key turning encrypted storage into plaintext, repeated captcha initialization crashing applications, and inbound email parsing under CJS / ESM bundles.

#v1.1.1 MCP server

The site adds an /mcp endpoint that exposes articles, moments, friend links and site settings through MCP (Model Context Protocol), so Claude Code, Cursor, Claude Desktop and MCP Inspector can read and maintain content.

• Transport: Streamable HTTP, with a fresh instance per request and no state shared across requests
• Authentication: X-API-Key or Authorization: Bearer, reusing settings-page keys and refreshing their last-used timestamp
• Scope filtering: tools/list is filtered by key scopes, with the new content.read scope
• Safety checks: Host and Origin validation blocks DNS rebinding, and custom domains are enabled through MCP_ALLOWED_HOSTS

Client configuration example:

{
  "mcpServers": {
    "rin": {
      "type": "http",
      "url": "https://<site-domain>/mcp",
      "headers": {
        "X-API-Key": "<mcp-key>"
      }
    }
  }
}

On a custom domain, attach the domain to the worker as a Custom Domain or Route in Cloudflare, and add the domain to MCP_ALLOWED_HOSTS (or set FRONTEND_URL to the site origin). 421 Misdirected Request comes from the Cloudflare edge while 403 Invalid Host comes from the server allowlist; see the API guide for both.

#v1.1.2 REST API keys and MCP keys split apart

Both endpoints used to share one set of keys and scopes, so a key created for scripted automation could also call the MCP endpoint. Keys are now split into two types:

• The type is fixed at creation, and the settings page lists and creates keys under separate REST API and MCP tabs
• A type that does not match the endpoint is rejected during authentication with 403, before any business logic runs
• content.read is available to MCP keys only; REST API keys select feed.write, moment.write, friend.write and the config.* scopes

The database gains a key_type column, and migration 0021.sql classifies existing keys automatically: keys whose scopes include content.read become MCP keys and the rest become REST API keys. Existing MCP clients keep working after the upgrade without recreating keys; a key that served both scripts and MCP clients keeps only one capability, so split it by purpose.

#Version status and numbering

The project follows standard semantic versioning, its version line starts at v1.0.0, and release tags use vX.Y.Z:

1. MAJOR: incompatible changes, X increases and the lower numbers reset
2. MINOR: backward-compatible features, Y increases and Z resets
3. PATCH: fixes and small changes, Z increases
4. Prerelease: a suffix such as -beta or -rc.1, for example v1.2.0-beta.1

Every release is recorded in the changelog. Announcement pages are maintained according to the size and the need of the change, and several releases of one line can share a page. When an entry mentions both the official upstream and this project's version, this project's version is written as yjvX.Y.Z. v1.1 is currently the latest line.

#Upgrade notes

• Pull the code and redeploy; migrations run as part of the deploy flow with no manual step
• Custom-domain sites must set MCP_ALLOWED_HOSTS, otherwise the MCP handshake returns 403
• Existing keys are classified automatically; if a client reports 403, check that the key's tab matches the endpoint

See the API guide for endpoint details and the changelog for the full list of changes.

#Feedback

If you find issues while validating v1.1.0~v1.1.2, report them through:

• Secondary edition issues: https://github.com/wool-hmq/Rin/issues
• Secondary edition discussions: https://github.com/wool-hmq/Rin/discussions
• Official upstream issues: https://github.com/openRin/Rin/issues