Page MenuHomePhabricator

Allow Wikimedians to verify their Mastodon profile with rel="me"
Closed, ResolvedPublic

Description

This is focusing on a specific usecase of a subset of T31968: Enable XFN rel=me for links on user page and rel="author" links on content pages.

Mastodon allows verifying URLs in one's profile by using the rel="me" microformat. https://microformats.org/wiki/rel-me & https://docs.joinmastodon.org/user/profile/#fields

For example, on https://blog.legoktm.com/ I have <a rel="me" href="https://wikis.world/@legoktm">Mastodon</a>. When I add my blog URL to Mastodon, it finds the link to my profile with rel="me", confirming that whoever runs blog.legoktm.com has said they are also @legoktm@wikis.world.

MediaWiki, for good reasons, does not allow setting arbitrary attributes on <a> tags. So we need a way for users to 1) specify profile link(s) and 2) annotate those links with rel="me".

The end goal is that I can put e.g. https://meta.wikimedia.org/wiki/User:Legoktm as a URL item and Mastodon will be able to verify it.

Some prior art:

Very brief discussion in the thread starting with https://wikis.world/@legoktm/109308814139458603

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Rough proposal for a MW extension:

  • As a user preference, allow the user to specify URLs that are their profile on another site
  • On the user's root userpage ("User:Example"), if any of those URLs are found, they're marked up with rel="me"

This provides a system in which only the user themselves can specify which URLs are their profile (so no one can pretend to be you by simply editing your userpage), but also that URL is still subject to the normal wiki process, since it has to be on your userpage to get the rel="me" attribute.

Rough proposal for a MW extension:

This sounds good to me. I wrote a quick proof on concept, https://git.sr.ht/~taavi/RelMe.

Ooh, nice! Quickly skimming the only red flag is $wgTitle.

Linker::makeExternalLink() optionally gets a title, we just choose not to pass it to the LinkerMakeExternalLink hook. We could add it to the hook signature? Not a huge fan of that just because Linker is icky.

Alternatively, we could add a hook in Parser::getExternalLinkAttribs() or Parser::getExternalLinkRel().

I think it would be valuable long-term to not allow link formatting hooks to vary by current page title and user preferences. I do agree with the design principles @Legoktm raised and such two-step process a good compromise, involving both consent and public visiblity/archivability.

Another way to achieve that would be via onBeforePageDisplay, using the same intersection logic (between ParserOutput::getExternalLinks and NS_USER/UserOptionsLookup), and outputting <link rel="me"> (addLink) in response, leaving the anchor links as-is.

With the current hooks available, the onBeforePageDisplay approach seems the best option to me. Done. Also requested a Gerrit repository.

Probably OutputPageParserOutput is better because it already has the ParserOutput object on hand?

And sorry for bikeshedding, is RelMe the name we want to go with? Feels jargony and implementation-specific. Maybe something like "ProfileLinks" or "MeElsewhere" (abbreviates down to "ME" :p)? "RealMe" could be some half-decent wordplay.

Change 858723 had a related patch set uploaded (by Majavah; author: Majavah):

[integration/config@master] zuul: Configure CI for ext:RelMe

https://gerrit.wikimedia.org/r/858723

Change 858723 merged by jenkins-bot:

[integration/config@master] zuul: Configure CI for ext:RelMe

https://gerrit.wikimedia.org/r/858723

And sorry for bikeshedding, is RelMe the name we want to go with? Feels jargony and implementation-specific. Maybe something like "ProfileLinks" or "MeElsewhere" (abbreviates down to "ME" :p)? "RealMe" could be some half-decent wordplay.

This is a good point. I like both MeElsewhere and RealMe.

Since a Gerrit repo was already created, I think we'll need to archive that and request a new one once we have the final name.

One use case I'd like to see supported is for organisational profiles to be able to have rel="me" as well. For example, a Contact page on a wiki should be able to link with [https://social.example.org/@account @account@social.example.org] and have it get the rel attribute. I guess these site-wide URLs would be defined in LocalSettings.php.

Also, +1 to the MeElsewhere name (although I think RelMe is fine too, and wonder if it's worth changing at this point).

Yay! Here's what it looks like so far:

Screenshot 2022-12-11 at 21-55-04 Preferences - Trunk Test.png (231×977 px, 26 KB)

First review:

  • Not a fan of the label "Profile URLs to verify:", maybe instead something like "URLs to external profiles:" and then we explain the rel=me verification part in the help text?
    • Per https://microformats.org/wiki/rel-me the standard is apparently called the "XHTML Friends Network", but I think it would be more confusing than helpful since we're just adding the rel="me" part.
  • Needs a linked mediawiki.org help page
  • Help text says it will be a meta tag, but it's actually a link tag
  • Can we use a multiselect thing like Echo's Mute preference?
  • Should there be a max limit on how many URLs can be added? Besides whatever the database blob limit size is. I'm currently leaning yes.
  • Can we add URL validation? (see my line that's like "aaaa<><><>" that was accepted)
  • Ideally we would also be able to show some kind of indicator confirming that the URL is also used on the user page and therefore active or not.

One use case I'd like to see supported is for organisational profiles to be able to have rel="me" as well. For example, a Contact page on a wiki should be able to link with [https://social.example.org/@account @account@social.example.org] and have it get the rel attribute. I guess these site-wide URLs would be defined in LocalSettings.php.

Do you want to split this into a separate ticket in the RealMe project? Agreed that it's a necessary/important use case, but I think it will end up being different than what individuals need (this task).

This is personally identifiable information btw, which means it has to be downloaded by the My account data from this project option in preferences, and might have to get disabled when we vanish users. I don't think those are immediate concerns blocking deploy, but I guess we should create tickets for it ?

This is personally identifiable information btw, which means it has to be downloaded by the My account data from this project option in preferences, and might have to get disabled when we vanish users. I don't think those are immediate concerns blocking deploy, but I guess we should create tickets for it ?

I don't think this is really PII, it seems pretty public info? But in any case, because it's stored as a user preference, it should already be included in the "My account data". And since this requires the link to also be present on the userpage to take effect, if the user page is blanked or deleted during vanishing, it will go away.

But some other questions along that line of thinking...

  • Is this a private user preference or is it OK to be exposed on wiki replicas? (Noting that the user preference alone is not enough, it also has to be on the wiki page)
  • Would we (eventually) be OK building an interface to list all Wikimedians with a URL set?

And, if we started doing 2-way verification (checking that the entered URL is also marked up with rel="me"), would our answers change?

This is personally identifiable information btw, which means it has to be downloaded by the My account data from this project option in preferences, and might have to get disabled when we vanish users. I don't think those are immediate concerns blocking deploy, but I guess we should create tickets for it ?

I don't think this is really PII, it seems pretty public info? But in any case, because it's stored as a user preference, it should already be included in the "My account data". And since this requires the link to also be present on the userpage to take effect, if the user page is blanked or deleted during vanishing, it will go away.

If you have two sets of information, this can be used to link someone between the two sets of data. Ergo, it’s PII. It being public doesn’t factor into that (names are also public), that only affects the impact and the severity of any problem/lawsuit etc.

Yay! Here's what it looks like so far:

Screenshot 2022-12-11 at 21-55-04 Preferences - Trunk Test.png (231×977 px, 26 KB)

First review:

  • Not a fan of the label "Profile URLs to verify:", maybe instead something like "URLs to external profiles:" and then we explain the rel=me verification part in the help text?
    • Per https://microformats.org/wiki/rel-me the standard is apparently called the "XHTML Friends Network", but I think it would be more confusing than helpful since we're just adding the rel="me" part.
  • Help text says it will be a meta tag, but it's actually a link tag

Proposed new messages:

{
  "realme-preference-desc": "URLs to external profiles:",
  "realme-preference-help": "Please add one URL per line. When these URLs are used on your user page, matching <code>&lt;link rel=\"me\"&gt;</code> [https://en.wikipedia.org/wiki/HTML_element HTML tags] will be added to the page, which some platforms (for example Mastodon) can use to mark profile links as verified."
}

I'll submit those to Gerrit once we've decided how public the values will be (since we might need to add a 'this is public!' warning).

  • Needs a linked mediawiki.org help page

Indeed. I'll write one.

  • Can we use a multiselect thing like Echo's Mute preference?

I tried to do that, but the UX wasn't great. Mainly since you can't modify an existing entry after it's been added so fixing a typo or similar is really annoying.

  • Should there be a max limit on how many URLs can be added? Besides whatever the database blob limit size is. I'm currently leaning yes.
  • Can we add URL validation? (see my line that's like "aaaa<><><>" that was accepted)

https://gerrit.wikimedia.org/r/904896

  • Ideally we would also be able to show some kind of indicator confirming that the URL is also used on the user page and therefore active or not.

This is a good idea, but I'm not sure how to implement that in the UI.

This is personally identifiable information btw, which means it has to be downloaded by the My account data from this project option in preferences, and might have to get disabled when we vanish users. I don't think those are immediate concerns blocking deploy, but I guess we should create tickets for it ?

I don't think this is really PII, it seems pretty public info? But in any case, because it's stored as a user preference, it should already be included in the "My account data". And since this requires the link to also be present on the userpage to take effect, if the user page is blanked or deleted during vanishing, it will go away.

Well the actual preference value does not. Do we have any automation to delete the email address for example?

But some other questions along that line of thinking...

  • Is this a private user preference or is it OK to be exposed on wiki replicas? (Noting that the user preference alone is not enough, it also has to be on the wiki page)
  • Would we (eventually) be OK building an interface to list all Wikimedians with a URL set?

This is a good question. I'm not a huge fan of making it possible to list everyone and their linked accounts. Of course there are alternative data sources for that like Wikidata, but those are incomplete and adding a new much more complete data source feels like opening yet another can of worms. On the other hand, for reasons which I will not explain here, I don't really want to add a setting which allows storing arbitrary data that can stay completely private.

And, if we started doing 2-way verification (checking that the entered URL is also marked up with rel="me"), would our answers change?

Not sure if that changes anything, but it needs to be possible to add non-verified URLs, since otherwise you end up in a catch-22 situation when adding a new URL pointing to a service that also does 2-way verification.

Will rel=me be limited to the user page, or can it also be used on a subpage of the user page?

Will it work, if the user page is a global user page?

@C.Suthorn: What's the underlying reason/idea for the first question?

A Link to this page: https://commons.wikimedia.org/wiki/User:C.Suthorn/gallery is printed on the business cards Wikimedia Deutschland e. V. issued to me. I use this page as a reference, when asking instituions for image permissions and I also link to this page from my Mastodon account.

I don't think this is really PII, it seems pretty public info? But in any case, because it's stored as a user preference, it should already be included in the "My account data". And since this requires the link to also be present on the userpage to take effect, if the user page is blanked or deleted during vanishing, it will go away.

Well the actual preference value does not. Do we have any automation to delete the email address for example?

No we don't. This is something we currently completely lack (same with real name in 3rd party installs). It's problematic and I'm pretty sure that our current iOS app is actually violating the data deletion requirements of the App Store because of this.

It's somewhat tracked in T34815 and T290099

Proposed new messages:

{
  "realme-preference-desc": "URLs to external profiles:",
  "realme-preference-help": "Please add one URL per line. When these URLs are used on your user page, matching <code>&lt;link rel=\"me\"&gt;</code> [https://en.wikipedia.org/wiki/HTML_element HTML tags] will be added to the page, which some platforms (for example Mastodon) can use to mark profile links as verified."
}

...(for example, Mastodon) use to mark profile links as verified." Otherwise LGTM.

I'll submit those to Gerrit once we've decided how public the values will be (since we might need to add a 'this is public!' warning).

I think as written, it's implied it'll be public? But more importantly it only becomes public if you put the URL on your userpage so...

  • Can we use a multiselect thing like Echo's Mute preference?

I tried to do that, but the UX wasn't great. Mainly since you can't modify an existing entry after it's been added so fixing a typo or similar is really annoying.

Hmm. I tried the cloner form field and it was pretty bad too (ignore the fact that I reused the messages):

Screenshot 2023-04-15 at 18-46-39 Preferences - Trunk Test.png (408×996 px, 66 KB)

The textarea is probably good enough for now.

Will rel=me be limited to the user page, or can it also be used on a subpage of the user page?

Currently it is limited to your root user page. I'm a bit skeptical whether we need to support subpages, but you're welcome to file a feature request asking for it, just no guarantees it'll be implemented.

Will it work, if the user page is a global user page?

Filed T334805: Support RealMe on global user pages for that.

Will rel=me be limited to the user page, or can it also be used on a subpage of the user page?

Currently it is limited to your root user page. I'm a bit skeptical whether we need to support subpages, but you're welcome to file a feature request asking for it, just no guarantees it'll be implemented.

Created [T334812]

This is personally identifiable information btw, which means it has to be downloaded by the My account data from this project option in preferences, and might have to get disabled when we vanish users. I don't think those are immediate concerns blocking deploy, but I guess we should create tickets for it ?

I don't think this is really PII, it seems pretty public info? But in any case, because it's stored as a user preference, it should already be included in the "My account data". And since this requires the link to also be present on the userpage to take effect, if the user page is blanked or deleted during vanishing, it will go away.

If you have two sets of information, this can be used to link someone between the two sets of data. Ergo, it’s PII. It being public doesn’t factor into that (names are also public), that only affects the impact and the severity of any problem/lawsuit etc.

Ack, thanks for explaining. (Though, the whole point of this in the first place is to create that link...)

To summarize, the preference value will be included in downloading "My account data from this project". When a user is vanished, their userpage should also be blanked/deleted, which will prevent any tag/link from being emitted publicly. At that point it's still stored privately as a user preference, which will eventually be cleaned up by T290099.

Does that seem adequate? Just want to confirm that you still agree with T322717#8737983; that this is not a blocking issue.

Does that seem adequate? Just want to confirm that you still agree with T322717#8737983; that this is not a blocking issue.

Let's make a ticket (as this is going to be an extension and can otherwise easily go unnoticed). Then I'm ok.

Change 921331 had a related patch set uploaded (by Majavah; author: Majavah):

[mediawiki/extensions/RealMe@master] i18n: Add link to help page

https://gerrit.wikimedia.org/r/921331

Change 921150 had a related patch set uploaded (by Legoktm; author: Majavah):

[mediawiki/extensions/RealMe@wmf/1.41.0-wmf.9] i18n: Add link to help page

https://gerrit.wikimedia.org/r/921150

Change 921331 merged by jenkins-bot:

[mediawiki/extensions/RealMe@master] i18n: Add link to help page

https://gerrit.wikimedia.org/r/921331

Change 921150 merged by jenkins-bot:

[mediawiki/extensions/RealMe@wmf/1.41.0-wmf.9] i18n: Add link to help page

https://gerrit.wikimedia.org/r/921150

Mentioned in SAL (#wikimedia-operations) [2023-05-19T15:09:38Z] <taavi@deploy1002> Started scap: Backport for [[gerrit:921150|i18n: Add link to help page (T322717)]], [[gerrit:921326|Enable RealMe (T324535)]]

Mentioned in SAL (#wikimedia-operations) [2023-05-19T15:21:10Z] <taavi@deploy1002> legoktm and taavi: Backport for [[gerrit:921150|i18n: Add link to help page (T322717)]], [[gerrit:921326|Enable RealMe (T324535)]] synced to the testservers: mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2001.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-05-19T15:31:40Z] <taavi@deploy1002> Finished scap: Backport for [[gerrit:921150|i18n: Add link to help page (T322717)]], [[gerrit:921326|Enable RealMe (T324535)]] (duration: 22m 02s)

Change 926854 had a related patch set uploaded (by Reedy; author: Majavah):

[mediawiki/extensions/RealMe@REL1_40] i18n: Add link to help page

https://gerrit.wikimedia.org/r/926854

Change 926854 merged by jenkins-bot:

[mediawiki/extensions/RealMe@REL1_40] i18n: Add link to help page

https://gerrit.wikimedia.org/r/926854