💾 Archived View for gemi.dev › gemini-mailing-list › 000162.gmi captured on 2023-11-04 at 12:29:45. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/5aca a3d7/attachment.htm>
> On May 29, 2020, at 05:18, poomklao at yahoo.com wrote: > > # Images > > Elegant form: > IMG /static/fun.png "Alt text to display if you're in a terminal" Talking of which... what about Data URLs [1] in text/gemini link lines? Kosher? How are they meant to be handled? Inline? As attachment? Verboten? [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
> On May 29, 2020, at 05:18, poomklao at yahoo.com wrote: > > # Blockquotes > > Pretty much the same as in Markdown: > > >> Gemini is a new, collaboratively designed internet protocol, which explores the space in between gopher and the web. > >> > >> It strives to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other. > > I think we need to be careful, because we could very well > > > > uh > > > > inherit the worst of both of them Ehehe! :D Actually, blockquotes (or should it be linequotes?), are more in the spirit of text/gemini line oriented format. And they predate markdown by a a good decade, or two, or three: https://en.wikipedia.org/wiki/Posting_style#Quoted_line_prefix https://en.wikipedia.org/wiki/Usenet_quoting
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/06ae b3df/attachment-0001.htm>
> On May 29, 2020, at 06:20, poomklao at yahoo.com wrote: > > Gar nicht verboten. > > => gemini://gemini.conman.org/test/torture/0021 Ohhh... shiny! data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D Let's see what else is hiding in those marvelous URI schemes: https://en.wikipedia.org/wiki/List_of_URI_schemes
It was thus said that the Great Petite Abeille once stated: > > > > On May 29, 2020, at 05:18, poomklao at yahoo.com wrote: > > > > # Images > > > > Elegant form: > > IMG /static/fun.png "Alt text to display if you're in a terminal" > > Talking of which... what about Data URLs [1] in text/gemini link lines? > > Kosher? How are they meant to be handled? Inline? As attachment? Verboten? Funny you should ask that: gemini://gemini.conman.org/test/torture/0021 -spc (Expect a flurry of tests now ... ) > [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
> On May 29, 2020, at 07:08, Sean Conner <sean at conman.org> wrote: > > Funny you should ask that: > > gemini://gemini.conman.org/test/torture/0021 > > -spc (Expect a flurry of tests now ... ) Got to say, this is a fantastic resource. Thank you very much. For the record: torture test https://portal.mozz.us/gemini/gemini.conman.org/test/torture/ Much excellent. If anything, you just have superior tooling: https://github.com/spc476/LPeg-Parsers E.g.: https://github.com/spc476/LPeg-Parsers/blob/master/http-client.lua You command of lpeg is to be commanded. For the curious: http://www.inf.puc-rio.br/~roberto/lpeg/
It was thus said that the Great Petite Abeille once stated: > > On May 29, 2020, at 07:08, Sean Conner <sean at conman.org> wrote: > > > > Funny you should ask that: > > > > gemini://gemini.conman.org/test/torture/0021 > > > > -spc (Expect a flurry of tests now ... ) > > Got to say, this is a fantastic resource. Thank you very much. You're welcome. > If anything, you just have superior tooling: > > https://github.com/spc476/LPeg-Parsers > > E.g.: > > https://github.com/spc476/LPeg-Parsers/blob/master/http-client.lua Oh man ... you just happened to pick one of the parsers I haven't finished yet [1]. The header names need to be matched case-insensitively, which they aren't, and I haven't finished with all the headers yet. Ah well. > You command of lpeg is to be commanded. It took a few years, but I'm now at the stage were I can pretty much answer any LPEG question out there. I use it extensively in GLV-1.12556 as well. > For the curious: > > http://www.inf.puc-rio.br/~roberto/lpeg/ -spc [1] If it doesn't have a rockspec, it's not finished.
poomklao at yahoo.com writes: > Backwards-compatible form: > => image:/static/fun.png "Image: My cute little cat" Please no....! > I think that only one form should be picked, but I'm not sure > which. Also, I know that solderpunk doesn't really like embedded > stuff... They're not the only one! >I miss it form the Web though. I get this, but honestly if there's one sure-fire way to allow corporate branding, ads, and other evilness into gemini, I really believe it's this. Anyway, if you want these things, you can always just serve text/html or text/markdown over gemini. Tim
> I get this, but honestly if there's one sure-fire way to allow corporate > branding, ads, and other evilness into gemini, I really believe it's this. > > Anyway, if you want these things, you can always just serve text/html or > text/markdown over gemini. Also, nobody forbids that a client *may* serve links to images/videos inline instead of displaying them only as a link. We have the freedom to do so and nobody is hurt by doing or not doing it
> # Blockquotes > > Pretty much the same as in Markdown: > > >> Gemini is a new, collaboratively designed internet protocol, which explores > the space in between gopher and the web. > >> > >> It strives to address (perceived) limitations of one while avoiding the > (undeniable) pitfalls of the other. > > I think we need to be careful, because we could very well > > > > uh > > > > inherit the worst of both of them I think block quotes may be a nice rendering extension, but are not essential, as we can always just use the text in raw form instead of having a defined formatting.
On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote: > Ohhh... shiny! > > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D > > Let's see what else is hiding in those marvelous URI schemes: ...let's not take delight in actively trying to crush the spirit of this thing? I mean, the web is right there if that's what you want. Cheers, Solderpunk
On Fri, May 29, 2020 at 09:35:20AM +0000, solderpunk wrote: > On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote: > > > Ohhh... shiny! > > > > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D > > > > Let's see what else is hiding in those marvelous URI schemes: > > ...let's not take delight in actively trying to crush the spirit of this > thing? I mean, the web is right there if that's what you want. Ugh, sorry about this email. I was irritable from a lack of good sleep and waking up to a whole slew of posts here about extra complications, just as I was starting to feel we were at last approaching a kind of "cross the t's and dot the lowercase j's" state where there wasn't much left to add. But I have no idea what your intended tone was and it may well have just been tongue in cheek. Mostly I was just annoyed at learning that these data:// URLs exist. I hadn't been aware of them. And frankly...what the hell? Who thought it was a good idea to turn a harmless way to indicate *where* some data can be found into a way to shoehorn in the data itself? What are we supposed to use in a context where we don't want that to be a possibility? Bah! Cheers, Solderpunk
> On May 29, 2020, at 15:15, solderpunk <solderpunk at SDF.ORG> wrote: > > Ugh, sorry about this email. No worries. > I was irritable from a lack of good sleep > and waking up to a whole slew of posts here about extra complications, > just as I was starting to feel we were at last approaching a kind of > "cross the t's and dot the lowercase j's" state where there wasn't much > left to add. But I have no idea what your intended tone was and it may > well have just been tongue in cheek. Just kicking the tires, I actually do like retro tech ?? No harm intended. > Mostly I was just annoyed at > learning that these data:// URLs exist. I hadn't been aware of them. > And frankly...what the hell? Who thought it was a good idea to turn a > harmless way to indicate *where* some data can be found into a way to > shoehorn in the data itself? Larry Masinter Internet pioneer and ACM Fellow ?? https://en.wikipedia.org/wiki/Larry_Masinter ? RFC 1737 Functional Requirements for Uniform Resource Names (K. Sollins, L. Masinter) ? RFC 1738 Uniform Resource Locators (URL) (T. Berners-Lee, L. Masinter, M. McCahill) ? RFC 1867 Form-based File Upload in HTML (E. Nebel, L. Masinter) ? RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (L. Masinter) ? RFC 2368 The mailto URL scheme (P. Hoffman, L. Masinter, J. Zawinski) ? RFC 2388 Returning Values from Forms: multipart/form-data (L. Masinter) ? RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter) ? RFC 2397 The "data" URL scheme (L. Masinter) ? RFC 2532 Extended Facsimile Using Internet Mail (L. Masinter, D. Wing) ? RFC 2534 Media Features for Display, Print, and Fax (L. Masinter, D. Wing, A. Mutz, K. Holtman) ? RFC 2542 Terminology and Goals for Internet Fax (L. Masinter) ? RFC 2616 Hypertext Transfer Protocol?HTTP/1.1 (R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee) ? RFC 2718 Guidelines for new URL Schemes (L. Masinter, H. Alvestrand, D. Zigmond, R. Petke) ? RFC 2732 Format for Literal IPv6 Addresses in URL's (R. Hinden, B. Carpenter, L. Masinter) ? RFC 2854 The 'text/html' Media Type (D. Connolly, L. Masinter) ? RFC 2938 Identifying Composite Media Features (G. Klyne, L. Masinter) ? RFC 2972 Context and Goals for Common Name Resolution (N. Popp, M. Mealling, L. Masinter, K. Sollins) ? RFC 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols (S. Hollenbeck, M. Rose, L. Masinter) ? RFC 3553 An IETF URN Sub-namespace for Registered Protocol Parameters (M. Mealling, L. Masinter, T. Hardie, G. Klyne) ? RFC 3778 The application/pdf Media Type (E. Taft, J. Pravetz, S. Zilles, L. Masinter) ? RFC 3986 Uniform Resource Identifier (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter) ? RFC 4395 Guidelines and Registration Procedures for New URI Schemes (T. Hansen, T. Hardie, L. Masinter) ? RFC 6068 The 'mailto' URI Scheme (M. Duerst, L. Masinter, J. Zawinski) ? RFC 7578 Returning Values from Forms: multipart/form-data (L. Masinter) ? RFC 7995 PDF Format for RFCs (L. Masinter) > What are we supposed to use in a context > where we don't want that to be a possibility? Bah! 5.3.2 Link lines is arguably the best feature of Gemini. With TLS. Less is more, love it. But of course, at the same time, it opens the door to creative tampering of sort. On the other hand, the destructive creativity will be limited to the client side. And may never gain traction in practice. Supply & demand & all. All in the spirit of Gemini: Clients can present links to users in whatever fashion the client author wishes. In term of damage control, we could perhaps arbitrary limit link lines' length to 1024 bytes, similarly to 2 Gemini requests. This will not discourage miscreant from using, like, *two* lines for their misdeeds, but at least the protocol itself would have made the point -loud and clear- about how it feels about it. Either way, nothing to lose sleep over. "Great job, team. Head back to base for debriefing and cocktails. " -- Spottswoode, Team America: World Police, 2004 -- PA
solderpunk <solderpunk at SDF.ORG> writes: > Mostly I was just annoyed at learning that these data:// URLs exist. > I hadn't been aware of them. And frankly...what the hell? Who thought > it was a good idea to turn a harmless way to indicate *where* some > data can be found into a way to shoehorn in the data itself? What are > we supposed to use in a context where we don't want that to be a > possibility? Bah! On the web, they make sense as a way of inlining short content, like icons, and avoiding a server round-trip. But obviously, they don't make sense for Gemini, and there's no reason clients should support them. If you want lolcats, just link to the image file. I do it all the time in my gemlogs. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
poomklao at yahoo.com writes: > I think that only one form should be picked, but I'm not sure which. > Also, I know that solderpunk doesn't really like embedded stuff... I > miss it form the Web though. Inline images break the principle of "one request per page". I was there when inline images were added to HTML, and while I was excited at the time, in retrospect, that's where things started to go pear shaped. > # Blockquotes > > Pretty much the same as in Markdown: I actually really want blockquotes (pretty much the same as in Usenet, as someone else pointed out). My only concern is how they might complicate implementing line wrapping. I also think they should not be nestable. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote: > On the web, they make sense as a way of inlining short content, like > icons, and avoiding a server round-trip. But obviously, they don't make > sense for Gemini, and there's no reason clients should support them. There's no reason they *should*, but they can. And some of them will. And then people will think of this as normal and expect it and design their documents around it, and the snowball will roll... I tried *so* hard to avoid this, but you just can't. This data:// URL thing is a monster. No RFC puts a limit on the allowed length of a URL. And the data:// scheme includes MIME types. So they are a vehicle for arbitrary content of arbitrary size. Turns out this entire time Gemini - and even it's hypothetical deliberately stripped-back cousin Mercury - has allowed embedding of inline images, audio and videos. It's just impossible to avoid this stuff unless you throw out URLs entirely and start with something else, in which case the effort to learn the spec and implement it skyrockets because you can't leverage existing knowledge and code. I was naive to think the internet was made out of little do-one-thing-and-do-it-well components you could compose in novel ways to build things of deliberately limited scope. Turns out it's made of a few massively overpowered blobs and it's impossible to build anything small. Yes, alright, to some extent abuse of this loophole will be limited by the fact that all this content has to be downloaded in a single file in a single transaction before any of it can be displayed, so the user experience will be miserable if there is more than just a little bit of embedded content. We won't quite end up as bad as the web. But still! This is just unspeakably frustrating. Cheers, Solderpunk
On 5/29/20 2:42 PM, solderpunk wrote: > I tried *so* hard to avoid this, but you just can't. Perhaps I'm missing something, but I don't think we've got a really big problem here. Links can link to anything; sure, but a client deciding to inline their display will create a monster of a user experience even if they try to do it with simple images. There's no sizing at work. There's no positioning available. If a site tries to very carefully link to images in a way designed to be inlined, a hundred more will not be doing that. The client's attempts to display those things will break browsing for its users and, hopefully, not gain popularity. If someone wants to do something edge-casey that only works in very specific situations then cool. I don't see it as a threat to gemini because of the guardrails you already have in place.
On Fri, May 29, 2020 at 10:18:48AM +0700, poomklao at yahoo.com wrote: > <div dir='auto'>I have a couple of silly ideas for extra formatting:<div dir="auto"><br></div><div dir="auto"># Images</div><div dir="auto"><br></div><div dir="auto">Elegant form:</div><div dir="auto">IMG /static/fun.png "Alt text to display if you're in a terminal"</div> This definitely isn't happening. It *screams* for extension. Even if the spec only defined IMG, clients would immediately start also supporting VID and SND. It's way too slippery a slope. Futhermore, anything which encourages clients to make additional requests while processing the results of an earlier request is definitely not happening. The privacy game is over then, and many other important games are over too. It's the end of user autonomy. We end up with the current situation on the web where you follow a link and you have no idea what's going to happen as a result and you just subject yourself to the will of whoever authored the text/html on the other side. Will your browser connect to 1 host or 10 hosts or 100 hosts? Nobody knows! Will one of those hosts belong to a company whom I don't want my computer talking to because I think they're evil? Nobody knows! Will my computer start making sounds, even though I'm in a library or a quiet cafe or I have the radio on beside me? Nobody knows! This is a disaster we have to avoid at all costs. The user needs to be in control of this stuff. Presenting links for them to follow *if* they want and *when* they want gives them that control. Inlining content takes it away. We should respect people's bandwidth and we should respect people's attention. # Blockquotes</div><div dir="auto"><br></div><div dir="auto">Pretty much the same as in Markdown:</div><div dir="auto"><br></div><div dir="auto">>> Gemini is a new, collaboratively designed internet protocol, which > explores the space in between gopher and the web.</div> I'm much less bothered by blockquotes, they are totally inoffensive, degrade nicely if ignored and treated as text, and several people have asked for them. In fact, I've already said I'll probably add them to the spec, as another optional line type. Cheers, Solderpunk
On Fri, May 29, 2020 at 04:06:26PM +0000, solderpunk wrote: > This is a disaster we have > to avoid at all costs. The user needs to be in control of this stuff. > Presenting links for them to follow *if* they want and *when* they want > gives them that control. Inlining content takes it away. We should > respect people's bandwidth and we should respect people's attention. I realise, by the way, that this hardcore "cyber-granola" attitude is not an explicitly stated goal of the project anywhere, so people might feel like it's coming out of nowhere. To be honest, the FAQ etc. were never written with a really general audience in mind. This used to be a small project where almost everybody involved was coming from Gopherspace and/or pubnixspace, so all this stuff was just kind of implicit and obvious and went without saying. Hacker News felt a million miles away! Perhaps this should change. I am *big* on user autonomy. Cheers, Solderpunk
> On May 29, 2020, at 18:06, solderpunk <solderpunk at SDF.ORG> wrote: > > We should respect people's bandwidth and we should respect people's attention. I will personally take this to heart. After all, I wish to use Gemini for my own pedestrian reasons. That said, if *I* would like *my* =>geo:13.4125,103.8667 link, in *my* own authored text/gemini, to magically turn into some wacky inline Map Web Snapshot behemoth [1], *I* will damn do so. Because it's my time, my bandwidth, my attention, and my ultimate decision. Specification's feelings be damned ? [1] https://developer.apple.com/documentation/snapshots
> On May 29, 2020, at 16:42, solderpunk <solderpunk at SDF.ORG> wrote: > > No RFC puts a limit on the allowed length of a URL ? RFC822 (?1982) ? RFC2822 (?2001) ? RFC5322 (?2008) 2.1.1. Line Length Limits There are two limits that this standard places on the number of characters in a line...
Petite Abeille writes: > That said, if *I* would like *my* =>geo:13.4125,103.8667 link, in *my* > own authored text/gemini, to magically turn into some wacky inline Map > Web Snapshot behemoth [1], *I* will damn do so. As long as you're only talking about how things render on _your_ computer, I agree. But it's ultimately _my_ choice how to interpret _your_ authored text/gemini on _my_ computer. This is going off-topic, but I think users tend to lose this power when faced with the gigantic sprawling mass of complexity that html+js+css has become. There are only 2 or 3 (?) independent client implementations in the *world*, meaning that nobody, to a very good approximation, has a real choice in how their devices interpret that mess in a useful way. ` Contrast this with gopher and gemini, where implementations abound, and someone like me - who's not a software engineer by any stretch - can: (a) be _completely_ in control of the (at least application-level) details of what my computer does with the stuff servers send me, and (b) still usefully extract, with my own clients, the majority of the meaning that people are trying to convey using the protocols. I'm _very_ thankful for the efforts people here have gone through to try to ensure that users continue to have this level of control over the behaviour of their own hardware. Sorry for the ramble, but you struck a nerve! :-) Tim
> On May 29, 2020, at 20:10, plugd <plugd at thelambdalab.xyz> wrote: > > As long as you're only talking about how things render on _your_ > computer, I agree. But it's ultimately _my_ choice how to interpret > _your_ authored text/gemini on _my_ computer. Absolutely. We are in total agreement. To each their own client. There is a plethora to choose from: https://portal.mozz.us/gemini/gemini.circumlunar.space/software/ It's all happening between cleared-eyed, consenting adults. ??
solderpunk <solderpunk at SDF.ORG> writes: > On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote: > >> On the web, they make sense as a way of inlining short content, like >> icons, and avoiding a server round-trip. But obviously, they don't make >> sense for Gemini, and there's no reason clients should support them. > > There's no reason they *should*, but they can. And some of them will. > And then people will think of this as normal and expect it and design > their documents around it, and the snowball will roll... Can't we just say: "A spec-compliant client MUST NOT display data: URLs inline; a client MAY treat data: URLs as links to media, to be opened only on user request."? -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
On 29-May-2020 21:37, Jason McBrayer wrote: > Can't we just say: "A spec-compliant client MUST NOT display data: URLs > inline; a client MAY treat data: URLs as links to media, to be opened > only on user request."? Can't see that would work - how about automated clients like spiders that crawl to build a search index for GUS etc? I think whilst we may disapprove, we cant enforce the behaviour of a client to interpret content served. - Luke
Jason McBrayer writes: > Can't we just say: "A spec-compliant client MUST NOT display data: URLs > inline; a client MAY treat data: URLs as links to media, to be opened > only on user request."? While ideal, I think Postel's law will eventually bite you there - correctly formatted pages will render just fine without clients forbidding data: URLS, while incorrectly formatted pages will only work on clients technically violating the spec. How about this: it's a bit of a hack, but imagine if we explicitly harnessed data URLs to do something vaguely useful? e.g. => data://a%20person%20dancing ``` \o/ | / \ ``` I know, I know, very silly - but _if_ there were a way to make data:// URLs an indispensible part of text/gemini it would make it very difficult to abuse them without breaking things, wouldn't it? Tim
Sorry ignore my last remarks about spiders in the email below, I didn't spot it was just referring to data:// URLs. Still it seems hard to enforce a singular client behaviour with respect to interpreting content. Luke > On 29 May 2020, at 22:09, Luke Emmet <luke.emmet at gmail.com> wrote: > >> On 29-May-2020 21:37, Jason McBrayer wrote: >> Can't we just say: "A spec-compliant client MUST NOT display data: URLs >> inline; a client MAY treat data: URLs as links to media, to be opened >> only on user request."? > Can't see that would work - how about automated clients like spiders that crawl to build a search index for GUS etc? > > I think whilst we may disapprove, we cant enforce the behaviour of a client to interpret content served. > > - Luke
On Fri, May 29, 2020 at 01:15:33PM +0000, solderpunk wrote: > Who thought it was a good idea to turn a harmless way to indicate > *where* some data can be found into a way to shoehorn in the data > itself? What are we supposed to use in a context where we don't > want that to be a possibility? Bah! I think it is completely reasonable to specify a set of allowed schemes whose use aligns with gemini's goals. For the sake of a concrete example, perhaps:
It was thus said that the Great solderpunk once stated: > On Fri, May 29, 2020 at 09:35:20AM +0000, solderpunk wrote: > > On Fri, May 29, 2020 at 06:34:29AM +0200, Petite Abeille wrote: > > > > > Ohhh... shiny! > > > > > > data: urls could be perhaps an interesting way to inline content in text/gemini... LOLcats at long last! :D > > > > > > Let's see what else is hiding in those marvelous URI schemes: > > > > ...let's not take delight in actively trying to crush the spirit of this > > thing? I mean, the web is right there if that's what you want. > > Ugh, sorry about this email. I was irritable from a lack of good sleep > and waking up to a whole slew of posts here about extra complications, > just as I was starting to feel we were at last approaching a kind of > "cross the t's and dot the lowercase j's" state where there wasn't much > left to add. But I have no idea what your intended tone was and it may > well have just been tongue in cheek. Mostly I was just annoyed at > learning that these data:// URLs exist. I hadn't been aware of them. > And frankly...what the hell? Who thought it was a good idea to turn a > harmless way to indicate *where* some data can be found into a way to > shoehorn in the data itself? What are we supposed to use in a context > where we don't want that to be a possibility? Bah! As I mentioned in my previous email, data: URIs can be "followed" just as any other URI, it's just that the data has already been "pre-cached" so to speak. And since it comes with a MIME-type as part of the scheme, it can be displayed in a client as any other MIME-type, just not automatically inlined. And trying to whitelist "acceptable" URI schemes is pointless as there are scores of schemes that are defined: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml not all of which actually point to a resource, like urn: (RFC-8141). And speaking of urn:, it's specification states (section 4.1): Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (to name just a few, the "href" and "src" attributes in HTML, the base element in HTML, the "xml:base" attribute in XML [XML-BASE], and the "xmlns" attribute in XML for XML namespace names [XML-NAMES]). However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource (e.g., the aforementioned "href" and "src" attributes). Ultimately, guidelines regarding when it is appropriate to use URIs under the "urn" scheme (or any other scheme) are the responsibility of specifications for individual URI protocol slots (e.g., the specification for the "xml:base" attribute in XML might recommend that it is inappropriate to use URNs in that protocol slot). This specification cannot possibly anticipate all of the relevant cases, and it is not the place of this specification to require or restrict usage for individual protocol slots. So it might be prudent to state in the Gemini spec that 1) urn: is not a valid URI type for links, and 2) NO INLINING OF LINKS ALLOWED [1]. -spc (You have my permission to do so 8-) [1] I have more to say about this in an upcoming email.
It was thus said that the Great solderpunk once stated: > On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote: > > > On the web, they make sense as a way of inlining short content, like > > icons, and avoiding a server round-trip. But obviously, they don't make > > sense for Gemini, and there's no reason clients should support them. > > There's no reason they *should*, but they can. And some of them will. > And then people will think of this as normal and expect it and design > their documents around it, and the snowball will roll... > > I tried *so* hard to avoid this, but you just can't. This data:// URL > thing is a monster. No RFC puts a limit on the allowed length of a URL. RFC-2397 (The "data" URL scheme) states (section 2): The "data:" URL scheme is only useful for short values. Note that some applications that use URLs may impose a length limit; for example, URLs embedded within <A> anchors in HTML have a length limit determined by the SGML declaration for HTML [RFC1866]. The LITLEN (1024) limits the number of characters which can appear in a single attribute value literal, the ATTSPLEN (2100) limits the sum of all lengths of all attribute value specifications which appear in a tag, and the TAGLEN (2100) limits the overall length of a tag. So there are, in fact, limits. -spc
It was thus said that the Great plugd once stated:
> Jason McBrayer writes:
> > Can't we just say: "A spec-compliant client MUST NOT display data: URLs
> > inline; a client MAY treat data: URLs as links to media, to be opened
> > only on user request."?
>
> While ideal, I think Postel's law will eventually bite you there -
> correctly formatted pages will render just fine without clients
> forbidding data: URLS, while incorrectly formatted pages will only work
> on clients technically violating the spec.
>
> How about this: it's a bit of a hack, but imagine if we explicitly
> harnessed data URLs to do something vaguely useful?
>
> e.g.
>
> => data://a%20person%20dancing
That's the incorrect format. It should be:
=> data:text/plain,a%20person%20dancing
> ```
> \o/
> |
> / \
> ```
> I know, I know, very silly - but _if_ there were a way to make data://
> URLs an indispensible part of text/gemini it would make it very
> difficult to abuse them without breaking things, wouldn't it?
The issue is when someone does something like:
=> data:image/jpeg;base64,YSBwZXJzb24gZGFuY2luZw...
```
\o/
|
/ \
```
-spc
Sean Conner writes: > That's the incorrect format. It should be: > => data:text/plain,a%20person%20dancing Sure, but the point is to _abuse_ the data: URL so as to make it useless. > The issue is when someone does something like: > > => data:image/jpeg;base64,YSBwZXJzb24gZGFuY2luZw... > ``` > \o/ > | > / \ > ``` But that will render horribly in clients that are obeying the spec where we abuse the contents of the data URL to specify the alt-text. I'm not actually suggesting this, to be honest - I'm just pointing out one technically feasible way of making it in the client author's best interest to prohibit using data: URLs to embed arbitrary content. Just saying to client authors, "you MUST refuse this URL type" isn't going to work. But making it somehow impossible for clients to simultaneously behave sensibly in the face of correctly formatted text/gemini _and_ interpret data: URLs as they are intended seems like it could work, at least in principle. Tim
It was thus said that the Great poomklao at yahoo.com once stated:
> I have a couple of silly ideas for extra formatting:
>
> # Images
>
> Elegant form:
>
> IMG /static/fun.png "Alt text to display if you're in a terminal"
>
> Backwards-compatible form:
>
> => image:/static/fun.png "Image: My cute little cat"
I'm picking this message as a starting point. I'm not trying to shame
poomklao for this idea, as people have been wanting something like this for
years [1]. And I promised an email about this earlier to day, when I said:
> NO INLINING OF LINKS ALLOWED
and here is the rational I have for this.
The idea is technically called "transclusion" and was coined by Ted
Nelson. "Transclusion" is the automatic inclusion of content into one
document from another one and was meant as a means of presenting a quote
(<blockquote> in HTML) from a particular version of a particular document
(with royalties and all that mess). We have a very limited form of it on
the Web---the only three mediums that can be directly transcluded are
images, video and sounds, none of which support transclusion themselves.
You also have a limited from with frames in HTML, but ...
Like all formal, well specified systems, things tend to go pear shaped [2]
when you allow self-referential references, and that's what transclusion (in
general) brings to the table. In the Hacker News thread about Gemini [4], a
person brought up transclusion [5] in text/gemini files with the following
syntax:
<= gemini://example.com/path/to/resource
and for the sake of argument, let's assume this does what it
indicates---that the document at the given link is inserted at that point
into the document being rendered [6]. For the example, let's say we are
obtaining the document <gemini://example.com/document.gemini>, and in that
document you have:
<= gemini://example.com/document.gemini
And thus the problem is revealed.
"But surely, you can keep track of all transcluded files to prevent this
from happening," you say. And yes, that is possible. But as the creator of
the Client Torture Test, I can assure you that I can create an endless
stream of unique documents that transclude an endless stream of unique
documents that transclude an endless stream of unique documents that
transclude an endless stream of unique documents th
Core error-bus dumped.
Where was I?
Oh yes, self-referential transclusion, or an infinite amount of
transclusion.
"But surely, like rediection, you can limit the depth of transclusion,"
you say. Yes, you can limit the level of transclusion, but that just adds
to the complexity of the implementation. An implementation would have to
both track the documents being transcluded plus the depth of transclusion.
Unlike rediects, where you just track the number of times you are being
redirected, transclusion is a bit more complex:
doc1 <= doc2 <= doc3 <= doc4 <= doc5
<= doc6
<= doc7
<= doc8 <= doc9
<= doc10
<= doc11
<= doc12 <= doc13
Just limited the depth of transclusion to 5 levels still leads to a
potential 626 documents being transcluded (if I did my math correctly). And
implementing just one level is annoying for little in return.
So while I like the idea of transclusion, I have to admit there are issues
when you can possibly transclude documents that transclude other documents.
So in this, I say:
NO INLINING OF LINKS ALLOWED!
-spc
[1] Starting in the 60s, with Ted Nelson and his Xanadu project.
[2] English (perhaps an Americanism) for "Situation Normal All Fouled
Up" [3]
[3] aka SNAFU.
[4] https://news.ycombinator.com/item?id=23042424
[5] https://news.ycombinator.com/item?id=23046008
[6] In the Hacker News comment, the transclusion is meant to be done by
the server, not the client. For my argument, it doesn't make a
difference *who* does the translusion.
> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote: > > [1] Starting in the 60s, with Ted Nelson and his Xanadu project. Ted! Xanadu! It never gets old :) EVERYTHING IS DEEPLY INTERTWINGLED https://en.wikipedia.org/wiki/Intertwingularity [ALL CAP AND ALL]
> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote: > > NO INLINING OF LINKS ALLOWED! In all due respect: this is wishful thinking at best, delusion at worst. But then again, the Gemini spec can -and perhaps should- be opinionated. Be the Zed Shaw and David Heinemeier Hansson of specification, all rolled into one... [1] [1] http://programming-motherfucker.com
> On May 29, 2020, at 18:06, solderpunk <solderpunk at SDF.ORG> wrote: > > This definitely isn't happening. To atone for any possible noise induced anxiety, here is a small token of gratitude for you: MAKER'S MAP Any creative act can be a perilous journey. A small box was discovered at the edge of a volcano containing coded notes from an unnamed source. Believed by many to be lost manuscripts from the failed expedition of a now forgotten explorer, the notes were pieced together and found to be a map of the creative process. We are proud to present you with this powerful tool as a reminder of all the frames of mind you have access to at any point as you work to bring something to life. This map is for creators who want to live and invite others to live also! Ahoi, Dreamer [1] The Fog of Fear [2] Wonder Mountain [3] ( via swissmiss at https://www.swiss-miss.com/2020/05/makers-map.html ) ( by montague workshop at https://shopmontagueworkshop.com/products/makers-map ) [1] https://cdn.shopify.com/s/files/1/1800/5841/products/makersmap01_1024x1024.jpg [2] https://cdn.shopify.com/s/files/1/1800/5841/products/IMG_0563_1024x1024.jpg [3] https://cdn.shopify.com/s/files/1/1800/5841/products/IMG_0549_1024x1024.jpg
> On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote: > > NO INLINING OF LINKS ALLOWED! Meanwhile, back on the interweb: http://subpixel.space/entries/open-transclude/ Also: https://subpixel.space/entries/introducing-quotebacks/
It was thus said that the Great Petite Abeille once stated: > > > On May 30, 2020, at 04:41, Sean Conner <sean at conman.org> wrote: > > > > NO INLINING OF LINKS ALLOWED! > > Meanwhile, back on the interweb: > > http://subpixel.space/entries/open-transclude/ Yes, but note that it only works within a certain context and is not a general solution to transclusion. Also, the transclusion is done by the client. A Gemini server *could* implement transclusion behind the scenes. > Also: > https://subpixel.space/entries/introducing-quotebacks/ I do this now. If you check this post of mine: http://boston.conman.org/2020/03/23.2 you should see a blockquote that links back to the original article. And if you check the source, you'll see I used the CITE attribute in the BLOCKQUOTE tag to *also* link to the source. Furthermore, when I use Firefox on Linux, I can highlight the portion of a page I want to quote, and using a special program, grab not only the HTML from the clipboard [1] but the URL, use that to grab the page again for the title, and automatically generate the BLOCKQUOTE for me. -spc (Amazing what's hidden under the hood, so to speak) [1] The X Windows selection mechanism is quote sophisticated and supports multiple MIME types (no, really!). I have some text highlighted in Firefox (under Linux) right now, and I can grab (among other values): text/html With the HTML UTF8_STRING sans HTML text/x-moz-url URL of the page You can read more about it here: https://www.jwz.org/doc/x-cut-and-paste.html
> On Jun 11, 2020, at 23:55, Sean Conner <sean at conman.org> wrote: > > I do this now. If you check this post of mine: > > http://boston.conman.org/2020/03/23.2 > > you should see a blockquote that links back to the original article. And if > you check the source, you'll see I used the CITE attribute in the BLOCKQUOTE > tag to *also* link to the source. Nifty :) ( got to say, I like the little hover effect in Quotebacks, which lift the blockquote oh-just-so-slightly from the surrounding text. nice visual emphasize ) > [1] The X Windows selection mechanism is quote sophisticated and > supports multiple MIME types (no, really!). I have some text > highlighted in Firefox (under Linux) right now, and I can grab > (among other values): > > text/html With the HTML > UTF8_STRING sans HTML > text/x-moz-url URL of the page > > You can read more about it here: > > https://www.jwz.org/doc/x-cut-and-paste.html Yes, ditto on the mac, curtesy of NSPasteboard: https://developer.apple.com/documentation/appkit/nspasteboard And yes, all those NS prefixes refers to NEXTSTEP to this day :D
---
Previous Thread: <META> overloading...
Next Thread: Trust model for addresses and certificates (DANE etc..)