feat: new plugin hatsu

[kwaa]

Description

This is an updated version of the same plugin in Aoba.

Check List

• Have you read the
  CODE OF CONDUCT
• Have you read the document
  CONTRIBUTING
  • One pull request per feature. If you want to do more than one thing,
    send multiple pull request.
  • Write tests.
  • Run deno fmt to fix the code format before commit.
  • Document any change in the CHANGELOG.md.

[oscarotero]

Please, give me some time to review this PR (and the middleware too). I didn't know the hatsu library and want to understand what this plugin does and what's the problem to solve. 🙏

Thanks!

[kwaa]

I didn't know the hatsu library and want to understand what this plugin does and what's the problem to solve. 🙏

The Hatsu plugin gets ActivityPub integration from Hatsu by setting up a static .well-known file and setting an activity+json alternate for matching urls.

https://hatsu.cli.rs/users/redirecting-with-static-files-and-markup.html

On top of this, Hatsu middleware goes a step further and redirects for .well-known and matched activity+json requests to be compatible with more Fediverse software.

[oscarotero]

I have been testing the plugin and left a couple of comments.

I don't have a hatsu server, so I've tested it with https://fed.brid.gy/web/lume.land and the build generates the following files:

Sorry for my ignorance, I don't have enough knowledge about the fediverse and indie web. What these files can do?

For example, Lume has a mastodon account https://fosstodon.org/@lume.
What benefits provides the hatsu plugin?

I'm using a web component to show the replies of a mastodon post as comments of posts (see the comments of this post as an example). Does this plugin make this process easier?

[oscarotero]

This doesn't work on local because the url host is always localhost.
Maybe the plugin should have a username, handler or something like this to configure this value?

[kwaa]

This doesn't work on local because the url host is always localhost. Maybe the plugin should have a username, handler or something like this to configure this value?

Maybe provide options.location option and fallback to site.options.location

[oscarotero]

yup!

[oscarotero]

Instead of using regexp for urls, I think it's better to use a Search query. For example: publish=true to select all pages with the variable publish set to true.
You can get all pages with:

const pages = site.search.pages("publish=true")

[kwaa]

Instead of using regexp for urls, I think it's better to use a Search query. For example: publish=true to select all pages with the variable publish set to true.

Indeed. is there a way to use a similar approach for middleware?

[oscarotero]

Nope. Do you need it for the middleware?
I'm thinking of a solution similar to redirect plugin: it generates a _redirects.json file with all urls that you can import in the redirect middleware.

[kwaa]

Do you need it for the middleware?

Some software only supports redirects instead of HTML link alternates, and middleware redirects requests from them while leaving normal user requests intact.

[kwaa]

What these files can do?

When a user searches for @[email protected] on Fediverse, the server tries to request https://instance.tld/.well-known/webfinger?resource=acct:@[email protected]. The Hatsu plugin's wellKnown part supports the query by saving the webfinger as a static file.

host-meta is related to webfinger and may be requested by some implementations. Here it is set to the webfinger URL of the Hatsu instance.

For example, Lume has a mastodon account fosstodon.org/@lume. What benefits provides the hatsu plugin?

The Hatsu plugin only considers integration with Hatsu instances, so there is no benefit.

As for why this isn't a generic Fediverse plugin, it's because Hatsu has a unique inferable AS2 URL feature.

When the pathname matches, the post will set the application/activity+json alternate (or automatically redirect the application/activity+json request when using middleware):

<!-- generated alternate for https://example.com/foo/bar -->
<link rel="alternate" type="application/activity+json" href="https://hatsu.local/posts/https://example.com/foo/bar" />

When a Fediverse user searches for https://example.com/foo/bar, they will be redirected to https://hatsu.local/posts/https://example.com/foo/bar to display the search results.

I'm using a web component to show the replies of a mastodon post as comments of posts (see the comments of this post as an example). Does this plugin make this process easier?

Yes, I have an example in the Hatsu documentation, but this plugin currently doesn't implement that part (since it's available only for theme-simple-blog).

https://hatsu.cli.rs/users/backfeed-based-on-mastodon-comments.html#lume

[oscarotero]

Thanks for the detailed explanation!

If I understand correctly, this plugins does two things:

• It creates a static version of the webfinger file to support requests like .well-known/webfinger?query_params. Due the file is static, the query parameters are really not used, it shows always the same content.
  • I understand the middleware in feat: new middleware redirect_as2 #632 does this redirect to the hatsu server.
• It also creates alternate links tags in some pages, which seems to be a special feature of hatsu, right?

What do you thing about split this plugin in two?

For example, a webfinger plugin to generate the /.well-known/webfinger file (and other files that may be required in the .well-known folder). This plugin could generate the file using static data and/or fetch the data from other services. For example:

site.use(webfinger({
    data: {}, // Data passed directly
    remote: // Url with a remote bridge, like  https://hatsu.local
});

Does it make sense to you?
This could allow to generate webfinger files with different methods and would be more flexible.

And hatsu plugin could be a different plugin to implement hatsu specific features.
Let me know your thoughts.

[kwaa]

• It creates a static version of the webfinger file to support requests like .well-known/webfinger?query_params. Due the file is static, the query parameters are really not used, it shows always the same content.
  • I understand the middleware in feat: new middleware hatsu #632 does this redirect to the hatsu server.

yes.

• It also creates alternate links tags in some pages, which seems to be a special feature of hatsu, right?

right, I think this is the main feature of this plugin, to provide search discovery on Fediverse for website URLs.

What do you thing about split this plugin in two?

For example, a webfinger plugin to generate the /.well-known/webfinger file (and other files that may be required in the .well-known folder). This plugin could generate the file using static data and/or fetch the data from other services. For example:

The implementation is simple, though it will make configuration more cumbersome.
People who only need webfinger can always simply create a static webfinger file.

Does it make sense to you? This could allow to generate webfinger files with different methods and would be more flexible.

And hatsu plugin could be a different plugin to implement hatsu specific features. Let me know your thoughts.

I feel necessary to think about the configuration format to try to avoid getting more complicated.