Add support for `fediverse:creator` OpenGraph tag #30398

Gargron · 2024-05-22T17:44:31Z

A new OpenGraph tag to highlight article writers and website creators on Mastodon. Putting <meta name="fediverse:creator" content="username@domain" /> on a web page will allow Mastodon to link directly to the fediverse account from the preview card card, like so:

This will highlight journalists that actively use Mastodon and help them cultivate an audience on the platform that is independent of their publisher. To prevent potential abuse (malicious websites could "frame" unknowing users by listing them as authors) this feature will only be available to publishers that have been approved for trending by each server's moderation team.

Fixes MAS-246

shleeable · 2024-05-22T23:55:34Z

This deeply rules.

trwnh · 2024-05-23T04:09:08Z

Is this property="fediverse:creator" defined or documented anywhere, or is it something being invented purely for/by this PR? It seems like the kind of thing that requires more thought... Also, the use of a pseudo-prefix is a bit weird, and it was just as weird when Twitter did it. Also pertaining to that, there are some conceptual issues with claiming the "fediverse" prefix and mapping it to a bare username@domain. It might make more sense to use a mastodon or toot prefix and use @username@domain instead, or otherwise consider supporting specifying the user by id instead of by Webfinger address (especially if Webfinger is to ever become optional per #17030 or similar). Also also: the usage of property is inappropriate for this, and name should be used; this is because name is defined for <meta> tags in HTML5 whereas property is defined for any element by RDFa, and if you're going the RDF route, then you would ideally need to define an RDFa prefix in order to avoid the unfortunate situation where naive parsers look for og: as a literal prefix and don't actually understand that it is a prefix (e.g. not understanding that http://ogp.me/ns# is equivalent).

Gargron · 2024-05-23T04:26:36Z

Mastodon supports both property and name. That's not really integral to the feature. But GitHub still uses property on this very page, so it's not such a far reach to use as an example in a PR description.

trwnh · 2024-05-23T04:38:45Z

Mastodon supports

This is about more than just Mastodon, though. It's about the underlying standards of HTML (which defines name on <meta>) and RDFa (which defines property on any element). It's also to a lesser extent about namespacing and what fediverse: is supposed to map to if anything, which is expected when using property but not so much when using name.

Basically either:

Opt out of RDFa and use <meta name="mastodon:creator" content="@username@domain" />
Opt into RDFa and use <meta property="http://joinmastodon.org/ns#creator" content="@username@domain" /> or otherwise use something of the form <meta property="toot:creator" content="@username@domain" prefix="toot: http://joinmastodon.org/ns#"/> (or put the prefix attribute on the wrapping element, i.e. <head>)

And also consider:

Allowing or defining name="mastodon:creator:id" (similar to Twitter's twitter:creator:id) pointing to an ActivityPub id, or otherwise using an equivalent RDFa property pointing to an ActivityPub id

Given that the inspiration for this feature seems to be the Twitter Card Preview markup, I'd be inclined to recommend opting out of RDFa and using the name attribute with a value of mastodon:creator and mastodon:creator:id. (I'm a bit wary of using fediverse:creator because the terms and their names and expected content-values are really being defined by Mastodon here.)

renchap · 2024-05-23T07:36:59Z

The goal here is for this to become widely used, and not only specific to Mastodon. There is nothing specific to Mastodon here, so we do not want to use the mastodon: prefix. We could write a specification for this, but I am not sure where it should be published? OpenGraph is not specified anywhere, ogp.me's repo has been archived.

We considered using the activitypub prefix, but this is less explicit for people not knowing about ActivityPub, where Fediverse is the name being pushed a lot lately by many actors.

tsmethurst · 2024-05-23T08:02:00Z

Will this be documented somewhere?

trwnh · 2024-05-23T08:11:55Z

We could write a specification for this, but I am not sure where it should be published? OpenGraph is not specified anywhere, ogp.me's repo has been archived.

Either in Mastodon's documentation (/spec/link-preview-meta or similar) or as a FEP or really just anything more than a random PR with no discussion consensus or agreement by the broader "fediverse" community. Also https://ogp.me is the documentation for OpenGraph, even if the repo is archived.

The goal here is for this to become widely used, and not only specific to Mastodon. There is nothing specific to Mastodon here, so we do not want to use the mastodon: prefix [...] We considered using the activitypub prefix, but this is less explicit for people not knowing about ActivityPub, where Fediverse is the name being pushed a lot lately by many actors.

activitypub: would probably be strictly worse, yes, but I still don't think fediverse: is ideal either. I understand the goal, but it is still being defined entirely by Mastodon in the same way that twitter:* meta tags are still used by numerous parties other than Twitter -- for example, the presence of twitter:card = summary_large_image is used by Discord, which is a completely separate entity from Twitter, in order to determine that a "large" image preview should be shown instead of a smaller one. So does Telegram, which is also a completely separate entity from Twitter.

The real "ideal" would be to have this kind of thing defined by a broad consensus or consortium in the same way the OpenGraph Protocol was standardized by Facebook, but failing that, it's okay to have it be specified by Mastodon as a project as long as it's called mastodon. Again, the reason I'm wary is because it sets a bad precedent if anyone can just define a new thing using the fediverse: pseudo-prefix, and ultimately a lack of cohesion for the ecosystem as a whole. But mastodon: is less likely to lead to such conflicts, because Mastodon is a clearly-defined entity.

ClearlyClaire

I like the idea and I like how it looks!

However, shouldn't we worry about this being devoid of verification? One way this could be abused is: write an outrageous piece, and have it claim to be authored by your victim, then share it on the fediverse. Onlookers will see the preview card with a direct link to the victim, who they can easily direct outrage towards. The article can also be shared in good faith by people who are not aware that it was not written by the claimed author.

On the technical side, this looks good, although:

I agree with @trwnh on the technical aspects of meta tags property VS name and namespaces, and I also agree with them that if we go with something generic like a fediverse or activitypub namespace, we should use the actor ID rather than a webfinger acct. There is also no real downside to using this for a Mastodon-specific namespace.
this is pretty minor, but I think there's a possible N+1 in app/controllers/api/v1/conversations_controller.rb

renchap · 2024-05-23T09:56:02Z

we should use the actor ID rather than a webfinger acct. There is also no real downside to using this for a Mastodon-specific namespace.

There is a usability issue here. You can not expect a user to know their actor ID. If we want CRMs and other publishing software to implement this, any author should be able to easily add their "profile" in a field, then have the tag appear on their publications. And we can not ask every CRM to support webfinger to get the actor ID either, otherwise this will never be used.

ClearlyClaire · 2024-05-23T12:24:21Z

However, shouldn't we worry about this being devoid of verification? One way this could be abused is: write an outrageous piece, and have it claim to be authored by your victim, then share it on the fediverse. Onlookers will see the preview card with a direct link to the victim, who they can easily direct outrage towards. The article can also be shared in good faith by people who are not aware that it was not written by the claimed author.

Thinking more about this I can think of a few ways forward:

a strong, heavy-handed verification mechanism, either using public-key cryptography or explicitly listing articles somewhere: this adds a lot of complexity, to the point this would probably not get traction anywhere
a compromise where article authors write somewhere on their Mastodon profile domains where articles from them are expected to be published (similar to aliases or verified links): this does not require additional complexity on the external site, and is easy to explain, but does still add overhead that would hinder adoption
have the UI clearly reflect that there is no verification being performed, and the author information could be falsified

we should use the actor ID rather than a webfinger acct. There is also no real downside to using this for a Mastodon-specific namespace.

There is a usability issue here. You can not expect a user to know their actor ID. If we want CRMs and other publishing software to implement this, any author should be able to easily add their "profile" in a field, then have the tag appear on their publications. And we can not ask every CRM to support webfinger to get the actor ID either, otherwise this will never be used.

That is a good point. I'd be in favor of Mastodon supporting both webfinger acct and ActivityPub actor ID then, with the documentation/specification spelling it out.

andypiper · 2024-05-23T14:13:27Z

I love this feature addition (and I discussed it with @Gargron in person when it came up as an idea).

My own previous experience with Twitter Cards and OpenGraph is useful here. I think @ClearlyClaire has captured the need for more thought on user validation very well.

On the choice of tag: OpenGraph wasn't exactly a standard, but it was invented by FB and very widely adopted, so much that in the end, Twitter Cards markup was essentially folded in on top of it (fun fact, if you have a right basic og: tags but no twitter: tags, then Twitter will - or would, no idea of current status - render a summary card anyway, since they figured out that you end up with more rich previews if you just use the FB markup without requiring the publisher to have Twitter-specific tags). OG is essentially abandoned as a thing, as I discovered a few years back - it's just sort of "out there".

We absolutely did think about how to label this property before coding it (so, landed on fediverse). We haven't yet gone through any of the related processes to socialise it more widely, but I'm open to going in that direction for broader adoption; FEP might be a way forward on that.

Appreciate the various perspectives shared in comments to this PR. One approach may be to test this out in nightlies on mastodon.social and see how things go.

ClearlyClaire

If my understanding is correct, the chosen solution for the impersonation issue has been to bind that feature to the article's publisher being approved for trends by a moderator (/admin/trends/links/publishers).

If so, I think this reduces the risk, but I'm not sure the two purposes are sufficiently close for moderators to be able to make the right call.

In addition, this approach has a minor issue where the information will only be processed for preview cards created after a provider gets approved.

Apart from that, it looks fine to me.

shleeable · 2024-05-29T01:17:50Z

Follow up question: Could we build an official repo of "approved publishers"? People can PR lists of providers who are known safe, and it would be sync'ed... or more specifically.. we can make a list of publishers who are using the flag correctly.

ClearlyClaire · 2024-05-29T09:06:23Z

I am still really not convinced this is the correct approach to avoid impersonation. I think having the author make a list of domains that are authorized to advertise as authors make more sense, even if it's a little more work for the author itself.

Indeed, the author is the probably the best placed person to make the decision, and this would not require every moderator to do duplicate work to make the right call.

If the server stores the account reference and whether it was verified as two different pieces of information, the UI could display to the author something like “Are you the author? Add publication.example.com to the sites allowed to advertise authorship” (needs workshopping but you see the idea) or “Not the author? Remove publication.example.com from your allowed list of publications” to nudge the author towards the feature.

trwnh · 2024-05-29T10:13:09Z

We absolutely did think about how to label this property before coding it (so, landed on fediverse)

I still think it's a red herring to say that it should be called fediverse because you intend for it to be widely used. It's not about how widely it will be used; it's about the authority to define things within a namespace. OpenGraph is namespaced to the OpenGraph domain because it's defined by OpenGraph. Twitter Cards are namespaced to twitter: because they are defined by Twitter. Consequently, meta tags introduced by Mastodon ought to be namespaced (if they are to be namespaced at all) to something under the control of Mastodon, in the same way that JSON-LD properties introduced by Mastodon are namespaced to the joinmastodon.org domain.

There is a usability issue here. You can not expect a user to know their actor ID. If we want CRMs and other publishing software to implement this, any author should be able to easily add their "profile" in a field, then have the tag appear on their publications. And we can not ask every CRM to support webfinger to get the actor ID either, otherwise this will never be used.

This can be solved in several ways:

Implementing a tag similar to twitter:creator:id that accepts id instead of user@domain
Having Mastodon do a resolve/WebFinger on the current tag's content-value
Provisioning profile URLs so that they redirect to the id when requested with the appropriate Accept header (the user is expected to know their own profile URL, right? or so one would hope...)

But again, this is kind of the point I'm getting at -- Mastodon is the one defining what the tag's content-value should be and how it will be used. Whatever you end up going with, it's being specced out by Mastodon. You can't authoritatively constrain the behavior of something that is fediverse in the same way that you can do so with mastodon.

Aside from that I think the feature does need more thought. The purpose seems clear (Mastodon wants to show the author's account underneath the preview card), but the semantics and mechanics of this are still unclear in a way that can't be said about OpenGraph or Twitter Card. It looks like it only works if you do user@domain and NOT @user@domain or acct:user@domain or https://domain/@user or https://domain/users/user, correct? And there's still the concern of verifying the claim as Claire brings up, which has been mitigated but not solved.

see: * https://wordpress.org/plugins/opengraph/ * https://codeberg.org/fediverse/fep/src/branch/main/fep/XXXX/fep-XXXX.md * mastodon/mastodon#30398

renchap · 2024-06-20T19:43:39Z

Is it being considered to add a mechanism that allows manually approving smaller websites that are less likely to be trending? Any chance to automatically approve websites with articles that list an admin of an instance as the creator?

Yes, but we have not defined it yet. We went with the trusted publishers for trends to be able to launch the feature quickly and start having adoption by publishers.

Hi, is this listed in the Mastodon documentation anywhere?

Not yet

Is there any way for a publisher (hello) to get approval? Regardless of answer, that should be noted in the documentation too.

Approval is done locally for each instance, using the trusted publishers system from trends. This will change at some point (see the answer above).

Have added support for it to articles on GamingOnLinux, so curious to see how it ends up looking.

This domain is already allowed for trending on mastodon.social, so posts with a link preview from the domain should show the author now.

pfefferle · 2024-06-22T04:30:34Z

To prevent potential abuse (malicious websites could "frame" unknowing users by listing them as authors) this feature will only be available to publishers that have been approved for trending by each server's moderation team.

Why not use the rel-me method (that is already used for link verification) to auto-enable the feature on a user basis?

renchap · 2024-06-22T08:15:17Z

Why not use the rel-me method (that is already used for link verification) to auto-enable the feature on a user basis?

How would this work?

pfefferle · 2024-06-22T11:35:04Z

How would this work?

Mastodon already uses rel-me to verify the links in the "Extra fields" https://joinmastodon.org/verification

Mastodon could use the same mechanism to verify if a post references to a valid mastodon account, by checking if the mastodon account links back to the posts domain.

For example:

If a post from notiz.bog has [email protected] as fediverse:creator, you could check if https://mastodon.social/@pfefferle has a rel-me link to https://notiz.blog:

https://php.microformats.io/?url=https%3A%2F%2Fmastodon.social%2F%40pfefferle

If you equate fediverse:creator with rel-me, you have the same verification method, you have with the Extra fields.

This way, you could have a way to verify it on a domain/user level, instead of having to manually check/approve it by the mastodon admins.

Ref mastodon/mastodon#30398.

ClearlyClaire · 2024-06-25T08:56:58Z

I don't think rel="me" carries quite the same meaning, but something similar would definitely make sense.

shaedrich · 2024-06-25T10:22:25Z

If there was another tag with other links that would have to be put into the bio, some instances have only a limited number of verified fields which already can be a problem. Maybe, there should be separate fields on /settings/verification

pfefferle · 2024-06-25T11:23:18Z

@ClearlyClaire why not?

It is about referencing other profiles/sites of the same person and besides of that it is already there and in use.

ClearlyClaire · 2024-06-25T12:57:16Z

Because saying that your profile on another website is you is a very different thing from saying that your employer is you. And as @shaedrich points out, it does not need to take up space in bio fields.

pfefferle · 2024-06-25T13:23:07Z

Because saying that your profile on another website is you is a very different thing from saying that your employer is you.

That is not the case that I had in mind. The case you are referring to, could be perfectly handled by the proposed approval system. These are normally big sites with a lot of different authors, but I am not talking about the Techcrunchs, I am talking about the small sites/blogs, where the publisher normally is also the only author, because these cases are hard to handle by a manually approval process!

And as @shaedrich points out, it does not need to take up space in bio fields.

For a small site/blog it wouldn't be, because normally it is already there!?

See: mastodon/mastodon#30398

This PR updates the Preview Card. Apart from a minor background color change, it introduces the new `StatusCardAuthorControl`, which is visible if the author of an article has a Mastodon-account. If the user taps on the account, the given profile will open. This feature will be available in Mastodon >4.3 (See [this PR](mastodon/mastodon#30398), for example). HMI, if you need more information on how to test this etc. Please enjoy these screenshots with some fake data: ![1321](https://github.com/mastodon/mastodon-ios/assets/2580019/cc580c84-6700-4f15-b1b0-b845c21a445e)

* add the fediverse creator of a post to opengraph see: * https://wordpress.org/plugins/opengraph/ * https://codeberg.org/fediverse/fep/src/branch/main/fep/XXXX/fep-XXXX.md * mastodon/mastodon#30398 * remove prefix until it is clearified * Do not add the metadata if it already exists

voxpelli · 2024-07-02T19:31:35Z

For future reference: Here’s some prior art in this area: http://microformats.org/wiki/rel-author

Eg. Google+ used that and rel-author uses Web Linking (https://datatracker.ietf.org/doc/html/rfc8288) and a-tags / link-tags with link relations to link to the author rather than using meta-tags to link to something.

I know this PR is implemented and closed. If there’s interest I can open a new issue for extending support to rel-author.

(Typically the algo with rel-author went: rel-author to same site profile page, rel-me from profile page to social account and rel-me back from
social account to profile page to verify the connection, to avoid articles claiming to be written by social accounts that it wasn’t)

Edit:

One could do:

<link rel="author" href="acct:[email protected]">

But since multiple rel-author on a single page means multiple authors one should preferably do rel-author to a same site profile and there so rel-me to all the alternative profiles of that account

tesaguri · 2024-07-03T04:21:08Z

<link rel="author" href="acct:[email protected]">

I think this approach could also cover the use case of a's proposal to define name="mastodon:creator:id" (#30398 (comment)), by adding type="application/activity+json" attribute (or type="application/ld+json; profile="https://www.w3.org/ns/activitystreams"" if the type attribute supports the media type parameter) and setting the href to a URL that resolves to the Activity Streams actor, like so:

<link rel="author" type="application/activity+json" href="https://example.com/@username" />

…n#30398)

shaedrich · 2024-07-05T22:37:25Z

<link rel="author" href="acct:[email protected]">

<link rel="author" type="application/activity+json" href="https://example.com/@username" />

I think, the combination would be quite neat:

<link rel="author" type="application/activity+json" href="@[email protected]">

as the type would already imply the necessary information to parse the href value

use @username@domain instead

tesaguri · 2024-07-05T22:53:52Z

href="@[email protected]"

I think that would technically mean a relative reference, identical to ./@[email protected].

Also, I'm not sure what exactly a type="application/activity+json" attribute for an acct: resource would mean. Although the acct: scheme doesn't specify any particular dereference mechanism for itself, Fediverse servers commonly uses WebFinger to resolve it, which returns a JSON Resource Descriptor (application/jrd+json) instead of application/activity+json, so hinting that the href is application/activity+json doesn't sound quite appropriate to me.

shaedrich · 2024-07-05T22:56:02Z

@tesaguri Interesting 🤔 Thanks for the hint! 👍🏻

If using application/jrd+json solves that—great! 👍🏻

… rel=author proposals refs: mastodon/mastodon#30398

j9t · 2024-07-21T10:19:04Z

Has this been documented somewhere, and is there an example of this in action? (A bit obscure going over this thread.)

renchap · 2024-07-21T10:33:01Z

You can find more information here: https://blog.joinmastodon.org/2024/07/highlighting-journalism-on-mastodon/

We have not yet published a formal documentation for this feature.

andypiper · 2024-07-21T10:38:41Z

I'm working on documenting this for the 4.3 release.

Here's an example post that shows the UI treatment in the web interface:
https://mastodon.social/@verge/112814103022751410

The page linked in that post has this markup in the <head>

<meta property="fediverse:creator" content="@[email protected]"/>

From an API perspective, if you retrieve that status using the API, you will see that it contains a card object that contains an authors array containing name, url, and account. For now the authors array will always have one item on Mastodon; in future or on other platforms, multiple authors could potentially be credited on a single link.

This was also briefly mentioned in the blog.

nightpool · 2024-08-19T23:34:03Z

I agree with the discussion here and elsewhere that this would be much clearer / better served by using <link rel="author" type="application/activity+json" href="https://mastodon.social/@jaypeters">, and I think we should reconsider this one-off meta property before it sees wider deployment / other projects adopt it.

… rel=author proposals refs: mastodon/mastodon#30398

Gargron added the ui Front-end, design label May 22, 2024

Gargron force-pushed the feature-fediverse-creator branch 2 times, most recently from d217a17 to a35ed53 Compare May 22, 2024 19:17

renchap requested a review from ClearlyClaire May 22, 2024 19:28

ClearlyClaire reviewed May 23, 2024

View reviewed changes

Gargron force-pushed the feature-fediverse-creator branch 2 times, most recently from 1ae7751 to 5922bfd Compare May 25, 2024 21:15

Add support for fediverse:creator OpenGraph tag

c5e042e

Gargron force-pushed the feature-fediverse-creator branch from 5922bfd to c5e042e Compare May 26, 2024 23:45

Gargron requested a review from ClearlyClaire May 28, 2024 08:46

ClearlyClaire reviewed May 28, 2024

View reviewed changes

Gargron merged commit 128987e into main May 28, 2024
57 checks passed

Gargron deleted the feature-fediverse-creator branch May 28, 2024 23:34

Gargron mentioned this pull request Jun 2, 2024

Add author links on the explore page in web UI #30521

Merged

tribela mentioned this pull request Jun 4, 2024

Allow account link to preview card when trends review is skipped #30545

Open

jonaharagon mentioned this pull request Jun 14, 2024

Add fediverse:creator OpenGraph tag privacyguides/privacyguides.org#2616

Merged

1 task

Krinkle added a commit to Krinkle/timotijhof.net that referenced this pull request Jun 24, 2024

theme: Add fediverse:creator meta tag

39163a1

Ref mastodon/mastodon#30398.

pfefferle added a commit to willnorris/wordpress-opengraph that referenced this pull request Jun 27, 2024

Add fediverse:creator support

c710ba7

See: mastodon/mastodon#30398

pfefferle mentioned this pull request Jun 27, 2024

Add fediverse:creator support willnorris/wordpress-opengraph#34

Merged

zeitschlag mentioned this pull request Jun 30, 2024

Show author in Card (IOS-284) mastodon/mastodon-ios#1321

Merged

franck-paul added a commit to franck-paul/socialMeta that referenced this pull request Jul 3, 2024

Remove first @ in mastodon @name@domain account (see mastodon/mastodo…

a407655

…n#30398)

3b0b added a commit to 3b0b/microblog.pub that referenced this pull request Jul 12, 2024

feat: Add problematic OpenGraph fediverse:creator proposal and better…

7e69c93

… rel=author proposals refs: mastodon/mastodon#30398

AaronNGray mentioned this pull request Aug 2, 2024

Standardize discovery using link rel on user-visible URLs w3c/activitypub#310

Open

AaronNGray mentioned this pull request Aug 20, 2024

Document fediverse:creator OpenGraph tag swicg/activitypub-html-discovery#16

Open

3b0b added a commit to 3b0b/microblog.pub that referenced this pull request Sep 7, 2024

feat: Add problematic OpenGraph fediverse:creator proposal and better…

ad74991

… rel=author proposals refs: mastodon/mastodon#30398

3b0b added a commit to 3b0b/microblog.pub that referenced this pull request Sep 8, 2024

feat: Add problematic OpenGraph fediverse:creator proposal and better…

fd4f09a

… rel=author proposals refs: mastodon/mastodon#30398

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for `fediverse:creator` OpenGraph tag #30398

Add support for `fediverse:creator` OpenGraph tag #30398

Gargron commented May 22, 2024 •

edited

Loading

shleeable commented May 22, 2024

trwnh commented May 23, 2024

Gargron commented May 23, 2024 •

edited

Loading

trwnh commented May 23, 2024 •

edited

Loading

renchap commented May 23, 2024

tsmethurst commented May 23, 2024

trwnh commented May 23, 2024

ClearlyClaire left a comment

renchap commented May 23, 2024

ClearlyClaire commented May 23, 2024

andypiper commented May 23, 2024

ClearlyClaire left a comment

shleeable commented May 29, 2024 •

edited

Loading

ClearlyClaire commented May 29, 2024

trwnh commented May 29, 2024

renchap commented Jun 20, 2024

pfefferle commented Jun 22, 2024

renchap commented Jun 22, 2024

pfefferle commented Jun 22, 2024 •

edited

Loading

ClearlyClaire commented Jun 25, 2024

shaedrich commented Jun 25, 2024

pfefferle commented Jun 25, 2024

ClearlyClaire commented Jun 25, 2024

pfefferle commented Jun 25, 2024

voxpelli commented Jul 2, 2024 •

edited

Loading

tesaguri commented Jul 3, 2024 •

edited

Loading

shaedrich commented Jul 5, 2024 •

edited

Loading

tesaguri commented Jul 5, 2024

shaedrich commented Jul 5, 2024

j9t commented Jul 21, 2024 •

edited

Loading

renchap commented Jul 21, 2024

andypiper commented Jul 21, 2024

nightpool commented Aug 19, 2024

Add support for fediverse:creator OpenGraph tag #30398

Add support for fediverse:creator OpenGraph tag #30398

Conversation

Gargron commented May 22, 2024 • edited Loading

shleeable commented May 22, 2024

trwnh commented May 23, 2024

Gargron commented May 23, 2024 • edited Loading

trwnh commented May 23, 2024 • edited Loading

renchap commented May 23, 2024

tsmethurst commented May 23, 2024

trwnh commented May 23, 2024

ClearlyClaire left a comment

Choose a reason for hiding this comment

renchap commented May 23, 2024

ClearlyClaire commented May 23, 2024

andypiper commented May 23, 2024

ClearlyClaire left a comment

Choose a reason for hiding this comment

shleeable commented May 29, 2024 • edited Loading

ClearlyClaire commented May 29, 2024

trwnh commented May 29, 2024

renchap commented Jun 20, 2024

pfefferle commented Jun 22, 2024

renchap commented Jun 22, 2024

pfefferle commented Jun 22, 2024 • edited Loading

ClearlyClaire commented Jun 25, 2024

shaedrich commented Jun 25, 2024

pfefferle commented Jun 25, 2024

ClearlyClaire commented Jun 25, 2024

pfefferle commented Jun 25, 2024

voxpelli commented Jul 2, 2024 • edited Loading

tesaguri commented Jul 3, 2024 • edited Loading

shaedrich commented Jul 5, 2024 • edited Loading

tesaguri commented Jul 5, 2024

shaedrich commented Jul 5, 2024

j9t commented Jul 21, 2024 • edited Loading

renchap commented Jul 21, 2024

andypiper commented Jul 21, 2024

nightpool commented Aug 19, 2024

Add support for `fediverse:creator` OpenGraph tag #30398

Add support for `fediverse:creator` OpenGraph tag #30398

Gargron commented May 22, 2024 •

edited

Loading

Gargron commented May 23, 2024 •

edited

Loading

trwnh commented May 23, 2024 •

edited

Loading

shleeable commented May 29, 2024 •

edited

Loading

pfefferle commented Jun 22, 2024 •

edited

Loading

voxpelli commented Jul 2, 2024 •

edited

Loading

tesaguri commented Jul 3, 2024 •

edited

Loading

shaedrich commented Jul 5, 2024 •

edited

Loading

j9t commented Jul 21, 2024 •

edited

Loading