(#n252jtq) @prologic@twtxt.net Hmm. Some thoughts.

WebMentions are probably the best solution in a world with “HTTP + server-side code”. (You need something to process the POST request.)

The … well, let’s call it “beauty” … of the original twtxt spec was that sending special HTTP user agents does not require server-side code. You can just grep your logs. This is probably not relevant for Yarn, but it is for me – I run a plain httpd, no CGI, no PHP, no nothing. That thing serves static HTML and that’s it. And I want to keep it that way, because it saves me a lot of trouble.

So that’s one aspect.

Another aspect is Gemini and Gopher: While they do support user input, they don’t support multiple fields. I.e., source and target as it is specified by WebMentions won’t work. So you have to come up with your own format anyway.

So, yeah, what’s left? How could it be done? Maybe something like this:

• We need a format to specify feed URL and nick name. I’d simply go with this: ${source.nick} ${source.url}, e.g. movq https://www.uninformativ.de/twtxt.txt
  
• HTTP: A GET request with one percent-encoded parameter, e.g.: https://www.uninformativ.de/twtxt.txt?follow=movq%20https%3A%2F%2Fwww.uninformativ.de%2Ftwtxt.txt
  
• Gemini: A request with a percent-encoded parameter, e.g.: gemini://www.uninformativ.de/twtxt.txt?movq%20https%3A%2F%2Fwww.uninformativ.de%2Ftwtxt.txt
  
• Gopher: A “search request” (menu type 7), no need for percent encoding here, e.g.: /twtxt.txt<literal_tab>movq https://www.uninformativ.de/twtxt.txt
  

If you run server-side code, then it can interpret this additional payload. If you, like me, run nothing but static httpd, then the requests will usually be served as if there was no parameter – but the full query will usually show up in log files.

So basically, this would be like moving the info from the HTTP user agent to some other place where it’s supported for all protocols.

Now, we could send this parameter for every request, but I’m not sure if that’s a good idea. For one, it creates noise. Also, what if a server is pedantic and takes the request literally, i.e. it searches for a file called twtxt.txt?follow=movq%20https:%2F%2Fwww.uninformativ.de%2Ftwtxt.txt? Or maybe Gopher servers refuse to serve the twtxt.txt file if there’s a search parameter. So I guess it’s better to only do these “pingback requests” every once in a while.

Strictly speaking, we could ignore HTTP entirely and just keep using the user agent here. We would then only be using this new format for Gopher and Gemini. I’m not sure, though, if it’s a good idea to use such different methods depending on the protocol. On the other hand, we should care about backwards compatibility.