💾 Archived View for pn.id.lv › 20220218.gmi captured on 2022-07-16 at 14:35:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
After learning more about Gemini's history and the stance of the more outspoken users of Gemini, I've decided that this proposal, along with the whole concept, doesn't befit any use, and therefore, though this is little more than a proposal, I'm retracting it, along with any endorsement that I've expressed either in public or private.
I don't recommend you implement this unless you see some use of it. This proposal has no community adoption beyond this pod, and I don't expect that to change, so implementing it is effectively meaningless.
This isn't to say that I don't believe the concept to be useful, but as I've discussed before, I've come to the conclusion that the approach listed herein is too complex for what it needs to be. For gemlog use cases, I point you to bacardi55's proposal instead: though I don't agree with it entirely, it already has been more successful in a Darwinian sense.
https://codeberg.org/bacardi55/gemini-mentions-rfc
⁂
Gemmention is an adaptation of Webmention for the Gemini smolweb. The general problem that Webmention solves is to allow site A to notify site B that A has linked to B -- essentially, proactively letting B know about a backlink, which is particularly useful if B doesn't know about A but wants to learn about them.
The Webmention spec outlines reasons why this might be useful. Primarily, it could be of interest for people who want to learn about others who link to them, which might be useful in more disjointed and decentralised communities. The mention mechanism is purely opt-in and performed as a courtesy, so by default it has little privacy impact.
Gemmention is a simplified version of Webmention, intended for use with the Gemini protocol. The changes required stem from the fact that Gemini doesn't have metadata extensibility, i.e., a request only has the one URL as all the data that an arbitrary client can supply, as well as the fact that for most purposes Webmention has some overhead that's not necessary for solving its core purpose.
The key words "MUST", "MUST NOT", "SHOULD", and "RECOMMENDED" in this document are to be interpreted as described in the IETF BCP 14 (RFC 8174).
A mention is a notification that a Mentioning Gemini URL links to a Mentioned URL. A mention is sent by a Sender and targeted towards a Receiver; presumably, the Sender has produced the Mentioning URL, and the Receiver is interested about the Mentioned URL.
A Gemmention endpoint is an arbitrary Gemini URL. The URL MAY have a query part.
To send a mention, the Sender performs these actions:
When a Receiver receives a mention, it MUST be verified before being displayed. This document defers the precise mechanism of verification: either an automated, asynchronous system should fetch the Mentioning URL to check that the Mentioned URL is indeed linked from it, or the mentions should be moderated manually, or any other system determined by the Receiver.
To prevent abuse, principles outlined in the section 4 of the Webmention specification SHOULD be followed when processing Gemmentions.
Unlike HTTP, the Gemmention endpoint can't be provided simultaneously but out-of-band with the content. If the Sender learns of a Gemmention endpoint URL via a side-channel, it can send a Gemmention to that endpoint, but a more common case is a Receiver explicitly publishing the URL they want to have notified about mentions, and the Sender discovering it from the content in-band.
For that, a basic discovery mechanism is proposed for text/gemini (hereonafter, Gemtext) documents. If the Gemtext document contains a link whose label, after stripping leading and trailing whitespace, is either precisely "Gemmention" or precisely "Gemmention this", the link's target is assumed to be the Gemmention endpoint URL.
=> gemini://example.com/mention Gemmention => gemini://example.com/mention Gemmention this
It's RECOMMENDED to provide a link to the Gemmention documentation or a friendly explanation about what Gemmention is and how to use it along with this link. No discovery mechanism is currently proposed for non-Gemtext documents.
Let's say that capsule A publishes an interesting article at this URL:
gemini://example.org/hot-take.gmi
The author of capsule B produces a response to the article, and posts it on their own capsule at this URL:
gemini://capsule.test/blog?response.gmi;version=1
The capsule B's software notices the inline link to capsule A, fetches the link target, and finds this snippet among the Gemtext:
=>/mention?token=1 Gemmention this
This is resolved to imply that capsule A wishes to receive a mention to the specified URL. After encoding the mentioned and mentioning URLs, a request is made to this URL:
gemini://example.org/mention?token=1;gemini%3A%2F%2Fexample.org%2Fhot-take.gmi;gemini%3A%2F%2Fcapsule.test%2Fblog%3Fresponse.gmi%3Bversion%3D1
The response, in its entirety, is this:
20 text/plain Mention received!
From that, the Sender infers that the Gemmention has been sent and received successfully. After this point, the Receiver is free to process this mention as they see fit.
Any feedback to this draft specification can be submitted either directly to the author, or via sending a Gemmention, pursuant to this specification, to the endpoint below.
bacardi55 has published a competing proposal, tailored specifically towards responses in the Gemlog sphere, which took into account this proposal.
The focus of their proposal and this one are different; this is pretty much a direct port of Webmention with the intent to preserve generality towards the mentionee and mention processor URLs and not prescribe a particular endpoint, and not limited to specifically replies, i.e., allowing for more rich interactions to be based upon Gemmention.
That said, perhaps that's designing for extensibility wherein a more pragmatic and based-in-reality (i.e., YAGNI-avoiding) proposal might be better. I am not deprecating this proposal, and indeed I still hold that it might be useful for certain use cases, but for my personal blog I'll likely implement bacardi55's proposal instead, and for gemlogs in particular suggest doing the same.
Prior art:
Indeed, The Backlinks Project fulfills a similar purpose as Gemmention as specified above. A partial goal of Backlinks appears to be to maintain bidirectional linkage between the original and the response, therefore the requirements proposed differ from Gemmention in multiple places. Gemmention happens to be more generic (given that the mentioned URL and the mention endpoint need not be on the same pod) and more precisely specified as a result of borrowing from the W3C Webmention specification.