Whenever we use a fediverse user style reference to a user, but the server name is a well known off-site server, we should create a link to that person.
For example,
@[email protected] should create a clickable link to http://twitter.com/@user
@[email protected] should create a clickable link to http://soundcloud.com/user
etc.
We could setup mappings for "well known services" and enable us to have consistent links to non-fediverse users.
While we all certainly have our issues with those corporate networks, we do know a lot of people on those networks. Having a clean and consistent way to reference them would make it a little easier to reference them in a post and make it easier to understand and read posts crossposted from those services.
What purpose would this serve vs. linking to their profile URL? For one, it would mean Mastodon would have to start keeping track of arbitrary services and their URL schemas. For another, it would be confusing since those are not real accounts on the network.
See also: #1849
It's another way to link to a profile that is consistent with profile-linking conventions in the fediverse, is in harmony with the fediverse philosophy of maximum interlinky goodness, people already use it all the time (especially for @[email protected]
), the only reason to avoid it is to spite Twitter. (It's not confusing if you leave the @website.com
on the end for non-fediverse sites, because people would learn fast that if you can see the second part of the handle then it'll open the profile in a new tab.) It means you don't have to go look up whether a profile is linked twitter style (twitter.com/person) or tumblr style (person.tumblr.com) or some other weird way (site.com/@person etc).
It's one thing to say you want to link to Twitter in a more "native" way. But once you start asking for other services to be supported, you now have to keep track of how every single proprietary service formats its URLs. Attempting to force everything into a @[email protected]
format doesn't exactly work without the translation layer that maps the fake mention to a real URL. There's enough complexity that you might as well just use the real URL directly.
Really, at its core, the usage of @[email protected]
within Mastodon implies that a Webfinger lookup will be successful, because that's what happens when you type something yourself that looks like a mention into the compose box and make a post via the API -- the server then does a Webfinger lookup and converts the mention to ActivityPub ID + inserts the HTML link. Networks like Twitter, Instagram, Soundcloud, etc. do not use Webfinger and would therefore be untranslatable by default.
There are already enough challenges with Mastodon supporting "pure" ActivityPub implementations that don't use Webfinger and instead use HTTP(S) URIs. I think those are more worthy of being solved before Mastodon starts having to store dozens of mappings for proprietary networks on top of that.
Entire projects like https://activitypub.actor were formed to try to fake the Webfinger lookup, because it's non-trivial. Asking for generic mention support in this way is basically the same as asking to integrate activitypub.actor into Mastodon's logic. It'd actually be much easier to allow users to define custom inline links/mentions.
It'd actually be much easier to allow users to define custom inline links/mentions.
Like writing https://twitter.com/user
instead of @[email protected]
:eyes:
We could setup mappings for "well known services" and enable us to have consistent links to non-fediverse users.
Managing a mapping isn't that hard but why legitimize/advertise those propritery services many of which are our competitors? Especially when good old URLs are a neutral way of accomplishing the same thing. It's not like a mapping like that will allow Mastodon users to notify people on those platforms, or open their profiles within the Mastodon UI. "Mentions" have those connotations, whereas plain URLs do not.
I wonder if there's a way to break down the walls of those walled gardens, by allowing Mastodon users to follow those links into Mastodon-wrapped versions of the proprietary actors and react to them.
It would probably violate their ToS though (although if you don't have a twitter account can you really violate their ToS, by reading the public page through custom software/a wrapper webpage?).
Mapping @[email protected] as a Twitter link is a bad idea because users may not be aware that they are actually going to Twitter. They will need to hover a long time to see the title
tip. And Mastodon mention suppose to open the collumn profile not to open a new page. In Twitter.Activitypub.actor I did not implement an automatic redirection because users may not want to use Twitter at all. If u are trying to escape from GAFAM services, you may not want to go to these websites at all. It a matter of privacy. Implementing a link as profile mention, is a very bad idea because it didn't respect this right.
Having a clean and consistent way to reference them would make it a little easier to reference them in a post and make it easier to understand and read posts crossposted from those services.
I think that it may be a good idea to support custom hyperlinks (for example: Google), but I do not think that usernames should be specifically supported as described in this issue. If users want to format usernames with @ handles (for example: @[email protected]
) then custom hyperlinks would allow that, but as has been mentioned several times... supporting non-federated usernames is misleading and would require the devs to understand countless non-AP username schemes.
I'm closing this as duplicate of #1849 since the reasoning for rejecting it hasn't changed.
Most helpful comment
Managing a mapping isn't that hard but why legitimize/advertise those propritery services many of which are our competitors? Especially when good old URLs are a neutral way of accomplishing the same thing. It's not like a mapping like that will allow Mastodon users to notify people on those platforms, or open their profiles within the Mastodon UI. "Mentions" have those connotations, whereas plain URLs do not.