Hi @schoenbaechler @JTannerWMF this is what I could deduce from the spike. please review :)

When we are viewing a diff page, we are trying to see if there is any activity on the user's talk page related to that edit.

In the particular case of a revert, there can be 2 cases:

1. The patroler reverted the edit, and left a talk page message
2. The patroller reverted but did not leave any messages on the user's talk page

So when showing diff of a revert, what is technically feasible is to:

-> look at the timestamp, and see if the revert happened within 24hrs [or whatever we set the limit to determine if it is recent] -> Get any messages from user talk page in that time frame and pick the latest one, check if that message is from the patroller, and display in a bottomsheet -> Can be replied to from the bottom sheet.
Note: There is no api directly tying a revert to a talk page message.

Things to think about would be:

• We will need to think of an elegant way to refresh that latest message in case the patroller responds in real time. I can think of 2 ways - when we receive a notification, process it in the background to see if it is related to this talk page and refresh our bottomsheet, which is tedious, or, poll every few seconds.

• Other than in the case of notifications, there is no way for us to know if we are looking at a reverted edit's diff - We might have to deduce it by parsing the edit comment for the first word to be "Undo", and hope the patroller has not overwritten the default revert comment.

• Just stating the obvious for completion - Nothing is shown if no message is left on the user's talk page

• On the edge case that the revert and message are not related, it will not make much sense.

@schoenbaechler @JTannerWMF Moving this to code review to get your feedback.

Great summary @Sharvaniharan 👏 I suggest to move forward with this and create actual designs and specs for it (in a new task), based on your findings.

Have you created this task already @schoenbaechler or do you want me to do it?

@JTannerWMF @schoenbaechler Just had a brief discussion about the timestamps on talk message apis with @MattCleinman
Before we get ahead on this, just wanted to bring this up that my solution to this fully depended on getting a timestamp for every talk page message, and even after that there were a couple hacky steps... Currently, we get the timestamp as part of the message text, and it is almost impossible to parse it out of that text, and looks like it might not be possible to get it as a separate field in the api response, so this might not be feasible ... sorry to get the hopes up for a bit there 😓

I agree w/ Sharvani. I *love* these designs, but it seems like beyond what we can do with the existing APIs.

We need some way to associate a talk page message with a specific revert. There are many ways this could happen:

• The message is associated with a specific revert (or vice versa) in the API response. This is what we'd expect ideally, but it's not there.
• The message mentions a specific revert, and we can parse that message. This is very brittle and prone to breakage. It's also likely there would be the occasional false positive, where we show people the wrong message. It would also often fail, and require us to make additional calls (to get up to date talk page for both the user and the article) when showing a revert from a notification, and I'd question whether this resource/battery drain is worthwhile, given that in many/most cases we wouldn't have anything to show (because no talk page message mentioned the specific revert.)
• Some way of associating a revert with a talk page comment, based on similar time stamps. This is very brittle, involved us calling a lot of data, and making a lot of assumptions. I'd expect this to break often. Especially because we don't get a well structured time stamp for talk page messages - It's often included when someone signs a page, but this looks different in many languages.

Given the number of sketchy things we have to do to go this route (without server support), it seems not worthwhile to spend a lot of time building this in a brittle way that likely won't fully work (especially in all languages), and likely will have maintenance issues over time. I truly love this feature idea, but I don't think we should build it purely in the Android app w/o a bunch of server support.

Thanks @Sharvaniharan and @MattCleinman for all the details. This has been very helpful.

We need some way to associate a talk page message with a specific revert.

👉 We don’t need to associate a specific revert with a talk page message.

How feasible is the following, “minimal viable product” version, of the concept, in which:

• We would “just” need check if User A received a message from User B recently and display a snackbar (or yellow infobox) in the diff view.

• The snackbar could say that there’s a message (on their talk page) that might be related to this revert.

Here’s a journey to exemplify it:

1. User A reverts an edit of User B
2. User A leaves message on the talk page of User B.
3. User B taps on the revert notification and is taken to the diff view.
4. On the diff view screen, User B sees a snackbar (or yellow infobox) that says User A has left a new message on your talk page recently with a View CTA (we can write the UX copy of the message pretty generic)
5. User B taps the View action and is taken to their own user talk page.

TL;DR, the MVP features:

• A snackbar (or yellow infobox) on the diff view that checks if the “author” (User A) of this revert has left a message on the user’s talk page (User B) recently
• The revert does not have an association with a talk page message
• No direct reply functionality, just a link to the user’s own talk page

Thank you @Sharvaniharan @schoenbaechler and @MattCleinman for the investigation and creative thinking on addressing this problem.

Our next steps are:

1. Backend ticket (@MattCleinman )- place in backlog with the understanding it’s not anything that’ll probably be fixed anytime soon
2. Front end workaround ticket (@MattCleinman )- a ticket for our team to tackle the approach you have in mind and place it in Ready for Dev
3. Improve Summaries ticket (@JTannerWMF - I’ll file a ticket for Robin and I to think through how we can improve the summary guidance for people making edits/reverts AND how said summary can be displayed more clearly

Once these tickets have been created I will close this one

For #1: https://phabricator.wikimedia.org/T296979

For #2: https://phabricator.wikimedia.org/T296976. I filed this as the under the hood work - and I filed a separate ticket for the UI work (https://phabricator.wikimedia.org/T296978). This latter UI ticket needs mocks added, and I wasn't sure where the most up to date ones were. Can @JTannerWMF or @schoenbaechler handle updating it with images and any verbal details that are important?)

Thanks everyone for the group work on this. I spoke with @Dbrant and I think he wants to do some thinking around it and chime in so I will leave this in my column until he does.

We have exhausted doing this in a hacky way technically so we will revisit the designs to solve the problem of someone getting a revert message and possibly getting a talk page message as well. We should ensure our current designs don't promote the behavior of a discussion of edit taking place on two users talk page at the same time.