type: extend Link type and ResourceDescriptor

[dodok8]

Summary

Change ResourceDescriptor and Link interfaces to support OStatus 1.0 Draft 2

Related Issue

• closes type: extend Link type and ResourceDescriptor #402
• related Webfinger in Fedify should support Mastodon's special rel= 'http://ostatus.org/schema/1.0/subscribe' and template #119

Changes

• Add template field to Link of ResourceDescriptor
• Fix the following problem

Benefits

Now we can handle OStatus 1.0 Draft 2, for example, mastodon remote follow URI.

Checklist

• Did you add a changelog entry to the CHANGES.md?
• Did you write some relevant docs about this change (if it's a new feature)?
• Did you write a regression test to reproduce the bug (if it's a bug fix)?
• Did you write some tests for this change (if it's a new feature)?
• Did you run deno task test-all on your machine?

Additional Notes

[gemini-code-assist]

Summary of Changes

Hello @dodok8, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily aims to enhance the Link and ResourceDescriptor interfaces to align with the OStatus 1.0 Draft 2 specification. This enables the system to correctly parse and utilize link structures, particularly for features like remote follow URIs in federated social networks. Additionally, it includes minor but important robustness improvements in related modules to handle cases where link href properties might be absent.

Highlights

• OStatus 1.0 Draft 2 Support: The Link interface has been extended to support the OStatus 1.0 Draft 2 specification, enabling handling of features like Mastodon remote follow URIs.
• Link Interface Enhancements: The Link interface now includes an optional template field for URI templates and makes the href field optional to align with the OStatus specification.
• Robustness Improvements: Null/undefined checks for href properties in Link objects have been added or enhanced in nodeinfo/client.ts and vocab/lookup.ts to prevent potential errors when href might be missing.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request extends the Link and ResourceDescriptor types to better support OStatus 1.0 Draft 2. This is achieved by making the href property on the Link interface optional and adding a new optional template property. The related code has been updated to handle cases where href might be missing. The changes are generally good and move towards better spec compliance. I've found one place where a new null check is redundant due to existing logic, and I've suggested its removal to improve code clarity.

[github-actions]

The docs for this pull request have been published:

https://64bf5be9.fedify.pages.dev

[dahlia]

Could you add a changelog entry for this change?

[github-actions]

The latest push to this pull request has been published to JSR and npm as a pre-release:

Package	Version	JSR	npm
@fedify/fedify	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/cli	1.9.0-pr.404.1515+d1cab13d	JSR
@fedify/amqp	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/cfworkers	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/denokv	1.9.0-pr.404.1515+d1cab13d	JSR
@fedify/elysia	1.9.0-pr.404.1515+d1cab13d		npm
@fedify/express	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/h3	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/hono	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/nestjs	1.9.0-pr.404.1515+d1cab13d		npm
@fedify/next	1.9.0-pr.404.1515+d1cab13d		npm
@fedify/postgres	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/redis	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/sqlite	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/sveltekit	1.9.0-pr.404.1515+d1cab13d	JSR	npm
@fedify/testing	1.9.0-pr.404.1515+d1cab13d	JSR	npm

[dahlia]

Good job!