Cannot mention (or send DMs to) users with dot or other "uncommon" chars in name #1011

New issue

Closed

opened 2025-11-17 23:07:48 +00:00 by Oneric · 1 comment

Oneric commented

2025-11-17 23:07:48 +00:00

Owner

Your setup

From source

Version

(current develop) d96c6f438d

PostgreSQL version

What is wrong?

Sending a DM with a text like

@us.er@remote.org hi!

will not actually get processed as a mention of the remote user and thus noöne except the author themselves is actually receiving the message.

That’s because Pleroma’s Linkify library which we use to auto-insert clickable links, extract hashtags and extract mentions uses this, kinda restricitive regex for matching mentions: ~r/^@(?<user>[a-zA-Z\d_-]+)(@(?<host>[^@]+))?$/
(one can test what it detects by changing the passed mention_handler to print out what was found)

This affects the Bridgy setup bot @bsky.brid.gy@bsky.brid.gy which is how I got made aware of this (see: https://github.com/snarfed/bridgy-fed/issues/374#issuecomment-3422614199 )

So far so understandable. The really weird thing here is, back when testing the initial Bridgy interop after fixing signatures etc, I did successfully exchange DMs with the bot.
At this point the formatting was already kinda iffy, rendering the handle as an at-symbol followed by a link, but it still produced a mention in the API and thus reached the bot.
I tried to bisect this but both 522a168af6 (what the HTTPSig PR was originally starting from) and 5987dd43d4 (after the PR got merged) already fail the “with dot” test:

Elixir tests intended to bisect this

defmodule Pleroma.Web.CommonAPI.ActivityDraftTest do
  alias Pleroma.Web.CommonAPI.ActivityDraft

  use Pleroma.DataCase

  import Pleroma.Factory

  setup do
    user = insert(:user, local: true)

    %{user: user}
  end

  defp test_dm_addressing(from, to) do
    {:ok, draft} = ActivityDraft.create(from, %{
      status: "@#{to.nickname} hi",
      visibility: "direct"
    })

    assert to.ap_id in draft.mentions
  end

  describe "addresses mentioned user" do
    test "when no dot in name", %{user: user} do
      addr = insert(:user, local: false, nickname: "nix@example.org")
      test_dm_addressing(user, addr)
    end

    test "when dot in name", %{user: user} do
      addr = insert(:user, local: false, nickname: "not.hing@example.org")
      test_dm_addressing(user, addr)
    end
  end
end

defmodule Pleroma.Web.CommonAPI.ActivityPostTest do
  use Pleroma.Web.ConnCase, async: false
  use Oban.Testing, repo: Pleroma.Repo

  import Pleroma.Factory

  setup do: oauth_access(["write:statuses"])

  defp test_dm_addressing(conn, to) do
    resp =
      conn
      |> put_req_header("content-type", "application/json")
      |> post("/api/v1/statuses", %{
        "status" => "@#{to.nickname} hi!",
        "visibility" => "direct"
      })
      |> json_response_and_validate_schema(200)

    assert Enum.any?(resp["mentions"], fn %{"id" => id} -> id == to.id end)
  end

  describe "addresses mentioned user" do
    test "when no dot in name", %{conn: conn} do
      addr = insert(:user, local: false, nickname: "nix@example.org")
      test_dm_addressing(conn, addr)
    end

    test "when dot in name", %{conn: conn} do
      addr = insert(:user, local: false, nickname: "not.hing@example.org")
      test_dm_addressing(conn, addr)
    end
  end
end

Which might suggest akkoma-fe somehow used to send explicit addressing for DMs? But I don’t remember it doing that nor any FE change related to addressing in the last year. Am confused how this ever worked.

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Version (current develop) d96c6f438d42ccea92ba6cfa56c97ee71dfff00b ### PostgreSQL version 17 ### What is wrong? Sending a DM with a text like ``` @us.er@remote.org hi! ``` will not actually get processed as a mention of the remote user and thus _noöne_ except the author themselves is actually receiving the message. That’s because Pleroma’s `Linkify` library which we use to auto-insert clickable links, extract hashtags and extract mentions uses this, kinda restricitive regex for matching mentions: [`~r/^@(?<user>[a-zA-Z\d_-]+)(@(?<host>[^@]+))?$/`](https://git.pleroma.social/pleroma/elixir-libraries/linkify/-/blame/master/lib/linkify/parser.ex?ref_type=heads#L371) *(one can test what it detects by changing the passed `mention_handler` to print out what was found)* This affects the Bridgy setup bot `@bsky.brid.gy@bsky.brid.gy` which is how I got made aware of this (see: https://github.com/snarfed/bridgy-fed/issues/374#issuecomment-3422614199 ) So far so understandable. The really weird thing here is, back when testing the initial Bridgy interop after fixing signatures etc, I _did_ successfully exchange DMs with the bot. At this point the formatting was already kinda iffy, rendering the handle as an at-symbol followed by a link, but it still produced a `mention` in the API and thus reached the bot. I tried to bisect this but both 522a168af627f6bb1d0bbe59b75fa18aff556885 (what the HTTPSig PR was originally starting from) and 5987dd43d427151c3a59faa794d3fc50fa0056d1 (after the PR got merged) already fail the “with dot” test: <details> <summary>Elixir tests intended to bisect this</summary> ```elixir defmodule Pleroma.Web.CommonAPI.ActivityDraftTest do alias Pleroma.Web.CommonAPI.ActivityDraft use Pleroma.DataCase import Pleroma.Factory setup do user = insert(:user, local: true) %{user: user} end defp test_dm_addressing(from, to) do {:ok, draft} = ActivityDraft.create(from, %{ status: "@#{to.nickname} hi", visibility: "direct" }) assert to.ap_id in draft.mentions end describe "addresses mentioned user" do test "when no dot in name", %{user: user} do addr = insert(:user, local: false, nickname: "nix@example.org") test_dm_addressing(user, addr) end test "when dot in name", %{user: user} do addr = insert(:user, local: false, nickname: "not.hing@example.org") test_dm_addressing(user, addr) end end end ``` ```elixir defmodule Pleroma.Web.CommonAPI.ActivityPostTest do use Pleroma.Web.ConnCase, async: false use Oban.Testing, repo: Pleroma.Repo import Pleroma.Factory setup do: oauth_access(["write:statuses"]) defp test_dm_addressing(conn, to) do resp = conn |> put_req_header("content-type", "application/json") |> post("/api/v1/statuses", %{ "status" => "@#{to.nickname} hi!", "visibility" => "direct" }) |> json_response_and_validate_schema(200) assert Enum.any?(resp["mentions"], fn %{"id" => id} -> id == to.id end) end describe "addresses mentioned user" do test "when no dot in name", %{conn: conn} do addr = insert(:user, local: false, nickname: "nix@example.org") test_dm_addressing(conn, addr) end test "when dot in name", %{conn: conn} do addr = insert(:user, local: false, nickname: "not.hing@example.org") test_dm_addressing(conn, addr) end end end ``` </details> Which might suggest akkoma-fe somehow used to send explicit addressing for DMs? But I don’t remember it doing that nor any FE change related to addressing in the last year. Am confused how this ever worked. ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

Oneric added the

bug

label

2025-11-17 23:07:48 +00:00

Oneric commented

2025-11-18 15:39:08 +00:00

Author

Owner

Am confused how this ever worked.

Mystery solved. When initially enabling bridging (via a follow req) the bridge bot sends out a DM and all my test DMs to the bot were replies to this. When replying like this the bot will be addressed and mentioned even without linkify detecting any inline mentions.
Sending non-reply DMs was indeed always broken

> Am confused how this ever worked. Mystery solved. When initially enabling bridging (via a follow req) the bridge bot sends out a DM and all my test DMs to the bot were replies to this. When replying like this the bot will be addressed and mentioned even without linkify detecting any inline mentions. Sending non-reply DMs was indeed _always_ broken

Oneric referenced this issue from a commit

2025-11-18 22:09:07 +00:00

Fix mentioning of complex usernames

Oneric referenced this issue from a commit

2025-11-18 22:37:38 +00:00

Fix mentioning of complex usernames

Oneric referenced this issue

2025-11-18 22:39:42 +00:00

Fix mentioning complex usernames #1012

Oneric referenced this issue from a commit

2025-11-19 12:32:21 +00:00

Fix mentioning of complex usernames