Provide permalinks for topics

[gnprice]

As @CohenCyril reported at #15290:

The links (for streams, topics and messages) we obtain by clicking "Copy link"/"Copy link to conversation" in the interface, or automatically generated by "Quote & reply" are relative to the names of the stream/topic (while the id of the message stays correct), and they break when streams are renamed, when topics are moved or renamed and when messages are moved to other streams/topics. In particular, topics are moved or renamed quite frequently, by design, and when they are, all links to messages are suddenly lost, in external and internal communications, which is really problematic, ...

Our stream links were in fact already permalinks, and with #21426 our message links (with /near/) are too, by following the message to wherever it's gone.

But we also have links that are to topics without a message ID. We generate those when you click a topic in the left sidebar; in the URL bar when you're viewing a topic; and in Markdown from syntax like #**general>some topic**, which we generate for you through autocomplete. We should find a solution to make those links keep working after the topic is renamed, too -- particularly given that the resolve-topic feature causes topics to be renamed very frequently.

I think this will probably look something like: we encode into those links a message ID too, so that we can follow that message around using the same logic as in /near/ links. I.e., we'd add another narrow operator that takes a message ID, and has a slightly different meaning from near: it'd mean to find the thread where that message now is (just like for near), and then go to the first unread.

Chat thread: https://chat.zulip.org/#narrow/stream/101-design/topic/redirects.20from.20near.20links/near/1349463.2E01

#11699 has some older technical discussion that may be of limited use.

API and clients

• #api design thread: https://chat.zulip.org/#narrow/stream/378-api-design/topic/topic.20permalinks/near/1800432
• Mobile issue (current/legacy app): Generate topic links as permalinks, using /with/ zulip-mobile#5876
• Mobile issue (Flutter app): Follow /near/ links through message moves zulip-flutter#683 (for parsing links)

[zulipbot]

Hello @zulip/server-api, @zulip/server-search members, this issue was labeled with the "area: search", "area: api" labels, so you may want to check it out!

[alya]

See more recent discussion on the above thread for a concrete proposal for how to solve this issue.

[mojavelinux]

I'd like to add that another case when this comes up is when a topic is marked as resolved. As soon as the status is changed, any link to that topic that was previously shared becomes broken. That's because marking a topic as resolved effectively changes the title. I'd really like to be able to mark a topic as resolved without causing links to the topic to break since those links are often used in external locations such as issue trackers to direct people to a solution.

[gnprice]

when a topic is marked as resolved. As soon as the status is changed, any link to that topic that was previously shared becomes broken.

Yes, very much this.

Personally I avoid ever using the "link to a topic" feature, because I know those links will break if anyone resolves the topic or otherwise renames it. Instead I always link to a message.

But of course other people do use the "link to a topic" feature — after all, we offer the feature, so people are quite justified in expecting it to work. And so:

I'd really like to be able to mark a topic as resolved without causing links to the topic to break

I also avoid ever using the "resolve topic" or "rename topic" features, except when the topic is pretty new and I can hope nobody has made links to it elsewhere.

All of these are useful features. It would be good if we fixed things so that using one of them didn't break the other.

[evykassirer]

Leaving a note here that having topic IDs is the solution I'd like to see for this problem. I think that linking to a topic without any particular message (i.e. going to the bottom of the topic) is a useful feature that people would want to use.

[ojeda]

As I discussed with Mateusz, this would be useful in the Linux kernel so that links to Zulip topics can be as stable as possible, and thus useful for Link: tags (and potentially Closes: tags too) within commit messages.

[RalfJung]

In Rust we experience broken links to Zulip topics after they got renamed all the time, and I think it's fundamentally due to this issue.

[Jazzagi]

Another raised hand for topic permalinks here! 🖐️ We link to zulip threads from various other systems to join context together, some of the team use the resolve feature and some don't, but when they do any links break. We did figure out that when it happens we can add .E2.9C.94.20 to the url and it finds the resolved topic, but that's obviously less than ideal, especially if we want to use some sort of automation to update a topic.

[roanster007]

@zulipbot claim

[gnprice]

#30114 was merged to add support in the server and web app for accepting these topic permalinks 🎉

However, this issue won't be complete until we start actually generating them in each of the places in the UI where we generate a link to a topic. From the issue description above, I believe the list of those is:

We generate those when you click a topic in the left sidebar; in the URL bar when you're viewing a topic; and in Markdown from syntax like #**general>some topic**, which we generate for you through autocomplete.

[gnprice]

There are a series of follow-up tasks to #30114 listed here:
#30114 (comment)

The current plan for when to start generating these topic permalinks is (from @timabbott):

Just a reminder that the current release engineering plan for this feature is that we will not have the product start generating these for several more weeks, while we wait for end users to upgrade to the newer versions of the mobile apps that support processing these links. And we might have to wait longer if end-to-end testing discovers correctness bugs in the mobile implementations that seem important.

But nonetheless, I think it's a really important milestone to have the initial support for this included in 9.0.