We should investigate the feasibility of doing mentions with Markdown links, e.g.

[this user wrote](@user@domain.tld)

as mentioned on the forum.

But this should be a last priority / bonus. First, let's focus on getting the basic functionality there.

It seems that Mastodon ignores mentions in "Articles". Maybe now that mastodon has the [expand] functionality we should consider using "Note" when federating (at least up to a certain text length at least).

Hmm. Well that's good to know, but I think changing the entire post type really isn't the right solution. Do mentions work with Pleroma?

Either way, I think we should open a GitHub issue on the Mastodon repo. Maybe we could also talk to the Plume developers about what they're doing -- not sure if they support mentions or not.

I'll test with pleroma and then open the issue with mastodon. I'll also look around plume.

Just pushed branch activitypub-mentions where mentions work on pleroma.

Next step is to make the handles look like links in the rendered articles, and open an issue on the mastodon tracker.

Awesome! Sounds good.

We should probably also start a draft pull request for this, so you can link to it from the Mastodon issue.

Ok will do.

I opened an issue on tootsuite here

I'm looking into turning handles into links and I think I should link to the user on remote instances.

This requires webfinger but I think it's wasteful (and slow) to ping servers before each render. I'm thinking of three options:

1. Use js or link to an internal page that runs webfinger when the user clicks on the link
2. Add a mentions table to the database that gets populated on save and stores the handle along with the profile endpoint of each user
3. Just leave it as is and don't turn mentions into links until we see how much this feature gets used

I think people will definitely expect mentions to turn into links, so we should address that now.

#2 would be a good permanent option for the future, but I think #1 would be better in the short-term. With that internal page, maybe we add some in-memory caching of webfinger results to speed things up.

Another quick and very dirty option for the near-term would be to do what Prismo does, which is to always turn the links into: https://{domain}/@{handle} without running webfinger at all.

Just to add to #2, we should probably just leverage the remoteusers table, adding a handle column (or however we name it). That would let us look up the handle and associated actor_id.

We'd just want to be sure the row is getting fully populated (i.e., including inbox and shared_inbox columns) when we mention a remote user that isn't already in the table. So that might require another call to get the full actor data (I'm not sure without looking into the code).

pixelfed doesn't support the @user syntax (it's pixelfed.social/qwazix and not pixelfed.social/@qwazix) so I think it's not a good idea to do the prismo thing.

When posting I'm already doing that extra call so that I can get the inbox of the user to post to it so we just need to store the handle, inbox and sharedinbox at that point. Nothing else AIUI.

I think we should go for writing to remoteusers immediately. It now seems much less hassle than creating an intermediate page and in-memory caching.

Sounds good. Just some other things to note about this approach:

• This will require more database calls to render the page, slowing things down. So I think it's still worth adding an intermediate page that only does the database lookup once a user clicks the link, and then redirects them -- for example, the route could be: /users/@matt@writing.exchange, so that you could populate the <a href= directly from the mentioned handle.

• We'll need a backwards-compatible way to populate the remoteusers table with handles. I could imagine we do this lazily (only when a user does a mention) or including it in the upgrade process. But I'd prefer that it's done lazily. (Let's discuss this more once you get to this point.)

👍