Gemini - About Antenna
Gemini - About Antenna
yarnd already supports this by using WebMentions -- It's just been neglected over some months and I'm trying to fix it proper for the upcoming v0.13 release. Is WebMentions suitable here do you think? It _has_ worked well in the past across pods at least, and honestly isn't that hard to implement anywhere else either.
yarnd already supports this by using WebMentions -- It's just been neglected over some months and I'm trying to fix it proper for the upcoming v0.13 release. Is WebMentions suitable here do you think? It _has_ worked well in the past across pods at least, and honestly isn't that hard to implement anywhere else either.
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.
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.
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.
So... Can we just decide never to support this at all? And instead expect (_which is up to clients really and doesn't need to be roamlized_) clients to keep track of if they've been mentioned already be mere fact of parsing feeds they follow?
So... Can we just decide never to support this at all? And instead expect (_which is up to clients really and doesn't need to be roamlized_) clients to keep track of if they've been mentioned already be mere fact of parsing feeds they follow?
rm -rf *webmention* all the code in yarnd as it's hard to support anyway...
rm -rf *webmention* all the code in yarnd as it's hard to support anyway...
Yes, I agree: There doesn’t need to be a mechanism for actively sending a message from user A to user B when user A mentions user B.
What I meant, though, was indeed discovery of new feeds. Or rather: New followers. At the moment, you can only find out about new followers by inspecting their HTTP user agents – and *that* only works via HTTP. So, for the purpose of notifying feed authors about new followers, I was proposing a pingback-like mechanism. (And I think this is also what the original GitHub issue from 2016 was talking about.)
Yes, I agree: There doesn’t need to be a mechanism for actively sending a message from user A to user B when user A mentions user B.
What I meant, though, was indeed discovery of new feeds. Or rather: New followers. At the moment, you can only find out about new followers by inspecting their HTTP user agents – and *that* only works via HTTP. So, for the purpose of notifying feed authors about new followers, I was proposing a pingback-like mechanism. (And I think this is also what the original GitHub issue from 2016 was talking about.)
Yes, I agree: There doesn’t need to be a mechanism for actively sending a message from user A to user B when user A mentions user B.
What I meant, though, was indeed discovery of new feeds. Or rather: New followers. At the moment, you can only find out about new followers by inspecting their HTTP user agents – and *that* only works via HTTP. So, for the purpose of notifying feed authors about new followers, I was proposing a pingback-like mechanism. (And I think this is also what the original GitHub issue from 2016 was talking about.)
yarnd always supported the use of WebMentions -- It's been broken for a while because well priorities and we desperately need to slow down and focus on e2e integration tests (_yes I know @lyse !_) -- But it got fixed proper today once and for all, and it works really nicely.
yarnd always supported the use of WebMentions -- It's been broken for a while because well priorities and we desperately need to slow down and focus on e2e integration tests (_yes I know @lyse !_) -- But it got fixed proper today once and for all, and it works really nicely.