Hello, Are there any protocols that could be used with (say) Gemini for capsules that are not always online ? The expectation that the whole internet is always online feels like a massive waste of resource. It should be ok for a capsule to say "hey, I'm not online. Come back later, or check this mirror". Instead we get fatal looking errors. Maybe custom TXT DNS entries could specify when to expect the capsule to be available, and where to find mirrors ? Anyone knows of any such protocol that could be used with Gemini ? :-) Alice
That sounds like an awesome idea! Although IIRC the definition of a server includes a system that is accessible 24/7 but your point makes sense.
> That sounds like an awesome idea! Although IIRC the definition of a > server includes a system that is accessible 24/7 but your point makes > sense. That's actually a cool idea. Have a DNS TXT record that looks like OFFLINE: This site is currently offline. Please try again later. We could then show this instead of having just a "service unreachable" fault or something. - xq
Maybe not just 'please try again later', but rather have a default syntax for specifying when a site is up usually so clients can display how long until the site will be online again or maybe even add a timer, or automatically fetch the site when it's online so you can watch it when you go online yourself again, the possibilites are endless.
It would please me to know whether a service has dropped off the map entirely or whether a person is moving house and unable to restart their Gemini instance in their new enclave. ==================== Jonathan McHugh indieterminacy at libre.brussels September 21, 2021 11:29 AM, "Felix Quei?ner" <felix at masterq32.de> wrote: >> That sounds like an awesome idea! Although IIRC the definition of a >> server includes a system that is accessible 24/7 but your point makes >> sense. > > That's actually a cool idea. Have a DNS TXT record that looks like > > OFFLINE: This site is currently offline. Please try again later. > > We could then show this instead of having just a "service unreachable" fault or something. > > - xq
> Maybe not just 'please try again later', but rather have a default
> syntax for specifying when a site is up usually so clients can display
> how long until the site will be online again or maybe even add a timer,
> or automatically fetch the site when it's online so you can watch it
> when you go online yourself again, the possibilites are endless.
Yeah, my idea was that the placeholder looks like
"OFFLINE:{whitespace*}{message}{whitespace*}"
where message can be anything you want.
Examples:
OFFLINE: Our business times are 08:00 to 18:00 CEST
OFFLINE: Please come back later. My server is currently down! - xq
OFFLINE: Sorry. Looks like i have a power outage again. Should be back
up in 20 minutes!
I don't think a more "technical" thing is a good idea here, as the
reasons for "server unreachable" are manifold
- xq
I'm not against having custom messages and such, but I think we should also have a standard format for showing regular uptimes and such so clients/daemons could implement automatic fetching and such for offline viewing
If the time expectations were known in advance it would be cool to
describe it in a progammatic way.
I have a lot of respect for Roaring Penguin's Remind tool
=> https://www.roaringpenguin.com/products/remind
As a practical example, perhaps you want to run a service only when there is a Blue Moon
=> https://www.linuxjournal.com/article/3529
``` remind
FSET isFirstFull(date) \
monnum(moondate(2, date)) == \
monnum(moondate(2, moondate(2, date)+1))
REM 1 SATISFY isFirstFull(trigdate())
set blue moondate(2, moondate(2,\
trigdate())+1)\
MSG Next blue moon is [trigger(blue)]
```
> Running this script through Remind shows that the next blue moon will
take place on October 31, 2001. The one after that is July 31, 2004.
Providing use input to a service could allow people to programatically
provide an overview of core services.
It could also provide directions to people as to when people should expect
to parse content from invididual URIs, minimising calls.
Having such a header in users' draft GemText files could provide a casual
workflow for aligning writers with consumers better - potentially
including deadline expectation for peer review or responses. A tidy script
could parse Remind blocks and update this service as things move along.
Perhaps it could be provided as a Git hook based upon criteria.
Kind regards,
====================
Jonathan McHugh
indieterminacy at libre.brussels
September 21, 2021 11:32 AM, "metalune" <metalune at mailbox.org> wrote:
> Maybe not just 'please try again later', but rather have a default
> syntax for specifying when a site is up usually so clients can display
> how long until the site will be online again or maybe even add a timer,
> or automatically fetch the site when it's online so you can watch it
> when you go online yourself again, the possibilites are endless.
Not exactly where the rest of the discussion here went but there is an existing tool/format for archiving capsules for offline viewing: https://codeberg.org/oppenlab/gempub As the name suggests its original intent was a gemini version of epubs, but its perfectly suitable for archiving a capsule. You could set up a cron job to periodically archive a capsule you're interested in and read its contents whenever you like. You could also possibly have a client that, when it checked its subscriptions would download and archive the capsule (or some part of it) so you could later view the content whether the capsule was online or not. Obviously this doesn't help the scenario where one is visiting a capsule for the first time that's currently offline, but its better than nothing.
Am 21.09.21 um 10:41 schrieb Alice: > The expectation that the whole internet is always online feels like a > massive waste of resource. Totally agreed. >It should be ok for a capsule to say "hey, Well, if the capsule is offline, it can't say anything. You will be thrown back to the messages of your Browser. And these could possibly done a bit more friendly or detailed. > Maybe custom TXT DNS entries could specify when to expect the capsule to > be available, and where to find mirrors ? In any case where a fault takes machine down, you can just send an informative message, if there is a second infrastructur - which itself burns energy. I don't know, how load balancers work, but these also provide some kind of high availability. But this does not look, as if it is what you want. If a server is offline, a possible solution could be to hold an old state of the content in a clients cache. A complete ?always available? solution could be to use something like ipfs or such, but I think this looks not as I would like it. Too big, too complex. -- EN: gemini://blog.datapulp.de DE:gemini://datenbrei.de
> I don't know, how load balancers work, but these also provide some kind of high availability. Load balancers are additional servers whose job is to sit in front of the content servers and proxy requests to them, usually to spread load between the content servers. Generally you'd have only a few load balancers working with a (relatively) large number of content servers. Given Gemini's relative size I don't see this web paradigm making its way to gemini any time soon. Also, as this involves more online servers, its probably not what you'd want for an offline friendly set up, as you noted.
On Tue, 2021-09-21, Alice wrote: >Are there any protocols that could be used with (say) Gemini for capsules that are not always online ? Gemtext-over-DNS (GoD): base64-encoded gemlogs served as TXT records. :) A more feasible idea is for Gemini and Gopher clients to keep local archives of visited pages, so that they can be accessed when servers are down. This was suggested by Solderpunk in: gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/the-individual-a rchivist-and-ghosts-of-gophers-past.txt Locally archived pages can also be versioned, as in git, so visitors can see the diff when a previously accessed page changes. Amfora allows subscribing to pages (it fetches them periodically and notifies you when they change); this feature would work well together with a versioned local archive. To echo some other suggestions: - with something like geminitrack, you can save entire capsules in gempub format for offline reading; - resilience against servers going down is one of the main goals of IPFS.
Hi, Reminds me of FidoNet days, https://en.wikipedia.org/wiki/FidoNet#Zone_mail_hour There was /Zone Mail Hour for all nodes on the network? when they MUST accept mail traffic from anywhere. Also there were flags in the list describing when the node is available for connection. / On 21.09.2021 11:41, Alice wrote: > Hello, > > Are there any protocols that could be used with (say) Gemini for > capsules that are not always online ? > > The expectation that the whole internet is always online feels like a > massive waste of resource. It should be ok for a capsule to say "hey, > I'm not online. Come back later, or check this mirror". Instead we get > fatal looking errors. > > Maybe custom TXT DNS entries could specify when to expect the capsule > to be available, and where to find mirrors ? > > Anyone knows of any such protocol that could be used with Gemini ? > > :-) > Alice > -- --- Serg Podtynnyi
On 21 September 2021 18:10:45 BST, nervuri <nervuri at disroot.org> wrote: >On Tue, 2021-09-21, Alice wrote: >>Are there any protocols that could be used with (say) Gemini for capsules that are not always online ? > >A more feasible idea is for Gemini and Gopher clients to keep local >archives of visited pages, so that they can be accessed when servers are down [...] > >To echo some other suggestions: >- with something like geminitrack, you can save entire capsules in > gempub format for offline reading; >- resilience against servers going down is one of the main goals of IPFS Archiving or caching capsule content are both good approaches to making the content available when the capsule is down. But that's only one part of the problem. One thing it doesn't do is tell new users "hey, this capsule is offline right now, but it will be back tomorrow". 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. :-) Alice
>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. 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.
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.
Omar, 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? ==================== 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.
On 22 September 2021 08:52:37 BST, Omar Polo <op at omarpolo.com> wrote: > >Love the idea, I'm tempting to drafting something in my client ^^" Awesome ! >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.) Agreed - as someone pointed out in this thread, the only thing that can cover all cases is a scripting language - which would be too complex an approach imo. And even that wouldn't cater for unpredictable schedules (e.g. "my capsule is available when I'm on #some-irc-channel") Best to deal with the simple, human oriented scenario first. > >There are registrar that disallow txt records? Lot of other services >(gitlab pages comes to mind for example) requires user to set TXT >records. Also SPF and dkim require TXT records - and these are needed for anyone who wants email at their own domain. My registrar hides TXT records under an "Advanced" tab, but it's available. :-) Alice
Hello, Alice <lia at loveisanalogue.info> writes: > Hello, > > Are there any protocols that could be used with (say) Gemini > for capsules that are not always online ? A while back I came across this project: http://solarprotocol.net/ They try to route traffic to the currently on server. That would require that capsules are hosted as a few copies. I guess. But small groups of folks doing hosting at home could do this. I don't know the technical details involved. And it seems to me that still some component must be always online. If a capsule is down today I try it tomorrow again. If a capsule registers new content to Antenna, I can see, it's changing, i.e. "not dead". Cheers, ~ew -- Keep it simple!
That solarprotocol.net thing looks really interesting, thanks for sharing
Hi, On 22 Sep 2021, at 11:36, Alice wrote: >> >> There are registrar that disallow txt records? Lot of other services >> (gitlab pages comes to mind for example) requires user to set TXT >> records. > > Also SPF and dkim require TXT records - and these are needed for > anyone who wants email at their own domain. > > My registrar hides TXT records under an "Advanced" tab, but it's > available. > when using TXT records (which might not be the best choice for this function), they should be stored at a well-known subdomain. The DNS currently has the problem that too many applications try to store information in TXT records on the base domain name, that creates all kinds of operational issues for the DNS service and for the applications. For example take a look at "dig microsoft.com txt" or "dig twitter.com txt". Storing more TXT records at that place will make the situation worse. A well-know subdomain for Gemini parameter information could be something like _gemini_parameter.domain.tld. TXT "online-start=090000" "online-end=220000" "language=en" Another (maybe technically better) alternative could be the new SVCB "Service binding and parameter specification via the DNS" record: <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https> Greetings Carsten
Carsten, I havent touched DNS properly, is this aspect easy to look into. Could public-inbox serve as an alternative approach? => https://public-inbox.org/README ``` By storing (and optionally) exposing an inbox via git, it is fast and efficient to host and mirror public-inboxes. Traditional mailing lists use the "push" model. For readers, that requires commitment to subscribe and effort to unsubscribe. New readers may also have difficulty following existing discussions if archives do not expose Message-ID and References headers. List server admins are also burdened with delivery failures. public-inbox uses the "pull" model. Casual readers may follow the list via NNTP, IMAP, Atom feed or HTML archives. If a reader loses interest, they simply stop following. Since we use git, mirrors are easy-to-setup, and lists are easy-to-relocate to different mail addresses without losing or splitting archives. _Anybody_ may also setup a delivery-only mailing list server to replay a public-inbox git archive to subscribers via SMTP. ``` ==================== Jonathan McHugh indieterminacy at libre.brussels September 22, 2021 12:33 PM, "Carsten Strotmann" <carsten at strotmann.de> wrote: > Hi, > > On 22 Sep 2021, at 11:36, Alice wrote: > >>> There are registrar that disallow txt records? Lot of other services >>> (gitlab pages comes to mind for example) requires user to set TXT >>> records. >> >> Also SPF and dkim require TXT records - and these are needed for > anyone who wants email at their >> own domain. >> >> My registrar hides TXT records under an "Advanced" tab, but it's > available. > > when using TXT records (which might not be the best choice for this function), they should be > stored at a well-known subdomain. > > The DNS currently has the problem that too many applications try to store information in TXT > records on the base domain name, that creates all kinds of operational issues for the DNS service > and for the applications. > > For example take a look at "dig microsoft.com txt" or "dig twitter.com txt". Storing more TXT > records at that place will make the situation worse. > > A well-know subdomain for Gemini parameter information could be something like > > _gemini_parameter.domain.tld. TXT "online-start=090000" "online-end=220000" "language=en" > > Another (maybe technically better) alternative could be the new SVCB "Service binding and parameter > specification via the DNS" record: <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https> > > Greetings > > Carsten
>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.) Right, the <schedule> and <contact details> in my example were simply meant to be placeholders for a natural language description of both of those things, not some formal specification that'd be machine readable. While being machine readable might be nice, I think the least effort for the most reward implementation is just a natural language message the capsule host can stick in their DNS and clients can fetch and display as is.
(Wasn't sure where to reply to so doing on the thread root) One currently possible way to detect the "severity" of the issue is via ping-ing the server. If the Gemini request fails, the client could (automatically or not) ping the server to see if it's the server that's down or just the Gemini capsule. Ping being ICMP control messages 0 & 8 => https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol -Oliver Simmons (GoodClover)
Alice <lia at loveisanalogue.info> writes: > On 22 September 2021 08:52:37 BST, Omar Polo <op at omarpolo.com> wrote: >> >>Love the idea, I'm tempting to drafting something in my client ^^" > > Awesome ! I gave it a shot. https://tmp.omarpolo.com/telescope-offline-dns.png the code is https://git.omarpolo.com/telescope/ in the proposal/offline-dns-message branch. To be honest, I've optimized the code for "quick to write" rather than quality, and so I haven't committed it to the main branch. Needs some further polishing, improvements and documentation, but it's working a demo. Following Chris advice, I picked a "well-known" subdomain _offline (I liked it more than _gemini_parameter). Cheers, Omar Polo
On Tue, Sep 21, 2021 at 09:41:44AM +0100, Alice <lia at loveisanalogue.info> wrote a message of 39 lines which said: > Are there any protocols that could be used with (say) Gemini for > capsules that are not always online ? That could be interesting for some low-tech environments such as servers powerd by solar energy (whch is not almways available) <https://solar.lowtechmagazine.com/about.html>. > The expectation that the whole internet is always online feels like > a massive waste of resource. I agree. Some protocols (UUCP, DTN, etc) are designed for intermittent connectivity. (For DTN, start with RFC 4838 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc4838.txt> then RFC 5050 and 5325.) > It should be ok for a capsule to say "hey, I'm not online. Come back > later, or check this mirror". Instead we get fatal looking errors. In the lively discussion in this thread about machine-readable vs. human-readable text, nobody mentioned the serious issue of internationalization. Not everyone reads english. > Maybe custom TXT DNS entries could specify when to expect the > capsule to be available, and where to find mirrors ? Since unavailability of the capsule may not be known in advance (such as with the example of a solar-powered capsule), DNS, with its caches, may not be the best solution.
On Tue, Sep 21, 2021 at 11:35:18AM +0200, Felix Quei?ner <felix at masterq32.de> wrote a message of 26 lines which said: > OFFLINE: Our business times are 08:00 to 18:00 CEST A detail but, in an international system like the Internet, never use local time zones. People may not know them, and some time zones acronyms are ambiguous. Always use UTC. (Or TAI for ?ber-geeks.) > OFFLINE: Sorry. Looks like i have a power outage again. Should be back up in > 20 minutes! Even worse since you don't know how old is the message. (It's the same problem with capsules announcing "this will be done next week" when the text does not mention the date where it was written. HTTP has the - almost useless in practice - Last-Modified: but Gemini must relies on the text.)
"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.
On Tue, Sep 21, 2021 at 06:50:52PM +0000, Chris McGowan <cmcgowan9990 at gmail.com> wrote a message of 21 lines which said: > 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. Detail: it is not always the registrar, it is the DNS hoster which may be the registrar or a third-party or yourself if you self-host your authoritative name servers.
On Wed, Sep 22, 2021 at 09:52:37AM +0200, Omar Polo <op at omarpolo.com> wrote a message of 38 lines which said: > I'm not convinced it is worth for robots to know these schedules, I know at least one use case: Lupa writes off capsules which are unreachable for more than N days so it may dismiss a capsule which works most of the time but was, by bad luck, down when the crawler tried it.
On Wed, Sep 22, 2021 at 12:32:34PM +0200, Carsten Strotmann <carsten at strotmann.de> wrote a message of 41 lines which said: > For example take a look at "dig microsoft.com txt" or "dig twitter.com txt". Small reminder for the people who don't use an Unix machine and have no "dig": you can do DNS queries from Gemini, see <gemini://gemini.bortzmeyer.org/software/dns.gmi>. <gemini://gemini.bortzmeyer.org/dns/microsoft.com/TXT> is indeed wonderful.
On Wed, Sep 22, 2021 at 04:39:10PM +0100, Oliver Simmons <oliversimmo at gmail.com> wrote a message of 12 lines which said: > One currently possible way to detect the "severity" of the issue is > via ping-ing the server. Many machines/networks don't reply to or block the messages used by ping so it is not realistic. > Ping being ICMP control messages 0 & 8 With IPv4 only.
On 22 September 2021 17:51:28 BST, Omar Polo <op at omarpolo.com> wrote: > >I gave it a shot. > > https://tmp.omarpolo.com/telescope-offline-dns.png > So cool ! I'll have to try your client :-) > >Following Chris advice, I picked a "well-known" subdomain _offline (I >liked it more than _gemini_parameter). > It's an interesting question: should it be Gemini specific ? What if different protocols pick up on the idea, and you host multiple protocols on the same domain. Would we want one general message for the domain (so not Gemini specific) or would we want a specific message per protocol ? I'd go for simplicity (so message per domain, as you've done) but I guess some people might prefer the other way. :-) Alice
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:
On Wed, Sep 22, 2021 at 06:45:57PM +0100, Alice <lia at loveisanalogue.info> wrote a message of 28 lines which said: > Would we want one general message for the domain (so not Gemini specific) or would we want a specific message per protocol ? > > I'd go for simplicity (so message per domain, as you've done) but I guess some people might prefer the other way. Well, port 443 to some.thing.example may go to a different machine than port 1965, thanks to the various "routers" we have now, so there is no reason they will share the same fate. I suggest to get inspiration from the DANE protocol and to prefix the name with the port: _443._tcp.some.thing.example IN TXT "The Web server works" _1965._tcp.some.thing.example IN TXT "The Gemini server will be back at 21:00 UTC"
On Tue, 2021-09-21, Alice wrote: >The expectation that the whole internet is always online feels like a >massive waste of resource. It should be ok for a capsule to say "hey, >I'm not online. Come back later, or check this mirror". Instead we get >fatal looking errors. An example: https://oh.mg/bbs/news/merci-free/ "I've redirected the domain temporarily to my hosting account with Netcup, but Gemini, Gopher, and the BBS just won't be online until I move and the connection is installed in the new place."
??????? Original Message ??????? Le jeudi 23 septembre 2021 ? 20:05, nervuri - nervuri at disroot.org a ?crit : > An example: > > https://oh.mg/bbs/news/merci-free/ I have actually been watching this thread with some interest, so thank you for bringing up my example :D Gemini is the kind of protocol that always isn't going to find itself in a data centre some where. I've pretty much always self hosted my capsule with a brief period I ran it off of a VM in DreamHost. In my self hosted hell scenario, other than spinning up a virtual machine, having to faff around with a web server, remount all the drives, issue new certs, etc - I don't have another way to get the message out that the capsule isn't dead, it's just that my ISP has been dicking around for the past month (still no activation ETA btw). This concept would be perfect for the occasional hiccup (it's in my house an oopsie happened), or in a longer term problem (eg don't forget I'm here, because I'll be back). -K?vin
---