💾 Archived View for rawtext.club › ~sloum › geminilist › 007200.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Jonathan McHugh indieterminacy at libre.brussels
Wed Sep 22 19:57:21 BST 2021
- - - - - - - - - - - - - - - - - - -
Omar,
The confusion is all at my end, relax. I know little about DNS, yet I was trying to understand whether an alternative mechanism is possible.
I guess the `dig` command covers most usecases and I should investigate how to practically add the message notes you have been discussing.
However, it did intrigue me along these lines:* GIVEN Client discovers 'not online' problem (akin to your more recent Telescope mail)* WHEN Client compares this state with previous state (this client keeps a cache of visited states)* AND This state is different* THEN Message sent to weird bulletin newsletter to permit pooled knowledge* AND This may already be too convoluted for most peoples requirements, let alone Gemini expectations... just brainstorming* AND Who on earth uses TDD flags with asterisks anyway!?!?
====================Jonathan McHughindieterminacy at libre.brussels
September 22, 2021 7:08 PM, "Omar Polo" <op at omarpolo.com> wrote:
"Jonathan McHugh" <indieterminacy at libre.brussels> writes:
Omar,
Hi :)
Speaking of your coding, I noticed this
=
https://git.omarpolo.com/mlmpl/tree/README.md
Can you imagine any considerations for creating a mailing list/newsletter approach for such a
problem domain?
Apologies but I don't understand the question.
mlmpl is was a quick hack to run a smallish newsletter for fun and (no)
profit. (it's still being used by the way.)
SMTP is quite resistant to offline/unreachable servers. MX *should*
retry before giving up the delivery (I don't remember the exact number
thought) so this is a slightly minor problem in the mailing
list/newsletter world AFAIK.
====================
Jonathan McHugh
indieterminacy at libre.brussels
September 22, 2021 10:03 AM, "Omar Polo" <op at omarpolo.com> wrote:
Chris McGowan <cmcgowan9990 at gmail.com> writes:
My assumption, when I follow a link and I just get an error message,
is that the capsule is dead, and the project abandoned. I assume an
always-on internet. I'm wondering how we can change this assumption,
and make it ok for capsules not to always be online.
That, I believe, is the point of the DNS txt record. In theory, a
client, when getting a cannot connect error from the capsule could
query for a DNS txt record for the domain (presumably at a standard or
conventional place/name) which it could then display to the user
attempting to connect. This message could say something like:
"Hey looks like you tried to reach me during my capsule's off
hours. Here's when this capsule is online <schedule>. If it is
currently within that schedule and you still can't reach the site,
please let me know here: <contact details>"
Or some other appropriate message.
Love the idea, I'm tempting to drafting something in my client ^^"
I think it's better to use a free-form text instead of trying to come up
with a strict syntax to communicate when the capsule should be online.
I'm not convinced it is worth for robots to know these schedules, given
all the complex schedule one can have (and the rabbit hole for the
"perfect" syntax that covers all possible situations is pretty deep.)
(just remember to add the timezone info in <schedule> :D)
This would have the benefit of being relatively simple to implement
for clients and for capsule hosts to use, although your registrar
would have to allow txt records.
There are registrar that disallow txt records? Lot of other services
(gitlab pages comes to mind for example) requires user to set TXT
records.