Not always online capsules

[Jonathan McHugh]

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 McHugh
indieterminacy@libre.brussels

September 22, 2021 7:08 PM, "Omar Polo" <op@omarpolo.com> wrote:

> "Jonathan McHugh" <indieterminacy@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@libre.brussels
>> 
>> September 22, 2021 10:03 AM, "Omar Polo" <op@omarpolo.com> wrote:
>> 
>>> Chris McGowan <cmcgowan9990@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.