Define a routing table for Thorium domains (2 TLDs + one currently used SLD)

[panaC]

• thoriumreader.fr
• thoriumreader.com
• thorium.edrlab.org

I strongly suggest not using any subdomain under thoriumreader.{fr,com} as a redirect target, but only as DNS entries for real, separate services.

I suggest automatically redirecting thoriumreader.fr to thoriumreader.com/fr/.

I also suggest adding the www subdomain (www.thoriumreader.{fr,com}) for the main website, and then redirecting all thorium.edrlab.org URLs to www.thoriumreader.com.

Finally, I suggest defining fixed and immutable shortcut routes for frequently used links that may change over time, such as the Discord invite or the “screen reader learn more” page on thorium-desktop. Some more routes may be added later for API-APP, OPDS, edrlab. We have to keep in mind that once a URL is shipped in a software product, it must continue to work.

[panaC]

According on #10, #12, and this issue.

I suggest implementing a Top-Level Router as a reverse proxy to handle all incoming requests from Thorium Reader website domains.

This router should be the single entry point for:

• thoriumreader.com
• www.thoriumreader.com
• thoriumreader.fr
• www.thoriumreader.fr
• thorium.edrlab.org

The goal is to centralize domain routing, redirects, and stable shortcut routes in one place, instead of spreading this logic across the app, the website, or DNS-only configuration.

The Top-Level Router should:

• redirect all website domains to the canonical domain
• preserve path and query parameters
• redirect thoriumreader.fr to the French website
• redirect legacy thorium.edrlab.org URLs to the canonical website
• expose fixed shortcut routes for URLs shipped in Thorium apps
• keep those shortcut URLs immutable, even if their final target changes later

From this canonical URL:

https://www.thoriumreader.com

We do:

https://thoriumreader.com/* -> https://www.thoriumreader.com/*

https://thoriumreader.fr/* -> https://www.thoriumreader.com/fr/*

https://www.thoriumreader.fr/* -> https://www.thoriumreader.com/fr/*

https://thorium.edrlab.org/* -> https://www.thoriumreader.com/*

For examples:

https://thorium.edrlab.org/download/?lang=fr&os=windows -> https://www.thoriumreader.com/download/?lang=fr&os=windows or to be defined with the final implementation of this repo website.

https://www.thoriumreader.com/discord -> to the current Discord invite
https://www.thoriumreader.com/screen-reader -> current screen reader learn-more page

The implementation must be done at the reverse-proxy / edge-router level, probably not in client-side JavaScript, so redirects are resolved before the website is loaded.

This also ensures that once a URL is shipped in Thorium apps it keep working without requiring an application update.

Ref: edrlab/thorium-reader#3594

[panaC]

Useful reference to support Apple Universal Link https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12-SW1

[panaC]

A practical option would be to introduce a controlled routing layer in front of the existing services, rather than relying only on DNS-level routing or individual redirects.

This could be implemented as a reverse proxy / ingress, for example with Nginx, Caddy, or Cloudflare Workers.

The goal would be to expose stable public URLs for Thorium-related resources, while keeping the actual backend targets independent from those URLs.

Such a routing layer would allow us to:

• define canonical URLs for the different Thorium domains;
• maintain stable deep links used by applications, documentation, or external references;
• route requests to different backends depending on the path or hostname;
• preserve compatibility when hosting, infrastructure, or website structure changes;
• centralize and version-control the routing rules.

This would make the public URL structure more predictable and easier to maintain over time, while still allowing internal services and hosting choices to evolve.

[llemeurfr]

The URLs included in Thorium Reader must be stable over time. Some of them point to web pages that MAY change over time, e.g. documentation, download pages etc.
The edrlab.org domain is the most stable one we can imagine (even in thoriumreader.com/fr has a good chance to stay also).
We'll rely on it then it Thorium Reader, using the thorium subdomain.

We'll use canonical & semantic URLs; these URL SHOULD be fine-grained, because it is easier to map 3 URLs to one than 1 URL to 3.

Examples:

• thorium.edrlab.org/download/windows
• thorium.edrlab.org/download/ios
• thorium.edrlab.org/discord/desktop (as we are sure that we will not split this in windows/macos/linux sections)
• thorium.edrlab.org/discord/ios

[panaC]

thorium.edrlab.org/discord/desktop
I didn't think a redirect to Discord would allow specifying a channel even after authentication, but I'm probably wrong. I was thinking more a short and invariant link to a Discord invitation or any social invitation link.

[llemeurfr]

@panaC, it was an example. Please tweak to get something that works.

[HadrienGardeur]

You can invite to a specific channel on Discord but this requires a separate invitation code.

[llemeurfr]

I see mention of query parameters in some issues. Not sure about the context, but here, we should avoid query parameters in favor of semantic urls.

[panaC]

We should use 3 distinct application identifiers:

• org.edrlab.thorium.desktop
• org.edrlab.thorium.web
• org.edrlab.thorium.mobile

Using the EDRLab domain namespace makes sense and keeps ownership centralized.

We could also standardize the related URLs/subdomains like this:

• desktop.thorium.edrlab.org → thorium.edrlab.org/desktop → www.thoriumreader.com/desktop
• web.thorium.edrlab.org → thorium.edrlab.org/web → www.thoriumreader.com/web
• mobile.thorium.edrlab.org → thorium.edrlab.org/mobile → www.thoriumreader.com/mobile

Additional shared endpoints:

• thorium.edrlab.org
• thorium.edrlab.org/download
• thorium.edrlab.org/social

I would avoid using /discord directly in the app-facing URLs, since it exposes a third-party brand/provider in our public routing. A neutral endpoint like /social is more future-proof and allows us to change providers later without impacting integrations or documentation.

[llemeurfr]

My comment at this point is that the app identifier issue is separate from the issue of embedding stable URLs in the code for "target URLs" that may move in time.

Which "targets URLs" do we have to take into account?

• Some will be independent from the variant of Thorium, e.g. social platform (Discord), user-support platform (Zenhub)
• Some will be dependant of a type of Thorium app -> desktop, mobile, web. Release notes come to mind.
• Some may end up being dependent on the OS -> Windows-specific links, or iOS vs Android. Download links come to mind.

[HadrienGardeur]

Here's a summary of what I have in mind right now:

• thoriumreader.com is our main domain for everything that we do related to Thorium Reader
• www.thoriumreader.com serves our product website and is also used for deep-links (add a catalog) and callbacks (OAuth)
• support.thoriumreader.com points to Zendesk where we handle all support-related matters
• blog.thoriumreader.com points to Ghost, which we use both as a blog and for newsletters
• web.thoriumreader.com would be a future deployment of Thorium Web with additional branding

For www.thoriumreader.com we always prioritize real URLs and fragments over query parameters.

Our main URLs so far are:

• www.thoriumreader.com
• www.thoriumreader.com/download
• www.thoriumreader.com/release-notes
• www.thoriumreader.com/release-notes/desktop

Our WIP based on Astro can already handle multiple languages and redirects, this means that if you go to www.thoriumreader.com/download with a browser that sends French as its preferred language, you'll get redirected by Astro to www.thoriumreader.com/fr/download

On the download page, we'll provide anchors for the different apps and platforms:

• desktop
  • windows
  • macos
  • linux
• ios

So, if we want to point a user to a download page for Windows, we can point them directly to www.thoriumreader.com/download#windows and they'll get links and instructions for Windows translated in their preferred language.

For Discord, I wouldn't do anything right now. If we ever reach 1000+ users, we could request to become a public server and replace the current invite. But in the meantime it's fine as-is.

For historical and additional domains, they should IMO be redirected to www.thoriumreader.com with a permanent redirect in HTTP.

This means:

• thorium.edrlab.org -> www.thoriumreader.com
• thoriumreader.fr -> www.thoriumreader.com

We might also consider mapping additional existing URLs to the new ones. For example thorium.edrlab.org/en/th3 could redirect to support.thoriumreader.com.

In terms of integration into apps, they should use the following ones IMO:

• Website: www.thoriumreader.com
• Support: support.thoriumreader.com (already included on mobile)
• Blog: blog.thoriumreader.com (already included on mobile)

I don't think that apps should do anything related to language, let Astro and Zendesk do their own job.

[llemeurfr]

Working on a consensus...

Hadrien promotes the direct use of thoriumreader.com as a stable domain. It is true that we commit to keeping this domain name as an EDRLab asset. Therefore, we can rely on it.

There is an issue with the strong reco to target www.thoriumreader.com now: this website is still in development and therefore not active yet. For the short term, we can put in place a redirect from this url (embedded in Th Dsk 3.5) to thorium.edrlab.org, and reverse the redirect when the www.thoriumreader.com can really replace the current website (so Th Dsk 3.4 users are not lost).

The other URL embedded in Th Dsk 3.4 is the invalid Discord link. There is no way to make it work now. Too bad.
In Th Dsk 3.5, I propose replacing it (on the welcome screen) with blog.thoriumreader.com.
And keep the current link to the website (which is the same as the "About" link at the bottom of the home screen, I guess).

Inserting support.thoriumreader.com in the welcome screen makes no sense, in my opinion. Problems come later.
We can still add this link to the Preferences (it has a label "Help & Feedback" in Th Mobile).

A prominent link to ZenDesk from the future www.thoriumreader.com also makes sense.

[HadrienGardeur]

We'll deploy https://www.thoriumreader.com next week and I think that this should also be the opportunity to publish release notes for Thorium Desktop 3.5 on it as well.
We can discuss it next week @llemeurfr but I believe that with 3.5, Thorium Desktop should move to compact release notes published in the Microsoft Store and the main website, plus a blog post focusing on new features rather than release notes.

For my suggestions, I wasn't talking about a welcome screen (and I have mixed feelings about such screens in general). In the case of Thorium Mobile, we include these links in our settings/about pages.

For Discord, I can check with Jiminy if we can easily set up a redirect in Astro, if so we could also roll out https://www.thoriumreader.com/discord