gemini://gmi.bacardi55.io/gemlog/2023/01/05/gemini-mention-discussion/

It is already past 1am here, so for once I'm going to try to be concise for real :]. This post is a continuation of a discussion about gemini mention and a response to Sean's post called « Thoughts on an implementation of Gemini mentions »[1] as I think there are a few misunderstanding of the RFC requirements.

> First, having the location locked to `/.well-known/mention` works fine for single-user sites, but it doesn't work that well for sites that host multiple users under a single domain.

The proposal only indicates "/.well-known/mention", which means that it doesn't have to be "gemini://domain.tld/.well-known/mention" but has to be "gemini://<capsuleRoot>/.well-known/mention", in the given example of alice and dave sharing the domain example.com, it would means that:

Alice have to setup her own gemini mention endpoint at "gemini://example.com/alice/.well-known/mention"

So whatever the base url of the capsule is + "/.well-known/mention" path. Which avoid the mentioned issue.

> Second, not every person may want to have every page to receive a mention. I know I don't—I want to restrict mentions to the blog portion of my Gemini site.

> […] it [the proposal] says nothing about limiting what pages can be the target of a mention.

> […] My implementation does scan the given URI for links to my blog, and will grab the first link that matches a blog entry from the URI (and ignores other links to my Gemini site—see point above).

The proposal indeed says nothing about limits, on purpose. It is up to the server implementation to decide what to do with received value. For example, in my ggm implementation, I only check that the link inside the reponse contains a valid URI to my capsule. It isn't mandatory in the proposal but I do prefer making sure the URL sent is correct *and* that is contains a URI to a valid page of my capsule. I could have added a verification that the gemini mention only concern my `/gemlog/' path and not the `/blog/' path, like Sean did. I don't think it should be part of the proposal and leave capsule owner decide how to manage received mention.

The server implementation could return a simple message saying "the author of this capsule doesn't accept mention in the provided uri" or whatever. So capsule owners decide where to put the link, what the description of that link should be (and even text around). Then the implementation should follow capsule owners decision of accepting or not mentions.

Maybe some wording should be added in the RFC to explicitely indicates this expected behavior?

The more I think about this, the more I agree that it shouldn't be mandatory. I'm going to update the current proposal to remove this. People should be free of using whatever text description as long as they point to one of your pages.

> Sending in two links, as in a webmention [5] provides some form of check on the request.

It seems to be the main point where I don't follow Sean and don't see the value of this 2nd URI. Having the mentioned URI as an argument will maybe help parsing the response page to check if the link is indeed in the page, but i still have to request the page and parse it anyway. Parsing the response to find an exact link (provided) or searching for a URI matching a pattern seems the same to me… So the gain seems limited in my view compared to bringing the "complexity" of multiple get parameters like on the web… But maybe i'm overfixating about that.

Anyway, it is already too late, so I'll update the RFC and the ggm code later this week, but I really enjoy this kind of conversation over gemlogs :).

Gemini mention, an ongoing discussion