Add option to use another instance than https://matrix.to for setting a link to event

[luixxiul]

The Problem

Currently the URL redirecting service (matrix.to) instance is set to https://matrix.to as hard-coded. I am not pretty sure how much it would be useful, but adding an option to specify another instance than that is possibly helpful in case where https://matrix.to would be blocked by a third party like an ISP, for example.

Fortunately a matrix.to instance can be easily set up by the MDAD playbook already.

The Solution

• Add an option to change a URL of a matrix.to redirection instance
• The default value should be https://matrix.to
• Add the option to "Network" on the settings UI?

Alternatives

No response

Additional context

No response

Happens in the latest version

• Yes, this feature is still missing.

[spantaleev]

I don't think it's too useful, though there's a real argument either way.

Looking at how Komai builds and recognizes these URLs, there are only 4 places where matrix.to URLs get emitted (event share, room share, user mention, room mention) and one place where matrix.to URLs get recognized as pills (incoming HTML processing). A configurable redirector would be a small patch on the emission side.

The catch is the recognition side. Komai's pill detection is strict-prefixed on https://matrix.to/#/. Anything else, including a custom redirector domain or a native matrix: URI, falls back to a plain <a> link with no pill styling. I suspect other clients (Element Web, Cinny, etc.) behave similarly, since pill detection is essentially everywhere convention-based on the matrix.to prefix rather than spec-driven. I haven't verified that, but the asymmetric cost is concerning regardless: if you flip your outbound redirector, every @user and #room you mention renders as a raw blue link instead of a pill for every recipient (and for yourself when you read your own messages back). That cost is paid forever, on every mention, in exchange for routing the much rarer "share link" action through a domain only you care about.

One way out would be to scope the setting narrowly: use the custom redirector only for explicit share-link actions (event share, room share copy buttons) and keep matrix.to hardcoded for mention markdown. That avoids the pill problem but adds inconsistency and a UX explanation surface for not much gain.

Also, practically speaking: as far as I'm aware almost nobody self-hosts matrix.to in the etke.cc / MDAD ecosystem this client targets. The playbook supports it, but it's not offered as an etke.cc service and there's no real evidence of demand.

A side note: digging into this surfaced two actual bugs in our existing matrix.to handling, which are now fixed on main:

1. The OS-level URL handler captured the matrix: URI but dropped it on the floor when the profile selector spawned the chosen profile, so the window raised but no navigation happened. Fixed in 7581ebed0.
2. Aliased URIs (matrix:r/#room:server, which is what matrix.to overwhelmingly emits) always popped the join confirmation even when you were already in the room. Fixed in 8e1363f8a.

[luixxiul]

It's possible that there hasn't been visible demand simply because no clients support it — a client which support it might evoke potential demand, theoretically. Anyway, I was just thinking about "Copy link to event" on the context menu, and I agree that handling https://matrix.to inside messages would be too much.

I guess a redirection service does not cost much (obviously no more than bridges do), and it is hard to imagine Element will shut it down any time soon, but still having an option in case of such event would be helpful. Just my 2c.