While I get the intention behind simplifying the web and the way we author documents on it, just like gemini this misses the mark by simplifying to a degree that gives as less capabilities we have now in the medium of html/text.
For one thing, I think common mark is really the worst form of markdown and especially considering the whole angle of hacker culture and DIY these kind of projects clearly aim at, I am always baffled that something more feature rich and easy to interoperate with like pandoc flavored markdown is not chosen.
And tables are optional? That does not sound great for many Text documents to be honest. I would rather argue, forcing browsers to not only implement tables but sortable and filterable tables would give such a standard an immediate leg up over the existing web and browsers and is absolutely something people working with text documents would gain benefit from.
But to this point, I always fell a way back to a more text focused web should also have even more a focus on hypertext than the original web did. The real value besides having it run in simpler browsers would be to offer features that were never realized on the web but could revolutionize how we work with text. I like to see more inspired be Engelbart or Nelson and really bring forward a new, more useful sort of web. Of course, that adds complexity and that has to be careful managed, but besides the community around it, gemini, and looking at it also this, are mostly not more featured than swapping text files over ftp, and I feel this is really a shame.
Without JS means without any dynamic behaviour or interactivity.
But it also depends on what the goals of this new system are. Are we trying to make a simpler, faster, read-only web?
If we're going that way, I'd love to limit CSS to a minimal subset (or maybe nothing?), minimise support for embedded content types, remove input elements, and remove stuff like cookies.
Kind of - and I mentioned this earlier so sorry for the repeat - but taking HTMX and making it's tools standardized parts of browsers would be amazing.
I think the primary concern of these projects is feature creep, where you end up “why notting” your way back to the web as it currently stands: something originally intended to be incredibly simple that over time turned into a pile of hacks.
There is probably value in a project that aims to create a more intentionally designed and capable version of the web with standard rich interactive widgets, etc, but those would need to be separate projects with their own approach to keeping scope sane.
But who said it was "intended to be incredibly simple"?
It seems that some people look at the designs from the past and think "oh, whatever the designer came up with was the true final form of the idea" when in reality it was just that what they came up with was to deal with the constraints they were dealing with (costs, time, resource, etc).
I meant in relation to the "original web" creator.
I don't think at any point in time TBL's just went on to say "oh, HTTP and HTML are set in stone and no more use-cases are going to be added or promoted". The protocol was not designed to satisfy some subjective notion of "incredibly simple", it was made to satisfy the possible use-cases within the constraints of the time.
Which leads me to ask you: why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
> A simple protocol ("HTTP") is used to allow a browser program to request a keyword search by a remote information server.…
> Making a web is as simple as writing a few SGML files which point to your
existing data.…
--
> Which leads me to ask you: why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
I think the phrase "should be" bothers me here. I just had an idea and I'm gonna try to implement it. Most likely I will be the only person to do so, but if someone else thinks it's a good idea, they can implement it too if they wish, and that would be cool. I'm sure many people who are interested in KyuWeb's goals will read my proposal and my arguments in this thread and still decide that Gopher, Gemini, or the modern web is still the better route to take, and that's fine.
Saying that your design allows people to do things in a "simple" way is not the same as saying that the protocol is meant to be deploy only in the limited use-cases.
> I just had an idea and I'm gonna try to implement it.
You are (implicitly) asking people to conform to your design, though. Or would you continue working on it even if you were the sole user?
> You are (implicitly) asking people to conform to your design, though. Or would you continue working on it even if you were the sole user?
When you put it that way… certainly these sorts of projects are more rewarding and validating if other people find them as useful as I do, yes. I'd consider it a success beyond all expectation if KyuWeb saw even the modest usage numbers of Gemini, but even a fraction of that would be very motivating. So let me try again at answering your question.
> why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
Because I think there is a hole in the "market" for a system of interlinked hypertext documents which is just that and nothing more, and I think KyuWeb is a way to fill that hole in a manner that balances usefulness and ease of implementation better than the alternatives.
But yes, others are free to disagree or offer their own solutions. :)
> Because I think there is a hole in the "market" for a system of interlinked hypertext documents which is just that and nothing more
Ok, so what? Why is it so important for you that the system does "just that and nothing more"?
- There is nothing stopping you in the existing web to create the documents according to whatever limitations that you would like to have.
- There is nothing stopping you to filter/transform whatever documents you receive from outside to fit your liking.
- If "resource usage" is a problem for you, go ahead and browse the web using lynx. Bonus points, you'd still be able to browse the existing "document-oriented" web without forcing other people to conform to your limitations of KyuWeb.
- Even micro-controllers that cost pennies on the dollar have enough resources to run a basic http client. Your proposal does not make anything more accessible/affordable.
Don't take it personally, but this is the type of project that I really wish never gets any traction. This type of ascetic mentality seems to be rooted in good intentions but always carries some totalitarian undertone that bothers me.
It's okay to be a minimalist by filtering out things on your side, but it's actually harmful when this minimalism becomes a forced doctrine. I'm all for trying to have tools that filter the complexity of the existing web, but I do not want to cripple it because some of its usages affect my sensibilities.
I think the Gemini FAQ[1] has a good answer to this that I imagine is pretty in line with the Kyuweb proposal author's motivations.
Using an alternative protocol is completely optional for you as a user so I don't think calling it a forced doctrine is accurate. These kinds of protocols are great for people who want to have an experience of browsing a web of documents knowing that they won't be giving up privacy or be bombarded with interactive attention grabbing graphical elements, advertisements, videos etc. If that experience is not something you value, you can obviously choose not to use it.
> I'm all for trying to have tools that filter the complexity of the existing web, but I do not want to cripple it because some of its usages affect my sensibilities.
Filtering the modern web is not easy. Just try browsing with JavaScript disabled and count the number of annoyances you encounter in a day.
> optional for you as a user so I don't think calling it a forced doctrine is accurate.
Sure, if they provide some kind of gateway or mirror. But the moment that their content is only on a gemini server, I have to use a gemini client.
> These kinds of protocols are great for people who want to have an experience of browsing a web of documents knowing that they won't be giving up privacy or be bombarded with interactive attention grabbing graphical elements, advertisements, videos etc.
That is utter, complete bullshit. You don't need a new protocol for that. You just need a client that is a better fit for your needs and that can filter things for you.
> Just try browsing with JavaScript disabled and count the number of annoyances you encounter in a day.
On the flip side, think of all the websites and services in the existing web that use the technology in a sensible way and made your life better. This very website we are talking on would not exist.
By staying on the web and developing tools that improve the clients, we are trimming the downside and keeping the upside. By creating a new protocol you are negating all the upside and denying the existence of the downside it. IOW, you are just shutting yourself out like an ascetic monk. To me is an act of cowardice dressed as something virtuous.
All right, well, I guess this and other ideas just aren't going to appeal to you, and that's okay.
I will keep making sites on the normal web, both for myself and my clients. Hopefully one of those will strike your fancy. But if not, that's okay too.
> For one thing, I think common mark is really the worst form of markdown and especially considering the whole angle of hacker culture and DIY these kind of projects clearly aim at, I am always baffled that something more feature rich and easy to interoperate with like pandoc flavored markdown is not chosen.
Or something even better than MD, like reStructuredText.
OMG no. RST has such a random syntax it's impossible to remember anything. I really hate it (have to use it at work, its processor is slow as hell, just a horrible experience).
If I ever decide against Markdown, some sort of strictly-defined subset of HTML would probably be my second choice. As someone who's been building web sites since 1996, though, I find HTML unpleasant to use for writing prose, and less readable when unrendered than Markdown.
Taking what the HTMX project has done and making it standard in browsers (without a library) would go light-years towards bringing back the hypertext focus of the web.
I think everyone has there own set of killer features for something like this, here's mine.
* HTMX build in, gives 99% of modern page interactivity with no javascript
* No javascript.
* Yes images and videos, no custom video controls.
* Simplified CSS, all layout done via flexbox? The goal is to be able to not use HTML as part of your layout, but instead have HTML model your data as closely as possible. Looking at how simplified the HTML is for modern bootstrap compared to previous generations I think this is possible.
* Simplified HTML. There are a lot of older tags that probably shouldn't get used.
Everyone has their own set of killer features though, so it's a hard problem to coordinate on.
I think something very much like that could be really powerful as a native GUI toolkit if you included an HTML5-canvas equivalent, maybe something similar to wayland's protocol, for native apps only of course.
> I always fell a way back to a more text focused web should also have even more a focus on hypertext than the original web did.
This is something that struck me with Gemini.
What happens is that since there are no inline links, you are basically penalized for adding links because you have to disrupt your prose with a stack of links, each on their own line, before resuming your content.
It focused so much on the text-only part of the early web that it forgot about the part where people linked to each other heavily. It's like it imagines the ideal web as just a bunch of online books rather than interconnected documents.
> What happens is that since there are no inline links, you are basically penalized for adding links because you have to disrupt your prose with a stack of links, each on their own line, before resuming your content.
I find it far less disruptive for actually reading a text, in which you want to follow references after you've read the text. If you do that while you read the text, you're no longer actually reading the text.
> I think common mark is really the worst form of markdown
How so?
> And tables are optional? That does not sound great for many Text documents to be honest. I would rather argue, forcing browsers to not only implement tables but sortable and filterable tables would give such a standard an immediate leg up over the existing web and browsers and is absolutely something people working with text documents would gain benefit from.
There are two issues with tables: One, they are not in the CommonMark spec and as such many parsers will not support them out-of-the-box, and two, the syntax as implemented in GitHub-flavored Markdown (which is what is commonly understood as a "Markdown table") is incredibly complex compared to any other standard or not-standard-but-common Markdown feature. Thus, I would not expect very resource-limited systems to be able to support them.
That said, I'd expect that any KyuWeb browsers that reach widespread use on modern every-day systems would support tables, so unless you're interested in browsing KyuWeb on old IBM PC systems or the like, the issue is largely moot.
Not really. The main thing PDF gets you is pixel-perfect reproduction of paper, printable documents. Authors of those “document-oriented Web” proposals use the word “document” when they really mean “painfully lightweight text files”. At the same time, those text files (whether plain, Gemini/gemtext, or Markdown), can still be freely reflowed, they can adjust to your screen size and preferred font size — you can’t do that with PDF, which has a set and constant page width/height and which specifies every character’s size and position on that page.
I suppose perhaps it would be interesting to have a format that takes a PDF and then lets a designer overlay the main area of content to zoom into. But perhaps that's HTML+CSS :)
It’s not actually pixel-perfect, because the format is resolution-independent, and different PDF renderers differ slightly at the pixel level. I get what you mean, but “pixel-perfect” isn’t the right word.
PDF is an awfully complex format with all kinds of added bells and whistles and dynamic features, a low level of strict adherence to its spec by existing documents, and fun facts like the character encoding of textual content depending on the font used. It’s a world of pain on its own, not much better than the web, except for being less of a moving target.
I don't want to pile on the author, but I agree here. It is worthwhile to explore new ideas and I think I understand what the author was going for, but JS is probably a bad start to propose something like that.
That said, it feels like my post was a little cheap, because I don't have a good enough alternative ( and it is unlikely people would want to go back to 90s net ).
a browser extension could help with that (but if the protocol starts hurting revenue for the browsers, the plugins might be banned from the extension marketplace)
Why couldn't this be implemented as an extension in an existing browser?
Sending and detecting a different content type (e.g. text/kyu) that triggers (for now) a JS parser that renders the markup used into the HTML that the browser understands
This feels like the best way to get some adoption without having to build a whole new browser
Edit: it also means you could flex away from Markdown and develop your own markup language and parser as and when the need arises
I haven't done any browser extension development. Is it possible for browser extensions to be able to read HTTP headers? Is that consistent across all browsers?
After re-reading the document three times, it is still not clear to me
- what ports this protocol uses
- a simple example of communication
- the reason of the technical choices (commonmark!?)
- the reason why one should use this protocol
also gemini has some flaws but they are debatable and have their deep reason why they are there, in this "kyuweb" here we have a scattered collection of thoughts about "how it would be nice if" without head nor tail nor a reason why
so, at the moment more than a proposal it seems to me an exercise in style or whishful tinking, but if someone has some other insights I read it very gladly!
> - the reason of the technical choices (commonmark!?)
Three reasons: It's pleasant to write; it's readable even when partially or completely "unrendered;" and it's limited in its capabilities while still meeting the goal of being able to present documents.
As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it.
well, commomark was just an example of the technical choices not explained, but for the sake of discussion let's focus on this single one:
actually commonmark has enough problems (already pointed out by others - see [1] and indirectly the flourishing of sub versions) and in good substance is unambiguous, it seems to me that they are not known by the author given the choice
> It's pleasant to write; it's readable even when[...]
very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms!
> As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it.
(beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier), in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple? in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags? and on the other side do i have to have custom classic web servers that also respond in this subformat? and if the server sends me mixed content? what should the browser do?
but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers?
if these remarks seem stupid, I still repeat that they are all addressed on gemini (even though the answers may not please everyone)
> actually commonmark has enough problems (already pointed out by others - see [1] and indirectly the flourishing of sub versions) and in good substance is unambiguous, it seems to me that they are not known by the author given the choice
Not entirely sure what you're intending here. The document you link to shows flaws in Gruber's OG Markdown specification as examples of what CommonMark intends to fix and are therefore examples of why I say KyuWeb documents are written in CommonMark instead of Markdown.
> very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms!
CommonMark is a markup specification, just like HTML. Heck, in most of its implementations, it "compiles to" HTML. Styling would be up to the browser.
> (beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier),
My apologies if I came off insulting. It was not my intention. I just merely intended to indicate that KyuWeb networking is basically just HTTP, so any questions about "Does/How does KyuWeb implement X?" with regards to networking can be answered by referring to the HTTP specification.
> in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple?
I don't think "layer" is the right word, but you can look at it that way if you wish. In reality it's just a handful of additional HTTP headers, and rules for using existing headers, allowing clients and servers to communicate with each other about KyuWeb-specific things.
> in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags?
No. A proper KyuWeb browser could use the same HTTP networking code as a "normal" browser but wouldn't have HTML, JS, or CSS parsers/VMs/renderers (at least not necessarily - I suppose a hybrid KyuWeb and normal web browser would be possible).
> and on the other side do i have to have custom classic web servers that also respond in this subformat?
Yes. Existing web servers can serve as KyuWeb servers. The server I'm currently building is simply a PHP app which would integrate with Nginx/Apache/what-have-you with FastCGI, just like Drupal or WordPress or Magento (but in practice much simpler than any of those).
> but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers?
Because normal web browsers don't render Markdown, and, to a lesser extent, because old resource-limited computers can't run normal web browsers.
Lots of haters here so I'll say it: THANK YOU. This is an option a lot of us wanted, and who don't like Gemini's philosophy. I will for sure support this via my participation.
I do think the name has to change for wider adoption as KyuWeb sounds too much like it's some isolated stand-alone community. Could be fun to call it like "1.1Web" (One point one) as a reference to HTTP1.1 (and is a discoverable name) and goes against the whole "Web<number>" scheme as well to indicate it's not a regression.
I'm fond of KyuWeb but not quite stuck on it if something better struck me. I don't think anything that looks like version numbers would be it, though.
What would we call the second iteration of One Point One Web (should there be one)? One Point One Web Two Point Oh?
If a goal of the project is to restrict the network to "book- or paper-like documents", then Markdown is woefully inadequate to represent the richness of the kinds of real-life paper layouts that people have been making over the ages. I say this after spending years creating ebooks for Standard Ebooks and trying to create HTML-based epubs that emulate the print layout of real print books.
I would go so far as to say that until very recently, until the dawn of CSS Flexbox and Grid, it was still impossible to emulate even a medium-complexity paper page layout in HTML/CSS, and HTML/CSS is far richer than Markdown. (For example, vertically and horizontally centering a short dedication in a viewport - basically requires Flexbox but done even better with Grid.)
HTML/CSS is very, very well suited to paper-like documents. In fact I'd say the document-based roots of HTML (<section>, <p>, <blockquote>, <i>...) combined with the richness of modern CSS makes HTML/CSS one of the best combos we've ever had for emulating paper. What the author probably really wants is just the regular web but without Javascript or multimedia tags like <video> or <canvas>. (But what about <img>? Books have been illustrated for centuries...)
My primary intention with KyuWeb is documents for screens, and creating documents with all the layout flexibility available in modern HTML/CSS is not a goal.
Hello. I'm the author of this document. It looks like someone posted this to HN without my knowledge after a discussion on IRC yesterday. I was intending to post it myself, but probably not until I had some working software for it - I've been hacking away at a server in my free time but hadn't gotten very far yet. I expect that the process of writing actually functioning software using these ideas will cause the ideas themselves to adapt to the realities of implementing software for them.
All that said, I appreciate the premature feedback. :)
Given that, I might re-evaluate stopping at 1.1 in the future. But let's keep it there for now.
Why do we not want to force encryption? Because modern encryption algorithms can be dog slow on old 16-bit systems and effectively impossible on 8-bit ones.
But for clients and servers that support it, SSL/TLS encryption will work the same way as it does for HTTP.
> This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?
Because that header is supposed to specify a content type(s). If I were creating a new content type as part of this, I might use it, but the idea is that KyuWeb documents are just Markdown documents, nothing more. Thus `text/markdown` a more correct value for the `Accept` header.
A honest reminder: we already have a document-oriented web, it's name is "web". html+css distributed via http, are actually that.
Recently there is a certain push toward a comeback to such classic model with personal static websites vaguely used as blogs.
The main issue is not much an alternative to such well-established and well-known model but the actual web evolution, the sole way to fight it it's NOT following the same model "correcting the aim" but proposing a different model. Classic desktops and Plan 9 propose a different model that IMVHO we desperately need today.
So why propose "another web"? Any platform have two initial big issues: users and contents. The classic web is already accessible by anyone, just using and advertising it well suffice, put a very well visible feed icon on any personal website, dedicating a page to explain how to use a feed reader and proposing an opml with a set of interesting feeds [1] telling why feeds are personal aggregators and while far underdeveloped they can still work very well as they are and with more popularity they might get new features like a personal recommendation engine, tweakable by it's user, not by some corporate propaganda interests. Offering a newsletter option, full article in the mail, text or html without remote contents or even option for pdf-atteched articles beautifully made by LaTeX from some source, like org-mode export complete the game. The consumers barrier is essentially zero. The producer barrier is still significant since it demand some monetary investments, but since having a personal home-server is something more and more popular and in many place of the world domestic connections start to have a decent enough upload it's not that hard to offer nice pre-cooked distros (some already exists since many years) NOT full of crappy corporate-pushed tech like docker/k*s/proxmox-on-raspberry and other absurdity fairly common today + advertising a bit things like ZeroNet (not that good, but perform well enough and it's just an easy to deploy python package) might be of help. The rest arrive is that get a bit of traction.
Next step: talking place. Usenet is widespread even if almost faded into oblivion, it's not that hard to revive it, some have already done that for piracy/commercial purposes with dedicated binary groups to spread music, TV series etc to a point that for a certain slice of the public usenet today is a substitute for bittorrent yesterday. File sharing? Retroshare is a good example and the success of PopcornTime clearly say that's possible IF there is a community behind with good intentions (so for instance not focused on piracy from day zero). Again the rest might follow, trying to push absurd social like fediverse is instead a recipe to a disaster.
We have desktops, not much datacenters, a solution for us the people is desktop based, not modern web/cloud copy...
[1] if a visitor find a website interested probably some/many other feeds followed by the website author will be interesting for the visitor as well.
First, congratulations to the KyuWeb team on making something and getting it to launch. Anytime you do that it is a win, because it is a big learning experience and a good confidence booster.
Second, I have some concerns with the design. CommonMark is not what I would have chosen. WikiCreole is the result of a standardization effort to create a Wiki markup standard, and what I would have picked. Also, there are conflicting pieces. For example, the MIME types accepted are text/plain and text/markdown, but then they talk about HTML wrapped Kyu documents and using pre to do so (better options are available; even script would be better I think). There's also an ambiguous statement about other types being displayable with helper applications.
However, more importantly, this seems to be trying to fill a space that doesn't exist. Plain text with little or no styling has Gopher/Veronica/Wais and now Gemini. I'm not familiar with Gemini but used Gopher back in the day a lot.
Text with styling exists in HTML. Yes, it has a lot of feature creep. Yes, there are pages that are just CSS and Javascript, with little HTML. However, it is the standard.
KyuWeb document reads to me like they want HTML without plugins or Javsscript. That's a legitimate want, and I think a good approach to getting it is to create a prototype of how you can specify an HTML profile that meets that need, then work within the W3C or WHATWG to see about getting that recognized.
What I think they really would be happy with is HyperCard. I have to wonder how the Internet would be different if Hypercard had taken off the way the Web did, instead of being replaced by it. Robert Cailliau from the Hypercard Team helped Tim Berners-Lee create the first Web browser [1].
[1] Cailliau, Robert, How It Really Happened, Computer, archived from the original on January 6, 2011 (on the WWW proposal).
> First, congratulations to the KyuWeb team on making something and getting it to launch.
No team, just me, and I don't consider this to have "launched" yet. A true launch will involve at least one working server and one working client people can use to browse it. But thank you regardless.
> Text with styling exists in HTML. Yes, it has a lot of feature creep. Yes, there are pages that are just CSS and Javascript, with little HTML. However, it is the standard.
I agree - which is why KyuWeb is about defining a way to use existing standards to meet the goal of a document-focused web rather than defining a new standard. That might seem like a distinction without a difference for some, but I think the difference will come in the software - a KyuWeb server is just an HTTP server with some slightly different behavior, and a KyuWeb client will use HTTP client libraries for communicating with it.
> What I think they really would be happy with is HyperCard.
HyperCard is not document-focused and not an open standard. That said I was a huge fan of Myst back in the day. :)
I really like this balkinization of the web that is happening. I think the web has become too centralized. Having different programs, protocols and standards will lead to a rethinking of everything. Computers have become Chrome machines in the last 15 years. I want variety, humanity, and disjoint choices.
I've loved Gemini so far, and see a lot of value in the limitations placed on it.
I think adding the ability to access KyuWeb from the normal web is actually the wrong move. I think we need to make these things completely distinct and let the winner come out naturally.
Also, I think leveraging existing technologies is a mistake. HTTP is a massive undertaking to implement. The idea of being able to write your own browser is a huge step forward as it prevents situations where everyone depends on one implementation like WebKit.
Unfortunately for Gemini, everyone still depends on canonical encryption implementations - openssl. I wish someone could create a sort of "reference implementation" in psuedo-code of TLS that is easy to understand and hard to mess up.
I can't find any mention of encryption - will this be more like Gopher in that it lacks encryption? Or is it optional?
> I think adding the ability to access KyuWeb from the normal web is actually the wrong move. I think we need to make these things completely distinct and let the winner come out naturally.
I think that forcing people to download and use a different software program will be a roadblock to letting people try KyuWeb. For better or worse (well, for worse, mostly), a web browser is the tool people use to do internet-related things. Every person that clicks a link and sees a KyuWeb document right in their browser is one person more using KyuWeb than there otherwise would have been. That said, I expect a mature KyuWeb browser to provide a better experience than a normal web browser if for no other reason than it should be much faster.
> Also, I think leveraging existing technologies is a mistake. HTTP is a massive undertaking to implement. The idea of being able to write your own browser is a huge step forward as it prevents situations where everyone depends on one implementation like WebKit.
I agree when it comes to the web, but for KyuWeb, strict standardization is a feature, not a bug. That said, the relative simplicity of implementing a usable Markdown parser and renderer versus a modern HTML + CSS + JS parser and renderer should result in relative explosion of client implementations (a relative explosion).
> I can't find any mention of encryption - will this be more like Gopher in that it lacks encryption? Or is it optional?
Does HTTP/1.1 support encryption? Is encryption optional in HTTP/1.1? There are your answers.
What we need instead is a DATA-oriented web. The web already largely consists of interlinked databases (anything from Amazon to AirBnB is really just a database exploration tool). Even WordPress blogs are really just databases (with TEXT columns).
The current web is highly unstructured and poses a challenge for automation and the AGI future. I'd prefer to see a web where this data is exposed directly for client consumption (via something like JSON/REST) and a universal data browser that allows consumers to query and navigate any remote dataset with ease (Norton Commander style).
I agree that this is needed, and there have been various attempts to implement this sort of thing (including from Berners-Lee himself). But that's not the problem this project is trying to solve.
Ok. We've got the extreme-minimalist web alternative in Gemini, and the alternative that uses Markdown in KyuWeb. Now we just need the version that exclusively uses s-expressions for markup to complete the triforce.
How about a system where documents are formed by using regular expressions to extract desired words and passages from a corpus such as the works of Shakespeare?
I am thinking that this is kind of the wrong way of doing such things like this (although HTTP as a protocol is OK for this kind of things; there are things that HTTP is bad for, but this isn't one of them).
Accept-Length and Title seem like they can be reasonable (and can be potentially used for any file, even implementations that do not otherwise support KyuWeb might or might not still implement them).
I think it should be better for Markdown responses to specify the variant of Markdown being used if available, as a MIME type parameter; e.g. CommonMark uses "text/markdown;variant=CommonMark". (This would potentially improve compatibility among non-KyuWeb clients, I guess.) (Although, I think there are many problems with Markdown, and that is also true of HTML.)
I think that the way of finding wrapped Markdown files using HTML comments isn't very good. My proposed ways are:
* Using <link rel="alternate">, which is standard and is compatible with common web browsers.
* My proposal of new HTML attributes "application", "feature", and "wraptype", which is not standard but it is compatible with common web browsers. (I do have some files using some of these features, though.)
* My proposal of a new HTTP response header "Interpreter", which is not standard and is not compatible with existing web browsers. I would want to make known my ideas and propose that hopefully can be standardized and implemented, since it would be much cleaner than the existing mess. (Although if you are worry about older browsers, then there is consideration such as needing to add something such as a "Accept-Headers" request header, which the server is allowed to ignore if it always gives "Interpreter" responses anyways or if it does not have any.)
I love projects like this because the web is currently so complex that only hypercorps can/will pay the cost of maintaining and evolving the engines.
That said, while reading the project description I became distracted by the idea of going in the exact opposite direction of simplification: drop every declarative (HTML, CSS) and make only the lower level JS and WASM APIs available. So, everything is rendered on canvas or WebXR sessions, all media playback is with WebAudio and WebRTC, and all input is via input events (KB/M/Touch), gamepad API, and WebXR Inputs.
I'm pretty sure this is a bad idea and yet it also feels like a lot of fun.
75 comments
[ 2.5 ms ] story [ 108 ms ] threadFor one thing, I think common mark is really the worst form of markdown and especially considering the whole angle of hacker culture and DIY these kind of projects clearly aim at, I am always baffled that something more feature rich and easy to interoperate with like pandoc flavored markdown is not chosen.
And tables are optional? That does not sound great for many Text documents to be honest. I would rather argue, forcing browsers to not only implement tables but sortable and filterable tables would give such a standard an immediate leg up over the existing web and browsers and is absolutely something people working with text documents would gain benefit from.
But to this point, I always fell a way back to a more text focused web should also have even more a focus on hypertext than the original web did. The real value besides having it run in simpler browsers would be to offer features that were never realized on the web but could revolutionize how we work with text. I like to see more inspired be Engelbart or Nelson and really bring forward a new, more useful sort of web. Of course, that adds complexity and that has to be careful managed, but besides the community around it, gemini, and looking at it also this, are mostly not more featured than swapping text files over ftp, and I feel this is really a shame.
But it also depends on what the goals of this new system are. Are we trying to make a simpler, faster, read-only web?
If we're going that way, I'd love to limit CSS to a minimal subset (or maybe nothing?), minimise support for embedded content types, remove input elements, and remove stuff like cookies.
There is probably value in a project that aims to create a more intentionally designed and capable version of the web with standard rich interactive widgets, etc, but those would need to be separate projects with their own approach to keeping scope sane.
It seems that some people look at the designs from the past and think "oh, whatever the designer came up with was the true final form of the idea" when in reality it was just that what they came up with was to deal with the constraints they were dealing with (costs, time, resource, etc).
I don't think at any point in time TBL's just went on to say "oh, HTTP and HTML are set in stone and no more use-cases are going to be added or promoted". The protocol was not designed to satisfy some subjective notion of "incredibly simple", it was made to satisfy the possible use-cases within the constraints of the time.
Which leads me to ask you: why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
Okay, my mistake. I do think simplicity was a goal for Sir Tim, though. Check out this old Usenet post introducing the "WorldWideWeb" (emphasis mine): https://groups.google.com/g/comp.archives/c/CfsHlSNYPUI/m/DT...
> A simple protocol ("HTTP") is used to allow a browser program to request a keyword search by a remote information server.…
> Making a web is as simple as writing a few SGML files which point to your existing data.…
--
> Which leads me to ask you: why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
I think the phrase "should be" bothers me here. I just had an idea and I'm gonna try to implement it. Most likely I will be the only person to do so, but if someone else thinks it's a good idea, they can implement it too if they wish, and that would be cool. I'm sure many people who are interested in KyuWeb's goals will read my proposal and my arguments in this thread and still decide that Gopher, Gemini, or the modern web is still the better route to take, and that's fine.
Saying that your design allows people to do things in a "simple" way is not the same as saying that the protocol is meant to be deploy only in the limited use-cases.
> I just had an idea and I'm gonna try to implement it.
You are (implicitly) asking people to conform to your design, though. Or would you continue working on it even if you were the sole user?
When you put it that way… certainly these sorts of projects are more rewarding and validating if other people find them as useful as I do, yes. I'd consider it a success beyond all expectation if KyuWeb saw even the modest usage numbers of Gemini, but even a fraction of that would be very motivating. So let me try again at answering your question.
> why do you think that you believe that other people should be limiting themselves to what basically amounts to your idea of "incredibly simple"?
Because I think there is a hole in the "market" for a system of interlinked hypertext documents which is just that and nothing more, and I think KyuWeb is a way to fill that hole in a manner that balances usefulness and ease of implementation better than the alternatives.
But yes, others are free to disagree or offer their own solutions. :)
Ok, so what? Why is it so important for you that the system does "just that and nothing more"?
- There is nothing stopping you in the existing web to create the documents according to whatever limitations that you would like to have.
- There is nothing stopping you to filter/transform whatever documents you receive from outside to fit your liking.
- If "resource usage" is a problem for you, go ahead and browse the web using lynx. Bonus points, you'd still be able to browse the existing "document-oriented" web without forcing other people to conform to your limitations of KyuWeb.
- Even micro-controllers that cost pennies on the dollar have enough resources to run a basic http client. Your proposal does not make anything more accessible/affordable.
Don't take it personally, but this is the type of project that I really wish never gets any traction. This type of ascetic mentality seems to be rooted in good intentions but always carries some totalitarian undertone that bothers me.
It's okay to be a minimalist by filtering out things on your side, but it's actually harmful when this minimalism becomes a forced doctrine. I'm all for trying to have tools that filter the complexity of the existing web, but I do not want to cripple it because some of its usages affect my sensibilities.
Using an alternative protocol is completely optional for you as a user so I don't think calling it a forced doctrine is accurate. These kinds of protocols are great for people who want to have an experience of browsing a web of documents knowing that they won't be giving up privacy or be bombarded with interactive attention grabbing graphical elements, advertisements, videos etc. If that experience is not something you value, you can obviously choose not to use it.
> I'm all for trying to have tools that filter the complexity of the existing web, but I do not want to cripple it because some of its usages affect my sensibilities.
Filtering the modern web is not easy. Just try browsing with JavaScript disabled and count the number of annoyances you encounter in a day.
[1]: https://gemini.circumlunar.space/docs/faq.gmi#:~:text=Why%20...
Sure, if they provide some kind of gateway or mirror. But the moment that their content is only on a gemini server, I have to use a gemini client.
> These kinds of protocols are great for people who want to have an experience of browsing a web of documents knowing that they won't be giving up privacy or be bombarded with interactive attention grabbing graphical elements, advertisements, videos etc.
That is utter, complete bullshit. You don't need a new protocol for that. You just need a client that is a better fit for your needs and that can filter things for you.
> Just try browsing with JavaScript disabled and count the number of annoyances you encounter in a day.
On the flip side, think of all the websites and services in the existing web that use the technology in a sensible way and made your life better. This very website we are talking on would not exist.
By staying on the web and developing tools that improve the clients, we are trimming the downside and keeping the upside. By creating a new protocol you are negating all the upside and denying the existence of the downside it. IOW, you are just shutting yourself out like an ascetic monk. To me is an act of cowardice dressed as something virtuous.
I will keep making sites on the normal web, both for myself and my clients. Hopefully one of those will strike your fancy. But if not, that's okay too.
Or something even better than MD, like reStructuredText.
* HTMX build in, gives 99% of modern page interactivity with no javascript
* No javascript.
* Yes images and videos, no custom video controls.
* Simplified CSS, all layout done via flexbox? The goal is to be able to not use HTML as part of your layout, but instead have HTML model your data as closely as possible. Looking at how simplified the HTML is for modern bootstrap compared to previous generations I think this is possible.
* Simplified HTML. There are a lot of older tags that probably shouldn't get used.
Everyone has their own set of killer features though, so it's a hard problem to coordinate on.
I think something very much like that could be really powerful as a native GUI toolkit if you included an HTML5-canvas equivalent, maybe something similar to wayland's protocol, for native apps only of course.
This is something that struck me with Gemini.
What happens is that since there are no inline links, you are basically penalized for adding links because you have to disrupt your prose with a stack of links, each on their own line, before resuming your content.
It focused so much on the text-only part of the early web that it forgot about the part where people linked to each other heavily. It's like it imagines the ideal web as just a bunch of online books rather than interconnected documents.
Just use footnotes.[0][1]
[0] Like this
[1] Or this[1a]
[1a] Or even this.
How so?
> And tables are optional? That does not sound great for many Text documents to be honest. I would rather argue, forcing browsers to not only implement tables but sortable and filterable tables would give such a standard an immediate leg up over the existing web and browsers and is absolutely something people working with text documents would gain benefit from.
There are two issues with tables: One, they are not in the CommonMark spec and as such many parsers will not support them out-of-the-box, and two, the syntax as implemented in GitHub-flavored Markdown (which is what is commonly understood as a "Markdown table") is incredibly complex compared to any other standard or not-standard-but-common Markdown feature. Thus, I would not expect very resource-limited systems to be able to support them.
That said, I'd expect that any KyuWeb browsers that reach widespread use on modern every-day systems would support tables, so unless you're interested in browsing KyuWeb on old IBM PC systems or the like, the issue is largely moot.
I suppose perhaps it would be interesting to have a format that takes a PDF and then lets a designer overlay the main area of content to zoom into. But perhaps that's HTML+CSS :)
It’s not actually pixel-perfect, because the format is resolution-independent, and different PDF renderers differ slightly at the pixel level. I get what you mean, but “pixel-perfect” isn’t the right word.
That said, it feels like my post was a little cheap, because I don't have a good enough alternative ( and it is unlikely people would want to go back to 90s net ).
Also, as I asked in another thread: Do extensions have access to HTTP headers?
Sending and detecting a different content type (e.g. text/kyu) that triggers (for now) a JS parser that renders the markup used into the HTML that the browser understands
This feels like the best way to get some adoption without having to build a whole new browser
Edit: it also means you could flex away from Markdown and develop your own markup language and parser as and when the need arises
The Web Extensions standard is coming along quite nicely (at least from my perspective)
But even just targeting a single browser engine to start with feels appropriate just to get the concept out there and see how it flies
https://chrome.google.com/webstore/detail/markdown-viewer/ck... https://chrome.google.com/webstore/detail/markdown-preview-p...
- what ports this protocol uses
- a simple example of communication
- the reason of the technical choices (commonmark!?)
- the reason why one should use this protocol
also gemini has some flaws but they are debatable and have their deep reason why they are there, in this "kyuweb" here we have a scattered collection of thoughts about "how it would be nice if" without head nor tail nor a reason why
so, at the moment more than a proposal it seems to me an exercise in style or whishful tinking, but if someone has some other insights I read it very gladly!
I don’t think anyone needs an example of http communication.
I feel like the choice of commonmark is mostly a ‘I really don’t like gemini markup’ reaction.
As to why you should use it? Why not?
Three reasons: It's pleasant to write; it's readable even when partially or completely "unrendered;" and it's limited in its capabilities while still meeting the goal of being able to present documents.
As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it.
actually commonmark has enough problems (already pointed out by others - see [1] and indirectly the flourishing of sub versions) and in good substance is unambiguous, it seems to me that they are not known by the author given the choice
> It's pleasant to write; it's readable even when[...]
very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms!
> As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it.
(beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier), in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple? in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags? and on the other side do i have to have custom classic web servers that also respond in this subformat? and if the server sends me mixed content? what should the browser do?
but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers?
if these remarks seem stupid, I still repeat that they are all addressed on gemini (even though the answers may not please everyone)
[1] https://github.github.com/gfm/#why-is-a-spec-needed-
Not entirely sure what you're intending here. The document you link to shows flaws in Gruber's OG Markdown specification as examples of what CommonMark intends to fix and are therefore examples of why I say KyuWeb documents are written in CommonMark instead of Markdown.
> very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms!
CommonMark is a markup specification, just like HTML. Heck, in most of its implementations, it "compiles to" HTML. Styling would be up to the browser.
> (beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier),
My apologies if I came off insulting. It was not my intention. I just merely intended to indicate that KyuWeb networking is basically just HTTP, so any questions about "Does/How does KyuWeb implement X?" with regards to networking can be answered by referring to the HTTP specification.
> in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple?
I don't think "layer" is the right word, but you can look at it that way if you wish. In reality it's just a handful of additional HTTP headers, and rules for using existing headers, allowing clients and servers to communicate with each other about KyuWeb-specific things.
> in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags?
No. A proper KyuWeb browser could use the same HTTP networking code as a "normal" browser but wouldn't have HTML, JS, or CSS parsers/VMs/renderers (at least not necessarily - I suppose a hybrid KyuWeb and normal web browser would be possible).
> and on the other side do i have to have custom classic web servers that also respond in this subformat?
Yes. Existing web servers can serve as KyuWeb servers. The server I'm currently building is simply a PHP app which would integrate with Nginx/Apache/what-have-you with FastCGI, just like Drupal or WordPress or Magento (but in practice much simpler than any of those).
> but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers?
Because normal web browsers don't render Markdown, and, to a lesser extent, because old resource-limited computers can't run normal web browsers.
I do think the name has to change for wider adoption as KyuWeb sounds too much like it's some isolated stand-alone community. Could be fun to call it like "1.1Web" (One point one) as a reference to HTTP1.1 (and is a discoverable name) and goes against the whole "Web<number>" scheme as well to indicate it's not a regression.
It's a subtle hat-tip
What would we call the second iteration of One Point One Web (should there be one)? One Point One Web Two Point Oh?
I would go so far as to say that until very recently, until the dawn of CSS Flexbox and Grid, it was still impossible to emulate even a medium-complexity paper page layout in HTML/CSS, and HTML/CSS is far richer than Markdown. (For example, vertically and horizontally centering a short dedication in a viewport - basically requires Flexbox but done even better with Grid.)
HTML/CSS is very, very well suited to paper-like documents. In fact I'd say the document-based roots of HTML (<section>, <p>, <blockquote>, <i>...) combined with the richness of modern CSS makes HTML/CSS one of the best combos we've ever had for emulating paper. What the author probably really wants is just the regular web but without Javascript or multimedia tags like <video> or <canvas>. (But what about <img>? Books have been illustrated for centuries...)
My primary intention with KyuWeb is documents for screens, and creating documents with all the layout flexibility available in modern HTML/CSS is not a goal.
All that said, I appreciate the premature feedback. :)
- This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?
Because HTTP/2 requires encryption. … Or so I thought. As I was double-checking my answer, I found that it looks like that is actually no longer the case: https://http2.github.io/faq/#does-http2-require-encryption
Given that, I might re-evaluate stopping at 1.1 in the future. But let's keep it there for now.
Why do we not want to force encryption? Because modern encryption algorithms can be dog slow on old 16-bit systems and effectively impossible on 8-bit ones.
But for clients and servers that support it, SSL/TLS encryption will work the same way as it does for HTTP.
> This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?
Because that header is supposed to specify a content type(s). If I were creating a new content type as part of this, I might use it, but the idea is that KyuWeb documents are just Markdown documents, nothing more. Thus `text/markdown` a more correct value for the `Accept` header.
Recently there is a certain push toward a comeback to such classic model with personal static websites vaguely used as blogs.
The main issue is not much an alternative to such well-established and well-known model but the actual web evolution, the sole way to fight it it's NOT following the same model "correcting the aim" but proposing a different model. Classic desktops and Plan 9 propose a different model that IMVHO we desperately need today.
So why propose "another web"? Any platform have two initial big issues: users and contents. The classic web is already accessible by anyone, just using and advertising it well suffice, put a very well visible feed icon on any personal website, dedicating a page to explain how to use a feed reader and proposing an opml with a set of interesting feeds [1] telling why feeds are personal aggregators and while far underdeveloped they can still work very well as they are and with more popularity they might get new features like a personal recommendation engine, tweakable by it's user, not by some corporate propaganda interests. Offering a newsletter option, full article in the mail, text or html without remote contents or even option for pdf-atteched articles beautifully made by LaTeX from some source, like org-mode export complete the game. The consumers barrier is essentially zero. The producer barrier is still significant since it demand some monetary investments, but since having a personal home-server is something more and more popular and in many place of the world domestic connections start to have a decent enough upload it's not that hard to offer nice pre-cooked distros (some already exists since many years) NOT full of crappy corporate-pushed tech like docker/k*s/proxmox-on-raspberry and other absurdity fairly common today + advertising a bit things like ZeroNet (not that good, but perform well enough and it's just an easy to deploy python package) might be of help. The rest arrive is that get a bit of traction.
Next step: talking place. Usenet is widespread even if almost faded into oblivion, it's not that hard to revive it, some have already done that for piracy/commercial purposes with dedicated binary groups to spread music, TV series etc to a point that for a certain slice of the public usenet today is a substitute for bittorrent yesterday. File sharing? Retroshare is a good example and the success of PopcornTime clearly say that's possible IF there is a community behind with good intentions (so for instance not focused on piracy from day zero). Again the rest might follow, trying to push absurd social like fediverse is instead a recipe to a disaster.
We have desktops, not much datacenters, a solution for us the people is desktop based, not modern web/cloud copy...
[1] if a visitor find a website interested probably some/many other feeds followed by the website author will be interesting for the visitor as well.
Second, I have some concerns with the design. CommonMark is not what I would have chosen. WikiCreole is the result of a standardization effort to create a Wiki markup standard, and what I would have picked. Also, there are conflicting pieces. For example, the MIME types accepted are text/plain and text/markdown, but then they talk about HTML wrapped Kyu documents and using pre to do so (better options are available; even script would be better I think). There's also an ambiguous statement about other types being displayable with helper applications.
However, more importantly, this seems to be trying to fill a space that doesn't exist. Plain text with little or no styling has Gopher/Veronica/Wais and now Gemini. I'm not familiar with Gemini but used Gopher back in the day a lot.
Text with styling exists in HTML. Yes, it has a lot of feature creep. Yes, there are pages that are just CSS and Javascript, with little HTML. However, it is the standard.
KyuWeb document reads to me like they want HTML without plugins or Javsscript. That's a legitimate want, and I think a good approach to getting it is to create a prototype of how you can specify an HTML profile that meets that need, then work within the W3C or WHATWG to see about getting that recognized.
What I think they really would be happy with is HyperCard. I have to wonder how the Internet would be different if Hypercard had taken off the way the Web did, instead of being replaced by it. Robert Cailliau from the Hypercard Team helped Tim Berners-Lee create the first Web browser [1].
[1] Cailliau, Robert, How It Really Happened, Computer, archived from the original on January 6, 2011 (on the WWW proposal).
No team, just me, and I don't consider this to have "launched" yet. A true launch will involve at least one working server and one working client people can use to browse it. But thank you regardless.
> Text with styling exists in HTML. Yes, it has a lot of feature creep. Yes, there are pages that are just CSS and Javascript, with little HTML. However, it is the standard.
I agree - which is why KyuWeb is about defining a way to use existing standards to meet the goal of a document-focused web rather than defining a new standard. That might seem like a distinction without a difference for some, but I think the difference will come in the software - a KyuWeb server is just an HTTP server with some slightly different behavior, and a KyuWeb client will use HTTP client libraries for communicating with it.
> What I think they really would be happy with is HyperCard.
HyperCard is not document-focused and not an open standard. That said I was a huge fan of Myst back in the day. :)
I've loved Gemini so far, and see a lot of value in the limitations placed on it.
I think adding the ability to access KyuWeb from the normal web is actually the wrong move. I think we need to make these things completely distinct and let the winner come out naturally.
Also, I think leveraging existing technologies is a mistake. HTTP is a massive undertaking to implement. The idea of being able to write your own browser is a huge step forward as it prevents situations where everyone depends on one implementation like WebKit.
Unfortunately for Gemini, everyone still depends on canonical encryption implementations - openssl. I wish someone could create a sort of "reference implementation" in psuedo-code of TLS that is easy to understand and hard to mess up.
I can't find any mention of encryption - will this be more like Gopher in that it lacks encryption? Or is it optional?
I think that forcing people to download and use a different software program will be a roadblock to letting people try KyuWeb. For better or worse (well, for worse, mostly), a web browser is the tool people use to do internet-related things. Every person that clicks a link and sees a KyuWeb document right in their browser is one person more using KyuWeb than there otherwise would have been. That said, I expect a mature KyuWeb browser to provide a better experience than a normal web browser if for no other reason than it should be much faster.
> Also, I think leveraging existing technologies is a mistake. HTTP is a massive undertaking to implement. The idea of being able to write your own browser is a huge step forward as it prevents situations where everyone depends on one implementation like WebKit.
I agree when it comes to the web, but for KyuWeb, strict standardization is a feature, not a bug. That said, the relative simplicity of implementing a usable Markdown parser and renderer versus a modern HTML + CSS + JS parser and renderer should result in relative explosion of client implementations (a relative explosion).
> I can't find any mention of encryption - will this be more like Gopher in that it lacks encryption? Or is it optional?
Does HTTP/1.1 support encryption? Is encryption optional in HTTP/1.1? There are your answers.
The current web is highly unstructured and poses a challenge for automation and the AGI future. I'd prefer to see a web where this data is exposed directly for client consumption (via something like JSON/REST) and a universal data browser that allows consumers to query and navigate any remote dataset with ease (Norton Commander style).
Accept-Length and Title seem like they can be reasonable (and can be potentially used for any file, even implementations that do not otherwise support KyuWeb might or might not still implement them).
I think it should be better for Markdown responses to specify the variant of Markdown being used if available, as a MIME type parameter; e.g. CommonMark uses "text/markdown;variant=CommonMark". (This would potentially improve compatibility among non-KyuWeb clients, I guess.) (Although, I think there are many problems with Markdown, and that is also true of HTML.)
I think that the way of finding wrapped Markdown files using HTML comments isn't very good. My proposed ways are:
* Using <link rel="alternate">, which is standard and is compatible with common web browsers.
* My proposal of new HTML attributes "application", "feature", and "wraptype", which is not standard but it is compatible with common web browsers. (I do have some files using some of these features, though.)
* My proposal of a new HTTP response header "Interpreter", which is not standard and is not compatible with existing web browsers. I would want to make known my ideas and propose that hopefully can be standardized and implemented, since it would be much cleaner than the existing mess. (Although if you are worry about older browsers, then there is consideration such as needing to add something such as a "Accept-Headers" request header, which the server is allowed to ignore if it always gives "Interpreter" responses anyways or if it does not have any.)
That said, while reading the project description I became distracted by the idea of going in the exact opposite direction of simplification: drop every declarative (HTML, CSS) and make only the lower level JS and WASM APIs available. So, everything is rendered on canvas or WebXR sessions, all media playback is with WebAudio and WebRTC, and all input is via input events (KB/M/Touch), gamepad API, and WebXR Inputs.
I'm pretty sure this is a bad idea and yet it also feels like a lot of fun.