Ahoy there Geminauts, I've been loosely following Gemini for a few months waiting for inspiration to strike. And a couple nights ago it finally happened. The aesthetics of Gemini have always put me in mind of classic interactive fiction, which is something I've always loved - from the classic Infocom games up to today's Twine games. For a long time I've had a dream of writing a good interactive fiction game the way some people dream of writing a novel. I've started in on Twine games a few times in the past few years, but always get side-tracked with all of the features and my brain running in a million directions adding more and more complexity, I can't actually get anything worthwhile out. Anyway, I figured it might be fun to get to learn Gemini and Golang _and_ build myself a limited-functionality framework for interactive fiction. And that's what GemIF is going to be. Basically you use a YAML file to configure your scenes and transitions and GemIF takes care of the rendering and user interaction. The only user interaction is following links to move between scenes. There are a few more features I'm looking to add (basic conditionals, mostly), but I'm very much looking to keep it simple purposely. Then hopefully I can get to actually telling a story finally - probably not, though. I've gone on about this for long enough, here's some links:
On 02-Dec-2020 01:37, Norm MacLennan wrote: > I've gone on about this for long enough, here's some links: > > * Demo site: gemini://gemif.fedi.farm > * Source: https://git.sr.ht/~nromdotcom/GemIF > > Lemme know what you think or if there's anything you'd like to see here. > The code is pretty rough due to (a) me still being a Go novice and (b) > kinda rushing through to get a proof of concept together, but if you're > willing to dive into the code I wouldn't turn away any collaborators. Hi Norm Its great to see a gemini interactive fiction engine. I had a walk around the demo instance to get a feel for it. Its a great start, but I'm afraid it breaks the forward and back navigation in my client, and might affect other clients too. This is because each rendered page has the same URL. I would suggest some sort of simple modification should fix it, for example a simple step number, like this maybe gemini://server/path/sessionguid/step e.g. gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/1 gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/2 gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/3 etc Or some other marker - it doesn't have to be an incrementing index. This would then work in a wider range of clients and they'd be able to back and forward through their session. Regards - Luke
On 12/2/20 4:13 AM, Luke Emmet wrote: > Its a great start, but I'm afraid it breaks the forward and back > navigation in my client, and might affect other clients too. This is > because each rendered page has the same URL. > > I would suggest some sort of simple modification should fix it, for > example a simple step number, like this maybe > > gemini://server/path/sessionguid/step > > e.g. > > gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/1 > gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/2 > gemini://gemif.fedi.farm/game/cb3e4821-c316-4124-a2f7-fa82a7110ed5/3 > etc > > Or some other marker - it doesn't have to be an incrementing index. This > would then work in a wider range of clients and they'd be able to back > and forward through their session. Hey Luke, Thanks for checking it out and thanks for the feedback. Since I was always opening a new Amfora tab to test, I hadn't considered how it breaks back/forward but you're completely right. Due to the nature of how the application currently works, I'm going to have to do some noodling on how to fix this. Though your suggestion will likely be some part of it. If I wanted to keep the low complexity of the app as it is now, I could even do away with the notion of "games" completely and just have it move you between a static URI for each room. That is, ``` # GemIF This is the homepage. => gemini://gemif.fedi.farm/room/the_beginning start the game ``` And on the next page ``` # The Beginning Some description. => gemini://gemif.fedi.farm/room/the_middle_a make choice a => gemini://gemif.fedi.farm/room/the_middle_b make choice b ``` That would probably be the most straightforward way of not hijacking history for the clients as the user could freely jump back and forward due to stable URLs and lack of server-side state. However, it becomes a little problematic if I want to introduce actual game state (e.g. you have the key because you made choice b). So I'll need to do some thinking on how important such state is to me (and anyone else interested). It originally seemed fairly integral to the ability to create a branching narrative without forcing the author to repeat themselves, but maybe it's not actually necessary or just not something I need to think about yet. If I do decide to implement simple game state, I'll likely play with your suggestion. But in stories where game state is used have it render something like the below when the user goes back to a previous page: ``` # Invalid Game State This story doesn't allow time travel. => gemini://gemif.fedi.farm/game/my_game_id/latest_recorded_step Go back to the current scene => gemini://gemif.fedi.farm/ Exit game ``` Because otherwise I'm stuck selectively rolling back game state on the server side. While it's not ideal and some users will find the messages annoying, it should at least be a bit more pleasant than their clients throwing error messages about non-existent exits or whatever it's doing now. And it means I don't need to worry about server-side needing to be able to selectively roll-back game state (or at least not immediately and I can add that feature later). Thanks again for the feedback, it has definitely been useful. If you think of anything else let me know. Thanks, Norm
Hi, On Wed, 2020-12-02 at 01:37 +0000, Norm MacLennan wrote: > Ahoy there Geminauts, > > I've been loosely following Gemini for a few months waiting for > inspiration to strike. And a couple nights ago it finally happened. > > The aesthetics of Gemini have always put me in mind of classic > interactive fiction, which is something I've always loved - from the > classic Infocom games up to today's Twine games. I recently got sucked into Stay: https://ejadelomax.itch.io/stay - which is built using a not-web-specific IF engine called Ink: https://www.inklestudios.com/ink/ While reading up on the language, I did find it quite gemini-like. GemIF looks interesting, but I'm curious what you think of the ink approach, and whether a gemini exporter (like the existing web exporter) for the existing editors would make more sense? If not, you might find the language used by Ink more compelling than a yaml file. I do find myself thinking that it would be fun to play Stay on Gemini rather than the web ^^. /Nick
On 12/2/20 10:28 AM, Nick Thomas wrote: > I recently got sucked into Stay: https://ejadelomax.itch.io/stay - > which is built using a not-web-specific IF engine called Ink: > https://www.inklestudios.com/ink/ > > While reading up on the language, I did find it quite gemini-like. > GemIF looks interesting, but I'm curious what you think of the ink > approach, and whether a gemini exporter (like the existing web > exporter) for the existing editors would make more sense? If not, you > might find the language used by Ink more compelling than a yaml file. > > I do find myself thinking that it would be fun to play Stay on Gemini > rather than the web ^^. > > /Nick Hey Nick, I'm not familiar with Ink, but it looks pretty cool. I haven't looked into how the project is persisted on disk nor how exporters work, but I bet making an exporter for simple Ink stories into a Gemini static site would be possible. But it looks like Ink has some more advanced features like conditions and variables which wouldn't lend themselves to a static site format and would require a server to keep track of gamestate (where I assume the web exporter does everything client-side with Javascript). In that case, unless I'm missing something, a Gemini exporter would basically need to scaffold and generate the entire server for each story - at least for stories that require conditions and variables. In which case it might make sense to build a pre-made server to be the engine and just generate configuration for the individual stories to keep the exporter relatively simple. Probably you can see where I'm going with this, but once GemIF has rough feature parity with Ink it might be interesting to look into making a GemIF exporter that generates the YAML from your Ink project. But I haven't really looked into the structure of Ink projects or the full feature-set beyond basic syntax to know what that might look like or if it's even feasible. Maybe once I do I'll find a better configuration format than YAML, cause I agree giant YAML files are the worst. But I figured it was halfway between human readable and machine readable and I could build some tooling to generate it from something easier to read and maintain in the future. Thanks for linking me to this, if nothing else it will give me more prior art to draw from but potentially also shows a valuable integration for the future. Thanks, Norm
On Wed, 2020-12-02 at 18:55 +0000, Norm MacLennan wrote: > > In that case, unless I'm missing something, a Gemini exporter would > basically need to scaffold and generate the entire server for each > story > - at least for stories that require conditions and variables. In > which > case it might make sense to build a pre-made server to be the engine Hmm. Perhaps the best way to go about this would be a cgi-bin script that can take a compiled ink story (turns out it compiles to json) and use client certificates + a persistent server-side data store for user state. The script would be the same for every story, it'd "just" need a way to store per-user state. If you want to focus on GemIF specifically, I might have a crack at this, it sounds fun. > Maybe once I do I'll find a better > configuration format than YAML, cause I agree giant YAML files are > the worst. I've not actually looked at *how* ink's language compiles down to json, but I wonder how many unique ways there really are to represent a branching storyline in this kind of format. It'd be amazing if the two formats ended up being compatible just through convergent evolution :D. > Thanks for linking me to this, if nothing else it will give me more > prior art to draw from but potentially also shows a valuable > integration > for the future. Best of luck! Keep us updated on exciting new stories as they arise :).
On 02-Dec-2020 19:22, mbays at sdf.org wrote: > * Wednesday, 2020-12-02 at 09:12 +0000 - Luke Emmet<luke at marmaladefoo.com>: > >> Its a great start, but I'm afraid it breaks the forward and back navigation >> in my client, and might affect other clients too. This is because each >> rendered page has the same URL. > Isn't it that this has exposed an incorrect assumption in the client, > rather than a problem with (the original implementation of) GemIF? > > There's no assumption of idempotence in gemini, two requests to the > same url might well return different responses. So I'd have thought > that consecutive requests to the same url should get separate history > items, at least if the responses aren't identical (and then to > minimise surprise, also if they are). I'm firmly of the camp that thinks that although there are many things the web got wrong ultimately, the hypertext model is basically right (see Roy Fieldin thesis and HATEOS etc). And indeed it is the established mental model for textual hypertext. Breaking the "back" button on the web is generally considered a bad idea and I think it is true on Gemini too for the same reasons. Rather, I think we should/can make a defacto assumption of idempotence in Gemini. Gemini requests are incredibly similar to HTTP GET requests, which are the "idempotent" and dominant method of hypertext on the web. We don't have the equivalent of the non-idempotent POST methods in Gemini. But maybe there are other solutions for that, or it might come one day. So repeatedly reloading the same resource, is the equivalent to a reload, hence when you go "back" it is back to the previous URL. - Luke
On Thu, 3 Dec 2020, Luke Emmet wrote: > > I'm firmly of the camp that thinks that although there are many things the > web got wrong ultimately, the hypertext model is basically right (see Roy > Fieldin thesis and HATEOS etc). And indeed it is the established mental model > for textual hypertext. Breaking the "back" button on the web is generally > considered a bad idea and I think it is true on Gemini too for the same > reasons. > > Rather, I think we should/can make a defacto assumption of idempotence in > Gemini. Gemini requests are incredibly similar to HTTP GET requests, which > are the "idempotent" and dominant method of hypertext on the web. We don't > have the equivalent of the non-idempotent POST methods in Gemini. But maybe > there are other solutions for that, or it might come one day. > > So repeatedly reloading the same resource, is the equivalent to a reload, > hence when you go "back" it is back to the previous URL. > > - Luke > I love a lot of the self-imposed "limitations" and simplicity of Gemini and I definitely still have a lot of unlearning of HTTP-based habits and instincts still to do. But I will also suggest that for some folks, the best part in working in systems with self-imposed limitations is figuring out how to push the boundaries, test the limits, and basically apply creative hacks to subvert those limitations. All of that being said, in the particular case of GemIF, I've already started "Gemini-ifying" it a bit. At the suggestion of a user who emailed me directly rather than replying to the thread (perhaps accidentally), I've converted to using "state tokens". Serialized and encoded game state in the URL simplifies the server side and _shouldn't_ break navigation. There's still a "pseudo-PUT" on every action you take to update your game state and return to you your new state token in the form of a redirect. I intend to have the server pre-calculate state tokens for every exit to construct direct links on every page and prevent the extra request/redirect each time. So in this case, I would say you are absolutely right and I just needed to do some unlearning of habits from other protocols, but I'm not sure I'm willing to categorically state all requests must be idempotent. Or perhaps I'm just willing to agree that such a thing makes sense for the spec and then being surprised at the crazy things people come up with when they start pushing the limits.
On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote: > I'm not sure I'm willing to categorically state all requests must be > idempotent. I have the same feeling, but I think it's well-founded. Gemini requests don't map well to HTTP GET semantics at all - we just don't have the safety guarantees we need for it. A simple example - imagine I build a gemini client that prefetches all links on the current page in the background, for performance. If they're all HTTP GETs in principle, this is fine. However, like any bad web 1.0 application that used links + GET instead of form buttons + POST for actions, my browser will make astrobotany no fun to play at all, as I simultaneously water, shake, and feed my plant each time I visit it. Any given Gemini link may or may not change server-side state, and it's impossible to tell from protocol-level information. It's not a bad thing, per se, it just isn't like GETs. /Nick
On 03-Dec-2020 23:20, Nick Thomas wrote: > On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote: > >> I'm not sure I'm willing to categorically state all requests must be >> idempotent. > I have the same feeling, but I think it's well-founded. Gemini requests > don't map well to HTTP GET semantics at all - we just don't have the > safety guarantees we need for it. > > A simple example - imagine I build a gemini client that prefetches all > links on the current page in the background, for performance. If > they're all HTTP GETs in principle, this is fine. > > However, like any bad web 1.0 application that used links + GET instead > of form buttons + POST for actions, my browser will make astrobotany no > fun to play at all, as I simultaneously water, shake, and feed my plant > each time I visit it. Well for all its retro quirky ascii art cuteness, Astrobotany is a bit of an outlier in this respect. It can get away with "abusing" gemini links only because it sits behind a layer of authentication, that restricts access to the links within the application. It would be a much safer application to implement in Gemini had a proper non-cacheable non-idempotent method. For example, consider that GUS (and other agents) visit all our sites on a semi-regular basis. this means that all the links will be activated many times. If there is a link somewhere => liveendpoint click this link if you liked my article this will be activated an aribitrary number of times, and is a mismatch for gemini as links in a public hypertext system are - in general - idempotent. If some other contrarian gemini author put 20 (or 1000) links to that live end point on their gemsite, whenever GUS comes to visit, I'm going to get 20 new "likes" One other point that is relevant here is that the "input" method (meta 10 and 11) do not really help, since again they are implemented as parameterised links (/path/to/endpoint?inputcontent). As such they can be reused as persistable links. But this is all we have in Gemini, so authors and developers do their best to work around the natural restrictions. Its the same on the web - there is a limit to the types of application you can implement with just normal links. If you want to change state, you need a post method (or equivalent/JSON etc). I'd be interested in what a non-cacheable, non-persistable, non-idempotent "post" type method would look like in Gemini, but at the moment we just have sort of hacks to try to fake it as best we can in some limited scenarios. - Luke ______________________________________
Le vendredi 4 d?cembre 2020, 00:20:05 CET Nick Thomas a ?crit : > A simple example - imagine I build a gemini client that prefetches all > links on the current page in the background, for performance. I just wanted to point out that this is forbidden by the specification: ?Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).? C?me
> On Dec 4, 2020, at 10:55, C?me Chilliet <come at chilliet.eu> wrote: > > I just wanted to point out that this is forbidden by the specification: Go ahead, try to stop me :D P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it uses to sport. Accidental? On purpose? What gives?
> On Dec 4, 2020, at 11:03, Petite Abeille <petite.abeille at gmail.com> wrote: > > P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it used to sport. Accidental? On purpose? What gives? The change seems to have occurred silently around November 22nd, end-of-day... thoughts? ( And please, let's not drag Mr Rosenthal into this :)
On 04.12.20 11:30, Petite Abeille wrote: > > >> On Dec 4, 2020, at 11:03, Petite Abeille <petite.abeille at gmail.com> wrote: >> >> P.S. Has something changed in the Reply-To behavior of the mailing list? It seems to be missing the Reply-To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> header now, which it used to sport. Accidental? On purpose? What gives? > > The change seems to have occurred silently around November 22nd, end-of-day... thoughts? > > ( And please, let's not drag Mr Rosenthal into this :) > We've suggested that change to the postmaster (as migadu.com). Reply-To header gets DKIM signed. Modifying or appending the Reply-To header breaks DKIM signature which along with failing SPF will make for certain DMARC failure and possibly rejection. That has lead to forced unsubscribing. The mailing list (mailman) does not know the reason for message rejection (DMARC policy) and threats that as if the subscriber is unreachable. -- ????? ??????
> On Dec 4, 2020, at 12:28, Dejan Strbac <me at dejanstrbac.com> wrote: > > We've suggested that change to the postmaster (as migadu.com). ( Who is "we"? ) Very unfortunate move, for the wrong reasons, with unfortunate consequences. DKIM+DMARC+SPF configuration quirks aside -and ignoring the reality that all/most other mailing lists do seem to manage just fine- assuming this list is a DISCUSSION list, replies should go to the list.
> DKIM+DMARC+SPF configuration quirks aside -and ignoring the reality that all/most other mailing lists do seem to manage just fine- assuming this list is a DISCUSSION list, replies should go to the list. SPF / DMARC aside, at least DKIM should not fail when mails get forwarded through a mailing list, proving authenticity. Email client should detect it's a mailing list and offer a "Reply-List" option. I am not sure Apple Mail (your client?) supports that, there is an open question there: https://discussions.apple.com/thread/251508297 e.g. Thunderbird handles mailing list messages correctly and provides automatically a Reply-List option based on the List- headers. -- ????? ??????
> On Dec 4, 2020, at 12:53, Dejan Strbac <me at dejanstrbac.com> wrote: > > Apple Mail ( Apple's Mail helpfully detects 'List-Unsubscribe:' and tantalizingly dare you to :^) Irrespectively of MUA, could we revert back to the setup pre November 22nd, and fix the rest of the stack instead.
On 04-Dec-2020 09:55, C?me Chilliet wrote: > Le vendredi 4 d?cembre 2020, 00:20:05 CET Nick Thomas a ?crit : >> A simple example - imagine I build a gemini client that prefetches all >> links on the current page in the background, for performance. > I just wanted to point out that this is forbidden by the specification: > ?Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).? I get the strong recommendation on this - and I take this to be a strong recommendation/exhortation for human facing clients behaviour. Its not a protocol invariant that must be preserved to ensure correct transmission or anything. Some user facing clients (for example one of the web proxies) load linked images as an "experimental" feature. But I get that there is a strong cultural exhortation against the expectation that images will be loaded. Personally for a human facing client I prefer that the images are not automatically loaded, or expected by the author that they will be loaded (unlike the web). And we need to consider that the ecosystem does not just contain human facing clients - there are proxies, archivers, indexers, which are also Gemini clients. They will be traversing geminispace as well, at their own time, schedule and frequency. - Luke
> Irrespectively of MUA, could we revert back to the setup pre November 22nd, and fix the rest of the stack instead. I don't think the point for the change was understood here. When Mailman is set to assert the Reply-To header to "list", it will invalidate the mail signature by many servers making others regard the email as forged. This was a slip up on this list; other lists on this server as set to not alter the Reply-To header. It is my opinion, and that of others, that this is best solved by mail clients observing the List-* headers. Further more, I recommend the use of "reply-all" as a default, because it is possible for a list to receive an email from someone who is not subscribed. With reply-all, your email client shall include both the person and the list, thus eliminating the reply-to issue. It also let's the recipient know they were being addressed in the response (commonly known as "mentioned").
> On Dec 4, 2020, at 14:28, orbifx ? <fox at orbitalfox.eu> wrote: > > it will invalidate the mail signature True. But this will happen anyway (e.g. attachment stripping or whatnot). remove_dkim_headers to the rescue? Sender Rewriting Scheme (SRS)? > best solved by mail clients observing the List-* headers True. Sadly, List-* headers support is, hmmm, uneven. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d883 2674/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: pacman.gif Type: image/gif Size: 2025 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d883 2674/attachment.gif>
> On Dec 4, 2020, at 14:28, orbifx ? <fox at orbitalfox.eu <mailto:fox at orbitalfox.eu>> wrote: > > use of "reply-all" as a default mwahahaha , I presume you never witnessed an email storm :D https://en.wikipedia.org/wiki/Email_storm <https://en.wikipedia.org/wiki/Email_storm> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/f8b7 70d7/attachment-0001.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: he-replied-all-new-yorker-cartoon_u-l-pysimf0.jpg Type: image/jpeg Size: 23656 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/f8b7 70d7/attachment-0001.jpg>
Ah, that would explain why so many of the emails to this list were getting thrown into my spam folder before now. Leaving it as it is help alleviate that, right? On Fri, Dec 4, 2020 at 8:30 AM orbifx ? <fox at orbitalfox.eu> wrote: > > Irrespectively of MUA, could we revert back to the setup pre November > 22nd, and fix the rest of the stack instead. > > I don't think the point for the change was understood here. > > When Mailman is set to assert the Reply-To header to "list", it will > invalidate the mail signature by many servers making others regard the > email as forged. This was a slip up on this list; other lists on this > server as set to not alter the Reply-To header. > > It is my opinion, and that of others, that this is best solved by mail > clients observing the List-* headers. > > Further more, I recommend the use of "reply-all" as a default, because it > is possible for a list to receive an email from someone who is not > subscribed. With reply-all, your email client shall include both the person > and the list, thus eliminating the reply-to issue. It also let's the > recipient know they were being addressed in the response (commonly known as > "mentioned"). > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/6b90 4e32/attachment.htm>
> On Dec 4, 2020, at 15:40, David Ashby <delta.mu.alpha at gmail.com> wrote: > > ... why so many of the emails to this list were getting thrown into my spam folder ... As seen through the lenses of gmail's web ui presumably? FWIW, accessing gmail through IMAP doesn't have such shortcoming.
On Fri, Dec 4, 2020 at 9:40 AM David Ashby <delta.mu.alpha at gmail.com> wrote: > Ah, that would explain why so many of the emails to this list were getting > thrown into my spam folder before now. Leaving it as it is help > alleviate that, right? > I had to tell Gmail that traffic sent to this list is never spam. So far I haven't been bothered, but it's annoying to get the big gray warning on many (not all) messages. > On Fri, Dec 4, 2020 at 8:30 AM orbifx ? <fox at orbitalfox.eu> wrote: > >> > Irrespectively of MUA, could we revert back to the setup pre November >> 22nd, and fix the rest of the stack instead. >> >> I don't think the point for the change was understood here. >> >> When Mailman is set to assert the Reply-To header to "list", it will >> invalidate the mail signature by many servers making others regard the >> email as forged. This was a slip up on this list; other lists on this >> server as set to not alter the Reply-To header. >> > Quite apart from this point, the arguments of Chip Rosenthal's classic "Reply-to Munging Considered Harmful" < https://unicom.crosenthal.com/pw/reply-to-harmful.html> are still as sound as ever, though the problem of "brain-dead mailers" that don't support both Reply and Reply All is probably no longer an issue. I QFT his summary, though I recommend reading the document in full: Many people want to munge Reply-To headers. They believe it makes reply-to-list easier, and it encourages more list traffic. It really does neither, and is a very poor idea. Reply-To munging suffers from the following problems: - It violates the principle of minimal munging. - It provides no benefit to the user of a reasonable mailer. - It limits a subscriber's freedom to choose how he or she will direct a response. - It actually reduces functionality for the user of a reasonable mailer. - It removes important information, which can make it impossible to get back to the message sender. - It penalizes the person with a reasonable mailer in order to coddle those running brain-dead software. - It violates the principle of least work because it complicates the procedure for replying to messages. - It violates the principle of least surprise because it changes the way a mailer works. - It violates the principle of least damage, and it encourages a failure mode that can be extremely embarrassing -- or worse. - Your subscribers don't want you to do it. Or, at least the ones who have bothered to read the docs for their mailer don't want you to do it. For this list I will emphasize the next to last point. I frequently screw up and choose Reply instead of Reply All. The recipient often asks me if I meant to send it to the list, and one of us then does it: the situation is fully recovered from. Choosing Reply All in place of Reply cannot be recovered from, and can have social consequences anywhere from temporary embarrassment up to a "career-limiting move". (For future reference, if you get an email from me beginning with "(Private Message)" in response to a list posting it is truly private; if not, it is me screwing up.) In addition to Chip's points, I would add the weight of RFC 2822, "Internet Message Format" (which didn't yet exist when Chip wrote): "When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent." Mailing list software is not "the author of the message". John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/6084 f3d5/attachment-0001.htm>
> On Dec 4, 2020, at 16:08, John Cowan <cowan at ccil.org> wrote: > > Chip Rosenthal's classic "Reply-to Munging Considered Harmful" Let him rest in peace. ?Considered Harmful? Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html > Mailing list software is not "the author of the message". What's the PURPOSE of a mailing list but to foster DISCUSSION? Why to impede its raison d'?tre? IOTD (Idiom of the day): https://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face
On Fri, Dec 4, 2020 at 10:20 AM Petite Abeille <petite.abeille at gmail.com> wrote: > > Chip Rosenthal's classic "Reply-to Munging Considered Harmful" > > Let him rest in peace. > "Death will not release you. (Even if you die.)" --rule 0 of the Los Angeles Science Fantasy Society (Has he in fact died since 2016? He has a common name, but I can't find anything that looks like an obituary.) ?Considered Harmful? Essays Considered Harmful > https://meyerweb.com/eric/comment/chech.html I respond to that with the two laws of FidoNet: 1. Thou shalt not be excessively annoying. 2. Thou shalt not be too easily annoyed. > > Mailing list software is not "the author of the message". > > What's the PURPOSE of a mailing list but to foster DISCUSSION? > True. But not all discussion is best held in public. Some is off-topic, some would offend certain list members, some is potentially slander. In any case, this is a religious issue, and I have no desire to start a religious war, so this is my last post on this topic. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/5df3 84ea/attachment.htm>
On 4 December 2020 18:24:58 GMT+00:00, mbays at sdf.org wrote: >* Friday, 2020-12-04 at 07:53 +0000 - Luke Emmet ><luke at marmaladefoo.com>: > >> On 03-Dec-2020 23:20, Nick Thomas wrote: >> > On Thu, 2020-12-03 at 23:11 +0000, Norm MacLennan wrote: >> > > I'm not sure I'm willing to categorically state all requests >must >> > > be idempotent. >> >> Astrobotany is a bit of an outlier in this respect. It can get away >> with "abusing" gemini links only because it sits behind a layer of >> authentication, that restricts access to the links within the >> application. > >Actually, this might be a good convention: we could declare that any >gemini request should be treated as idempotent, i.e. GETlike, *unless* >the server is sent a client certificate as part of the connection >handshake (for the original connection, in the case of session >resumption). I've been mulling over this one a bit - the search engine example is very good. Client certificates aren't the worst heuristic here, but i do see the potential for false positives & negatives. Now we have robots.txt, we *could* say that non-idempotent requests (state-changing ones in general, really) ought to be protected in there. That ups the importance of any crawler actually paying attention to it - and my hypothetical, but spec-forbidden, eager loading client could use it to behave safely too (it could be reimagined as a local caching proxy to work around the prohibition on following links without user interaction, i guess). This feels more appropriate to me than the client certificate heuristic, since it's *possible* for robots.txt to make conforming clients be safe 100% of the time. /Nick
It was thus said that the Great mbays at sdf.org once stated: > > Actually, this might be a good convention: we could declare that any > gemini request should be treated as idempotent, i.e. GETlike, *unless* > the server is sent a client certificate as part of the connection > handshake (for the original connection, in the case of session > resumption). Define "state change", because this link on my server: gemini://gemini.conman.org/qotd literally makes a state change on every request (it pulls up the next quote, and it tracks the number across restarts). -spc
On Fri, Dec 4, 2020 at 4:28 PM Sean Conner <sean at conman.org> wrote: Define "state change", because this link on my server: > > gemini://gemini.conman.org/qotd > > literally makes a state change on every request (it pulls up the next > quote, and it tracks the number across restarts). > I'm with Sean here. There are a large number of very simple services that Gemini systems could easily provide that would be banned under an idempotent-only rule. Historically, quote-of-the-day could be gotten from a server by connecting on port 17 with either TCP or UDP; see the /etc/services file and RFC 865. (Sean, you might want to support port 17 just for hack value; if anybody connects to it, forget TLS: just blast back the first 512 bytes of the next quote and close the connection.) Other examples that could be geminized are: 1. The current time in a human readable (including HTTP and ISO) format per RFC 867 (historically on port 13). 2. The current list of users connected to the server (for some definition of "users", "connected" and "server"), one on each line per RFC 866 (historically on port 11). 3. An endless stream of characters for testing streaming clients per RFC 864 (historically on port 19). I once set up a whole lot of workstations after working hours to connect to this port (using gopher://foo:19/0 via a test firewall) in order to see how much of this the firewall could take without crashing. It held up fine, though the browsers eventually crashed. 4. The current phase of the moon (no RFC). 5. The Really Big ASCII Button That Doesn't Do Anything (see < https://krystalrose.com/rosewood/library/BigButton.htm>; copies of this page date back to 1993). Finally, if you look at RFC 7231, HTTP 1.1, you'll find that all of these
It was thus said that the Great John Cowan once stated: > On Fri, Dec 4, 2020 at 4:28 PM Sean Conner <sean at conman.org> wrote: > > Define "state change", because this link on my server: > > > > gemini://gemini.conman.org/qotd > > > > literally makes a state change on every request (it pulls up the next > > quote, and it tracks the number across restarts). > > I'm with Sean here. There are a large number of very simple services that > Gemini systems could easily provide that would be banned under an > idempotent-only rule. Historically, quote-of-the-day could be gotten from > a server by connecting on port 17 with either TCP or UDP; see the > /etc/services file and RFC 865. (Sean, you might want to support port 17 > just for hack value; if anybody connects to it, forget TLS: just blast back > the first 512 bytes of the next quote and close the connection.) Did you try it? Because I do run a QOTD server on port TCP port 17. In fact, the Gemini link gets the quote from my QOTD server (and the same with my gopher server, only the quote is on the main page). I don't quite follow the RFC (it will send a quote longer than 512 bytes) but hey, this is 2020, not 1983. I used to support QOTD via UDP until I found out it was used in amplification attacks and had to drop UDP support (this is why we can't have nice things on the Internet). -spc (We now resume our regularly scheduled bikeshedding, currently in progress ... )
On Fri, Dec 4, 2020 at 9:13 PM Sean Conner <sean at conman.org> wrote:
> Did you try it? Because I do run a QOTD server on port TCP port 17.
I confess I did not. And I certainly did not expect the Oblique
Strategies! ("Nobody expects ...") Kudos. I once designed (but didn't
get a chance to implement) an IRC bot named teddybot[*] that most of the
time said nothing when you addressed it, but occasionally would hand you a
Strategy instead.
[*] http://www.unconsciousagile.com/teddy_bear_effect
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
I should say generally that that marriage was best auspiced, for the
achievement of happiness, which contemplated a relation between a man and a
woman in which the independence was equal, the dependence mutual, and the
obligations reciprocal. --Louis Anspacher (1944)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201204/d0a6
d32e/attachment-0001.htm>
On Wed, 2 Dec 2020, Nick Thomas wrote: > Hmm. Perhaps the best way to go about this would be a cgi-bin script > that can take a compiled ink story (turns out it compiles to json) and > use client certificates + a persistent server-side data store for user > state. The script would be the same for every story, it'd "just" need a > way to store per-user state. That's a neat idea. I haven't yet had a chance to inspect Ink's file format, but I'll keep that in mind once I finally get around to it. Right now I'm working on the project foundation because, well, it's fun. But also so the project is healthy and maintainable if/when I try to add Ink integration. What I _have_ done is simplify the server-side by making use of state tokens in the URL. Rather than tracking games and state in-memory server side, the server instead serializes the game state out into a token (configurable as JSON or Protobuf) in the URL. That way, each action link on the page just contains a "speculative" state token. This also wildly simplifies state rollback when the user navigates backward in their client since the state token contains everything anyway. It also means games still work across server restarts (and theoretically even across _servers_ with the same stories) without having to persist sessions anywhere. Another new addition is writing stories in `.gemif` format rather than YAML format and "compiling" to YAML via a new `gemifc` command. Right now, it's just a very minor abstraction over the YAML, but it's a start and does make writing a little more pleasant. Scene metadata and transitions are still written in YAML format in (essentially) YAML frontmatter, while scene descriptions are now just plaintext. Each `.gemif` file can contain one or more scenes and each story can contain one or more .gemif file. Anyway, you can see some examples in the repo [1], so I don't take up too much space trying to explain it. The other thing the samples demonstrate is the use of conditions. Transitions can attach conditions to the game state, which can then be used for conditional rendering in the scene descriptions as well as allowing or disallowing the use other transitions based on which conditions are present. There's still a ways to go since I'm just learning a lot of these technologies, but I'm pretty happy with how things are shaping up so far. [1] https://git.sr.ht/~nromdotcom/gemif/tree/master/stories/src/conditions
---
Previous Thread: [ANN] Play Tic Tac Toe through gemini
Next Thread: variable indentation levels / hierarchy in lists