42 ms·

KyuWeb: A proposal for a simple document-oriented web

76 points by modinfo 5y ago

Grumbledour 5y ago
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.
- tluyben2 5y ago
  Maybe web without any frontend dynamic? So without JS and the all the complex dynamic features of css?
  - gbanfalvi 5y ago
    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.
    - Induane 5y ago
      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.
- kitsunesoba 5y ago
  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.
  - rglullis 5y ago
    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).
    - Cyberdog 5y ago
      I am the author of the document. KyuWeb is intended to be incredibly simple.
      - rglullis 5y ago
        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"?
        Cyberdog 5y ago
        > I meant in relation to the "original web" creator. 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/DTs60INnuzcJ 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.
- Starlevel001 5y ago
  > 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.
  - brabel 5y ago
    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).
    - tetris11 5y ago
      Org-markdown?
      - Aeolun 5y ago
        How about we just stick with HTML?
        Cyberdog 5y ago
        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.
    - snek_case 5y ago
      Agreed, the RST syntax is truly awful. At least Markdown is easy to understand and work with.
- Induane 5y ago
  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.
  - traverseda 5y ago
    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.
  - knighthack 5y ago
    HTMX is such a killer library, especially with Django. I use it for almost everything now, and with a touch of Alpine JS.
- hombre_fatal 5y ago
  > 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.
  - zozbot234 5y ago
    > 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. Just use footnotes.[0][1] [0] Like this [1] Or this[1a] [1a] Or even this.
    - IgorPartola 5y ago
      So a PDF.
    - afavour 5y ago
      Which is objectively worse than an inline link.
      - marginalia_nu 5y ago
        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.
- Cyberdog 5y ago
  > 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.
  - IgorPartola 5y ago
    I think you answered your own questions as to why common mark is bad :)
    - Cyberdog 5y ago
      Did I? How so? Please be specific. Was it that it doesn't support tables?
    - davidjytang 5y ago
      Only because the spec lacks table?
robertlagrant 5y ago
I've wondered if you could you achieve (some of) this with PDF, just better integrated into the browser experience.
- Kwpolska 5y ago
  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.
  - robertlagrant 5y ago
    Yes, I thought that might be the objection :) 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 :)
  - layer8 5y ago
    > pixel-perfect reproduction 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.
- layer8 5y ago
  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.
hcarvalhoalves 5y ago
Here’s my proposal for a simple document-oriented web: just like it is, just don’t use JavaScript.
- A4ET8a8uTh0 5y ago
  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 ).
- layer8 5y ago
  The goal is to enable new clients to be written without requiring herculean efforts.
  - pgcj_poster 5y ago
    Use xhtml with no css.
- frozenlettuce 5y ago
  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)
  - Cyberdog 5y ago
    Browser extensions are written in JavaScript. :) Also, as I asked in another thread: Do extensions have access to HTTP headers?
simonhamp 5y ago
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
- Cyberdog 5y ago
  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?
  - simonhamp 5y ago
    Yes and yes. 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
- ejones 5y ago
  In fact it looks like there are already browser extensions that do this for Markdown: https://chrome.google.com/webstore/detail/markdown-viewer/ckkdlimhmcjmikdlpkmbgfkaikojcbjk?hl=en https://chrome.google.com/webstore/detail/markdown-viewer/ck... https://chrome.google.com/webstore/detail/markdown-preview-plus/febilkbfcbhebfnokafefeacimjdckgl?hl=en https://chrome.google.com/webstore/detail/markdown-preview-p...
__void 5y ago
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!
- Aeolun 5y ago
  If you use HTTP, I think the accepted idea is you use port 80. Or 443 if you want to communicate over https. 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?
- Cyberdog 5y ago
  > - 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.
  - __void 5y ago
    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) [1] https://github.github.com/gfm/#why-is-a-spec-needed- https://github.github.com/gfm/#why-is-a-spec-needed-
fallat 5y ago
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.
- simonhamp 5y ago
  I like One-Point-One! Perhaps 'opoweb' with a bit of creative license? It's a subtle hat-tip
- Cyberdog 5y ago
  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?
  - fallat 5y ago
    One-point-two Web.
    - a9h74j 5y ago
      Web 1/2.0 ?
acabal 5y ago
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...)
- Cyberdog 5y ago
  Markdown supports images. 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.
Cyberdog 5y ago
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. :)
- eoo 5y ago
  - Why is KyuWeb limited to HTTP/1.1? - 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`?
  - Cyberdog 5y ago
    > Why is KyuWeb limited to HTTP/1.1? 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 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.
kkfx 5y ago
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.
Communitivity 5y ago
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).
- Cyberdog 5y ago
  > 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. :)
trh0awayman 5y ago
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?
- Cyberdog 5y ago
  > 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.
akrymski 5y ago
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).
- Cyberdog 5y ago
  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.
krapp 5y ago
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.
- Cyberdog 5y ago
  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?
aendruk 5y ago
I just wish existing browsers would render `Content-Type: text/markdown`.
zzo38computer 5y ago
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.)
TrevorFSmith 5y ago
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.

76 points by modinfo 5y ago

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.

tluyben2 5y ago
Maybe web without any frontend dynamic? So without JS and the all the complex dynamic features of css?
- gbanfalvi 5y ago
  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.
  - Induane 5y ago
    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.
kitsunesoba 5y ago
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.
- rglullis 5y ago
  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).
  - Cyberdog 5y ago
    I am the author of the document. KyuWeb is intended to be incredibly simple.
    - rglullis 5y ago
      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"?
      - Cyberdog 5y ago
        > I meant in relation to the "original web" creator. 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/DTs60INnuzcJ 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.
Starlevel001 5y ago
> 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.
- brabel 5y ago
  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).
  - tetris11 5y ago
    Org-markdown?
    - Aeolun 5y ago
      How about we just stick with HTML?
      - Cyberdog 5y ago
        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.
  - snek_case 5y ago
    Agreed, the RST syntax is truly awful. At least Markdown is easy to understand and work with.
Induane 5y ago
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.
- traverseda 5y ago
  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.
- knighthack 5y ago
  HTMX is such a killer library, especially with Django. I use it for almost everything now, and with a touch of Alpine JS.
hombre_fatal 5y ago
> 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.
- zozbot234 5y ago
  > 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. Just use footnotes.[0][1] [0] Like this [1] Or this[1a] [1a] Or even this.
  - IgorPartola 5y ago
    So a PDF.
  - afavour 5y ago
    Which is objectively worse than an inline link.
    - marginalia_nu 5y ago
      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.
Cyberdog 5y ago
> 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.
- IgorPartola 5y ago
  I think you answered your own questions as to why common mark is bad :)
  - Cyberdog 5y ago
    Did I? How so? Please be specific. Was it that it doesn't support tables?
  - davidjytang 5y ago
    Only because the spec lacks table?

robertlagrant 5y ago

I've wondered if you could you achieve (some of) this with PDF, just better integrated into the browser experience.

Kwpolska 5y ago
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.
- robertlagrant 5y ago
  Yes, I thought that might be the objection :) 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 :)
- layer8 5y ago
  > pixel-perfect reproduction 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.
layer8 5y ago
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.

hcarvalhoalves 5y ago

Here’s my proposal for a simple document-oriented web: just like it is, just don’t use JavaScript.

A4ET8a8uTh0 5y ago
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 ).
layer8 5y ago
The goal is to enable new clients to be written without requiring herculean efforts.
- pgcj_poster 5y ago
  Use xhtml with no css.
frozenlettuce 5y ago
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)
- Cyberdog 5y ago
  Browser extensions are written in JavaScript. :) Also, as I asked in another thread: Do extensions have access to HTTP headers?

simonhamp 5y ago

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

Cyberdog 5y ago
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?
- simonhamp 5y ago
  Yes and yes. 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
ejones 5y ago
In fact it looks like there are already browser extensions that do this for Markdown: https://chrome.google.com/webstore/detail/markdown-viewer/ckkdlimhmcjmikdlpkmbgfkaikojcbjk?hl=en https://chrome.google.com/webstore/detail/markdown-viewer/ck... https://chrome.google.com/webstore/detail/markdown-preview-plus/febilkbfcbhebfnokafefeacimjdckgl?hl=en https://chrome.google.com/webstore/detail/markdown-preview-p...

__void 5y ago

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!

Aeolun 5y ago
If you use HTTP, I think the accepted idea is you use port 80. Or 443 if you want to communicate over https. 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?
Cyberdog 5y ago
> - 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.
- __void 5y ago
  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) [1] https://github.github.com/gfm/#why-is-a-spec-needed- https://github.github.com/gfm/#why-is-a-spec-needed-

fallat 5y ago

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.

simonhamp 5y ago
I like One-Point-One! Perhaps 'opoweb' with a bit of creative license? It's a subtle hat-tip
Cyberdog 5y ago
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?
- fallat 5y ago
  One-point-two Web.
  - a9h74j 5y ago
    Web 1/2.0 ?

acabal 5y ago

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...)

Cyberdog 5y ago
Markdown supports images. 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.

Cyberdog 5y ago

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. :)

eoo 5y ago
- Why is KyuWeb limited to HTTP/1.1? - 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`?
- Cyberdog 5y ago
  > Why is KyuWeb limited to HTTP/1.1? 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 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.

kkfx 5y ago

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.

Communitivity 5y ago

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).

Cyberdog 5y ago
> 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. :)

trh0awayman 5y ago

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?

Cyberdog 5y ago
> 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.

akrymski 5y ago

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).

Cyberdog 5y ago
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.

krapp 5y ago

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.

Cyberdog 5y ago
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?

aendruk 5y ago

I just wish existing browsers would render `Content-Type: text/markdown`.

zzo38computer 5y ago

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.)

TrevorFSmith 5y ago

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.