Emacs saves the Web (maybe)

Yuchen Pei (he/him, pronounced: "eww-churn pay"), IRC: dragestil, id@ypei.org, https://ypei.org, mastodon: dragestil@hostux.social

Format: 32-min talk; Q&A: BigBlueButton conference room
Status: Q&A to be extracted from the room recordings

Talk

00:00.000 Overview
00:35.680 Background problems
05:31.940 Solutions outside of Emacs
09:46.480 Emacs solutions
09:54.600 Free clients in Emacs
12:43.021 Web browsers in Emacs
16:52.380 emacs-web-server - overview
17:30.380 emacs-web-server - hello emacs!
18:17.580 emacs-web-server - yolo
23:07.940 emacs-web-server - emacs web framework
29:40.420 Firefox with emacs for extensions
31:25.360 Thank you

Q&A

Description

On one hand, Emacs is the crown jewel of the GNU Project for its customisability and the ability to effortlessly convert users to hackers. On the other hand, today many of the sticky issues with proprietary software proliferation stems from the web, including the Javascript trap[1] on the client side and the SaaSS trap[2] on the server side. So enters the topic of this talk. I will briefly talk about these issues and existing non-emacs solutions, followed by ideas and demonstrations on how Emacs can fix user freedom on the web, including: emacs clients for specific websites and services, emacs-based browsers aka universal frontends, transformer of emacs packages to web apps and firefox browser extensions, and more.

• [1] https://www.gnu.org/philosophy/javascript-trap.html
• [2] https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

Projects and tools mentioned in the talk:

• LibreJS https://gnu.org/s/librejs
• lynx https://lynx.invisible-island.net
• noscript https://NoScript.net
• GreaseMonkey https://www.greasespot.net/
• Haketilo https://haketilo.koszko.org
• mitmproxy https://mitmproxy.org
• Invidious https://invidious.io
• youtube-dl https://youtube-dl.org
• libretube https://libre-tube.github.io
• newpipe https://newpipe.net
• woob https://woob.tech/
• Redirector http://einaregilsson.com/redirector/
• libredirect https://libredirect.github.io
• openwith https://addons.mozilla.org/addon/open-with/
• mastodon.el https://codeberg.org/martianh/mastodon.el
• mastorg https://g.ypei.me/dotted.git/tree/emacs/.emacs.d/lisp/my/mastorg.el
• sx.el https://github.com/vermiculus/sx.el
• buildbot.el https://g.ypei.me/buildbot.el.git/about/
• emacs-hnreader https://github.com/thanhvg/emacs-hnreader
• emacs-w3m https://emacs-w3m.github.io/
• luwak https://g.ypei.me/luwak.git/about/
• url-rewrite https://g.ypei.me/url-rewrite.git/about/
• wkhtmltopdf https://wkhtmltopdf.org
• pdf-tools https://github.com/vedang/pdf-tools
• emacs-web-server https://elpa.gnu.org/packages/web-server.html
• yolo.el https://g.ypei.me/dotted.git/tree/emacs/.emacs.d/lisp/my/yolo.el
• bom.el https://g.ypei.me/bom.el.git/about/

About the speaker:

Yuchen is a computer programmer, mathematician and free software advocate based in Melbourne, Australia. He is addicted to writing Emacs packages[3], of which a few has made into ELPA. He likes to claim to be the only free software advocate in Australia, in the hope that someone will correct him and point him to fellow comrades fighting for user freedom in Oz.

• [3] https://g.ypei.me

  Discussion

Questions and answers

• Q: I like the idea of using org mode to display data from the web. Are there many different packages that does that? (I am newish to Emacs, so maybe this is obvious to everyone else.)
  • A: dragestil uses roughly 10 packages that display data from the web.  Roughly half of them are org-mode based
• Q: Have you tried EAF (Emacs Application Framework) and its browser? If yes, what is your opinion about it?
  • A: No I haven't. My impression is it would run javascript by default. Not sure whether it has any extensions to block js. A nice comparison between different browsers including EAF, nyxt and emacs-webkit can be found in the readme file of https://github.com/akirakyle/emacs-webkit
• Q: I find the JavaScript trap almost impossible to avoid since I like to buy used stuff online and use my online bank. How do you deal with the JavaScript trap? I use NoScript and compromise on the few things I really feel I cannot live wihtout. Eww is nice for a lot of things, especially with R for less noise, but I need Firefox for those JS-entrapped pages...
  • A: Unfortunately I don't have a solution for that. I run nonfree javascript when doing banking or online shopping, though in a more isolated environment (mullvad browser) with a VPN. It's a tiny portion of my online activity (<.1% I suppose), so it's not that bad
  • However, that does not mean emacs cannot help. woob has a few clients interfacing with online banking, so perhaps at least some banks allow the possibility of non-js client. It would be good to look into this.
• Q: This is not really relevant to the talk, but I am curious about your nickname. Do you have some connection to Norway? Your nick indicates an interest in the architectural style inspired by the decoration on viking ships that was popular in the early 20th century. dragestil = dragon style
  • A: dragestil is my favourite architectural style. Look at these images on wikipedia https://en.wikipedia.org/wiki/Dragestil - aren't they gorgeous? I've only seen one of these famous ones in real life, the Buksnes Church on Lofoten Islands.
• Thoughts about Nyxt; about its aims, its approach, its relevance, etc.?
  • Very early on, ran into issues with keybindings. More specifically, some conflicts between binding j to follow-hint in document mode and C-s/C-r to next-suggestion/previous-suggestion in prompt buffer mode. Did not continue with trying nyxt because keybindings are basic functionalities IMO. Might revisit someday. nyxt has a noscript-mode btw that blocks javascript. A nice comparison between different browsers including EAF, nyxt and emacs-webkit can be found in the readme file of https://github.com/akirakyle/emacs-webkit
• Q: so trying to understand, is emacs being used as a web proxy to scrub potentially privacy attacking JS?
• Q: Anyone else here has experimented with Nyxt? I haven't much, but can't say there's not an overlap with some of the ideas of Emacs and all. Just curious.
  • Not the speaker:
    • I recommend qutebrowser over nyxt. For me it was just easier to use, customize and has better user experience.
    • I do/did too. But then it occurred to be that a very simple locally-loaded extension might very well be able to transform any of the major browsers into 99 + of Nyxt when paired with an Emacs backend (and websocket async bidirectional communication between the two)... (when said extension is made of a service worker part and a per-page part, to access both browser-level API/state, and page-level DOM, with just these two bits) e.g. could expose/present open tabs as pseudo-buffers (à la "virtual buffers/files"), candidates for completion, and such

Notes

• mastorg for mastodon
• hacker news in org mode
• emacs-web-server for hosting things from Emacs
• Dang, this is really a great demo.
• I love how he's using org-mode to do it all.
• It might actually save the web!
• Emacs as a Firefox extension!!! Ha!
• Definitely some interesting ideas in that one, and the literate form is top-notch. Warrants a focused rewatch for me (back-n-forth between 2 talks is not conductive to my best focus it seems...)
• I really like Org-Babel as a bridge to make complex one-off tasks ("why did the stuff in the database get into this state?" type things, usually) reproduceable and version-controlled.
  • Hear hear! Howard's talks over the years have converted me to do pretty much anything in Org-mode in literate form at this point
• I use org-babel for recurring tasks that I need to remember. Things I have to run once a month, etc. I guess I could use cron, but usually they aren't really time sensitive enough. Or they are things like clearing my mu4e trash, which requires that I quit mu4e.
• "It's not Emacs!" Ha!

Transcript

[00:00:00.000] Overview

Hello, I am Yuchen, and I will be talking about how Emacs may be used to save user freedom on the web. I will begin by describing the background issues, followed by solutions outside of Emacs. Then I will move into the main business of describing several ways to address the issues using Emacs, including free clients in Emacs, web browsers, also known as universal clients in Emacs, approaches using Emacs web server and Emacs web framework, which allows one to write an Emacs package and get a web app for free, as well as using Emacs as a Firefox extension.

[00:00:35.680] Background problems

OK, let's now move on to the background issues for this topic. Many of you probably already know what is free software. It is software that respects four user freedoms, including freedom 0, which is the freedom to use, freedom 1 is the freedom to study and modify a program, freedom 2 is the freedom to distribute exact copies of a program, and freedom 3 is the freedom to distribute modified copies. Different environments have different norms with regards to user freedom. For example, GNU/Linux distributions default to free software, even though the official kernel Linux contains non-free code, like non-free firmware. What I mean is, people generally expect free software in these environments. There's plenty of free software built on other free software, so generally people can accomplish tasks using free software only. Emacs, by comparison, is even better. It has freedom built-in, as it is highly customizable with self-documenting configurations. When a Lisp form is evaluated by the user in Emacs, the change is instantly reflected in the environment. Thus, it converts users to hackers effortlessly. From writing setq statements, which is similar to configurations in the majority of other programs, to writing functions, which are building blocks of Elisp features, to writing features and publishing packages, it is a natural progression. In this sense, Emacs perhaps has the most gentle learning curve for hackers. On the other hand, the default license in the Emacs community is GNU General Public License version 3 or later, which is the best free software license apart from the Affero license. Now let's move on to web browsers, which by contrast does not default to freedom. For one thing, free software JavaScript projects default to Expat license, which is also commonly known as the MIT license, which is a lax permissive license that could be exploited as developers could write non-free derivatives and subjugate user freedom. This also contributes to the JavaScript trap. Most popular web browsers nowadays simply download and run any JavaScript code requested by the web page. Generally speaking, there are two camps on this issue. One side would say JavaScript is simply part of life, and an integral part of the so-called modern web. Just accept it, and there is no point in fighting it. Indeed, it can be frustrating when greeted by "This page requires JavaScript and cookies to continue," or even a blank page when opening a web page while disabling JavaScript. The other camp takes a more principled position and says JavaScript is unnecessary. I mean, people use the web mainly for database-like operations to interact with data stored on other people's computers, like querying, creating, updating, deleting. I mean, 99% of the things happen in getting data, including reading news, watching videos, downloading images, etc., and posting data, including publishing this sort of materials, publishing news comments, videos. Why does this need any programs to do funny computations, right? Modern web browsers are also a pain to use. They are the opposite to Emacs in terms of customization capabilities. Such problems on the client side is the main focus of this talk. On the server side, the issue is known as SaaSS, service as a software substitute. It is about doing computing for users on other people's computers, which the user has no visibility, let alone control. Examples include translation or photo editing in so-called web applications. Another example would be web applications make recommendations based on user data and suggest what the users read or watch next. On the one hand, SaaSS is an intractable problem because free software is all about user freedom on one's own computer, not someone else's computer. On the other hand, this is also a lesser problem because it has trivial solutions, which is self-hosting and keeping computations local. Wouldn't it be nice to use a photo editing web application, but without the web?

[00:05:31.940] Solutions outside of Emacs

Right, now let's move on to solutions outside of Emacs that tackle these problems. There are generally two ways to fix this issue. One is blocking non-free JavaScript, and the other is substituting with free programs. Let's start with blocking. LibreJS, for example, is a Firefox extension blocking non-free, non-trivial JavaScript. It works by intercepting, filtering all requests for JavaScript, recognizing the ones that are trivial or free, and blocking the execution of the others. As an experiment, I logged the LibreJS output for about two weeks, and during which, of all the web pages I loaded, 23 domains have at least some LibreJS-compliant scripts. That is not much, though I did use other means to reduce the scenarios where I need to load web pages with JavaScript in Firefox, like using a text browser like Lynx. Then there's also NoScript, which is like LibreJS,

but it blocks all scripts, whether free or non-free, trivial or non-trivial.

[00:09:46.480] Emacs solutions

Now let us move to Emacs-based solutions. They are based on the same ideas but using Emacs.

[00:09:54.600] Free clients in Emacs

First, free clients in Emacs. Basically alternative frontends written in Elisp. There are several advantages. For example, integration with other Emacs tools, good for archiving, making use of Emacs libraries, extensibility, thanks to Emacs' own extensibility and customizability. Examples include mastodon.el for mastodon, or mastorg for viewing and archiving toots with org, sx for Stack Exchange, buildbot.el for buildbot, etc. Here's an example of mastorg displaying the hierarchy of a toot in org. Just wait. Right. So this is the toot itself, this is a first reply, this is a reply to the reply, and so on. And here is an example of opening a Stack Exchange link using sx. Let's check out the tag.

So we can browse the Stack Exchange Emacs site with ease.

[00:12:43.021] Web browsers in Emacs

Web browsers are universal clients because all sites support browsers. So in a world of no JavaScript, there will be no need to write bespoke clients. In such a world, instead of using JavaScript code to fetch JSON, web developers make server do the heavy lifting and just send the complete HTML over. Okay, back to reality. EWW, the default Emacs browser, is what people refer to as a text browser, even though it is not text only and it supports images too. It is a good solid browser that supports forms, etc. The downside is that it does not support CSS, so the formatting could be a bit ugly sometimes. There are some other browsers in Emacs too, like emacs-w3m, which is backed by w3m, and Luwak, which is backed by Lynx. Sorry for the naming, by the way. They often consist of a backend that fetches URL and parses HTML. For example, the built-in URL package and the libxml2 binding in Emacs are decent enough. And the frontend that renders the HTML, like shr or lynx, etc. There is also an xwidget-webkit, but this browser executes JavaScript, so it does not really help in this case. Browser extensions on Emacs are effortless, as they can be written as Emacs packages. For example, one could easily write Elisp scripts with similar functionalities to libredirect and openwith to redirect links, to rewrite URLs, or to open, say, a YouTube URL with MPV, but with even more flexibility. For example, here's how one could transform a Zoom link to a dial-in number so that it is easier to join a Zoom meeting without running non-free JavaScript. This might still be bad for privacy, but at least it's good for freedom. As mentioned before, one shortcoming of these Emacs-based browsers, Emacs web browsers, is no support for CSS, so the formatting could leave a lot to be desired. Maybe someone would write an Emacs browser package backed by wkhtmltopdf, which, when opening a URL, it calls wkhtmltopdf to convert the web page to PDF and opens in, say, pdf-view-mode of the pdf-tools, thus containing formatting, and all the URL clicks resolve to the same actions. Also, wkhtmltopdf contains a flag that disables JavaScript. Another idea would be to use Firefox as a processor to fetch URLs. Maybe it can be used to pass back the HTML after executing free JavaScript, say, if Firefox has LibreJS installed. This requires Firefox to send back the DOM, which could be achieved using native messaging. More on that later. Alternatively, one could also write a Firefox extension that sends the DOM in an existing tab back to Emacs. But thinking more about it, I don't think this is actually a useful idea, because most of the sites that work under LibreJS also are useful when all JavaScript is blocked. So, this means these sites are viewable under EWW, Luwak, etc. And another issue is that this could also make running non-free JavaScript easier, which is harmful to user freedom.

[00:16:52.380] emacs-web-server - overview

OK, let's move on to the idea of running Emacs as a web server, so that Emacs client packages are web apps serving as alternative frontends. Why would we want to do this? Well, as much as one wants to be always in Emacs, it is not always feasible. For example, one may be on the go and needs to look up something on the phone. On the other hand, Emacs client packages are just alternative frontends but written in Elisp and run in Emacs. With the help of emacs-web-server package, we can access Emacs packages on the web. emacs-web-server package is not something new, but seems to be underused in the community somehow.

[00:17:30.380] emacs-web-server - hello emacs!

OK, let's start with a simple example called hello-emacs. It is pretty straightforward. Just require the web server feature and run ws-start to start a server process and send the string "hello emacs" to the process regardless of the request. As you can see, it is going to be available at port 9000 of localhost. Let's try it out. We need to first evaluate this code block. And it works. To stop a server, just run ws-stop on the web server object. Let's evaluate. Yep, it stopped.

[00:18:17.580] emacs-web-server - yolo

OK, now let's move on to something funny that you should never run on the public web. I call it yolo.el. It uses htmlize to make any Emacs buffer available on the web. Let's try it out. Just require the thing and start the server by yolo-start. And it's available at port 9999. By default, the root domain shows the splash screen which needs to be available. Running display-splash-screen ensures that, but here I've already run it. So let's have a look. And here we have the splash screen. Emacs tutorial and such. Unfortunately, none of these links work, which is something we will revisit later. So, to show an arbitrary buffer, just use the buffer name as a path. For example, the slide has the buffer named web.org, so we can display it. Let's try something fancier, like the man page of ffmpeg. So this is the man page of ffmpeg. And the buffer name is a bit more complicated. I have the URL available here. It's missing a star. It's pretty neat if you ask me. And, yeah, what else? Well, we can also browse EWW in Firefox. For example, let's check out gnu.org, and note that the buffer name is EWW with stars. So, ah, it works. And it has all the graphics even. Now, how about we do it the other way around? So we load the current slide web.org using this funny thing. And it works. Not as nice as the Org buffer, though. Right, and now that gives me some funny idea. So I'm a firm believer that memes are meant to be enjoyed in silence rather than read out loud. So I will jump straight to trying this idea, which is loading the EWW buffer URL with EWW itself. Loading, loading, loading. Spoiler alert, it never loads. So that concludes the demo. And so we can stop the server, web server, with yolo-stop. So one could extend yolo to serve arbitrary Emacs commands, making it even more dangerous. That is, for example, localhost:9000/m-x/magit-status would run magit-status and show the magit-status buffer in the web browser. Or localhost:9000/m-x/eww/ any arbitrary URL to browse arbitrary URL with EWW inside of Firefox. It can serve as a way to block all JavaScript, because EWW does not support JavaScript. And enforce preferred colorscheme in Firefox, since htmlize, as you have noticed, faithfully reflects the theme used in Emacs.

[00:23:07.940] emacs-web-server - emacs web framework

Okay, so we know that yolo is unsafe and needs to be refined. In fact, we don't necessarily want to run Emacs on a web browser. After all, a modern web browser is something one has to fight all the time and should be avoided whenever possible. We want to instead be able to access things when forced to be in a web browser, in which case only the motivations of an alternative frontend apply. Moreover, the ideal situation is an Emacs web framework, a tool that automatically transforms Emacs packages to web apps, so that one does not need to write extra code to get a web app that does the same thing as the package. We also need all links in the web pages to work. As noted before, the links on the yolo Emacs splash screen do not work. So here's a proof-of-concept example. It's called bom.el. It gets some weather forecast data from the Australian Bureau of Meteorology and displays it in an org buffer. So let's try it out. One could do M-x bom, which shows an org buffer with links to each state. So based in Melbourne, naturally, I would like to find out the weather of Victoria. And yes, to execute this command. Wait, wait, wait. Right. And we are at a buffer that shows the weather forecast of the whole of Victoria in the hierarchy. Note that this back button takes you to the previous page. So here are the regions of Victoria. I think Melbourne is in Central. And yeah, it shows the seven-day weather forecast of Melbourne. You can also reach this page by running, let's see, directly M-x bom-state. Vic. OK. So this works. And this is bom as an Emacs package. Now let's check out bom as a web app transformed by Emacs web framework. So start the web server with bom-start. And let's try it out. It's at 9000 again. Oops. Invalid path. Oh, that's because it makes exactly one command to one path. So remember that we used the bom command to show the landing page. So here we need the bom in the path as well. And it shows the same landing page, except in HTML. Let's check out Victoria weather forecast as before. And it shows an HTML converted from the org buffer using ox export HTML, whatever. And you can see even the back button is here. That takes you to /bom. So let's have a look at Melbourne. Here it is. Hooray, it works. So, yeah, as usual, you can stop the web server with M-x bom-stop. Right. And alternatively, it can also be deployed directly in terminal in a dedicated Emacs daemon. So you can see that there's a one-one correspondence between the Emacs package interface and the web interface. And that implies some restrictions to the Emacs package for the Emacs web framework to be able to do its job. Right. For example, the package needs to have an Org interface and the links that trigger other commands need to be in Elisp links so that the Emacs web framework can translate it to web server URL path. Note that Emacs web server framework is not a real package. I wrote some functions in bom.el serving the purpose, and they should be separated out eventually without much trouble. One could get weather forecast without running JavaScript anyway, which makes bom.el less important as an alternative web client. Though it does provide, dare I say, a clean and minimal interface compared to common weather forecast web pages. Other more relevant use cases could be Mastodon, whose official web client requires JavaScript to display a post. The mastorg package that shows an Org hierarchy of toots rooted as a given toot could be a low-hanging fruit. The limitation of Org interface requirements can also be relaxed in further work, if one could extend Emacs web framework to translate back and forth between Emacs widgets, say, including buttons and web page widgets, including links. Another more far-fetched idea would be to translate to other types of interfaces, like GNU/Linux or Android GUI. How about animations? Say, M-x butterfly, or even web games from Emacs games? Possibilities are unlimited in this, as always, in Emacs. I also noticed some limitations when trying to actually host bom.el on the public web. Given the limited access to the Emacs server, I was comfortable enough to give bom.el a go to serve it on the public web. However, I immediately stopped after noticing how slow it is. It can take more than 30 seconds to load a page of weather forecast for a state. I am also not sure how many simultaneous connections it can handle. In any case, I think the package emacs-web-server could do with some performance enhancement.

[00:29:40.420] Firefox with emacs for extensions

Right. Because of the time constraints, I will briefly touch one final idea, which is to use Emacs as a Firefox browser extension. We already have org-protocol, which allows Firefox to communicate with a running Emacs server by sending an org-protocol URL to the latter. It can be used not just for capturing or storing links, but to execute arbitrary code on any component of the URL. However, it is fire and forget, and Emacs cannot tell Firefox what to do. There may be a length restriction, too. For example, Firefox may not be able to send back the whole DOM. This claim needs to be verified, though. Native messaging is one solution to this problem. It is a two-way communication channel between a Firefox web extension and a local system process started by the web extension. The process could be an Emacs server, which would make Emacs effectively a Firefox web browser extension. In this case, Elisp would be the main extension language, rather than JavaScript. However, JavaScript is still needed at the Firefox end of the communication channel. As a simple example of this idea, Firefox could ask Emacs to redirect a URL by removing tracking and using alternative frontend, etc. However, I was not able to implement this due to some tricky business with enforcing synchronicity that allows the web extension to wait for responses from Emacs. Some further work, I suppose.

[00:31:25.360] Thank you

That concludes my talk. Thank you for your attention.

Captioner: ken

Q&A transcript (unedited)

Hi Yuchen, how are you doing? I'm not sure if I... Yeah, I mean, brain not working well at this moment. How about you? EmacsConf is a very taxing process and I can tell you we could have a race to know who's more more tired right now between you and myself but I guess we'll find out at the end How late or how early I should say is it for you right now? It should be like 6am or like 8.30 or something. Well, anyway, thank you for the sacrifice just to answer some of the questions. All right, so I'll be displaying the questions. I'll be, let me just maximize this on the stream so that people can read everything on my screen. So what I'm going to do, Yuchen, as usual, I'm going to start reading the questions on the pad. I'm going to ask Sasha to open the Q&A. Yes, it's already open. Cool. So if you want to join us, people, Feel free to click on the link on the talk or on IRC to join us on BBB and to ask your questions. Otherwise just leave them on the pad. Alright, Yuchen, starting with the first question. I like the idea of using org-mode to display data from the web. Are there many different packages that do not, I assume. I'm new to Emacs, so maybe this is obvious to everyone else. specify what is it to display data from the web. Just reading it like this, I'm reminded of Adam, Arthur Pappa, I mean, Code All Capture Web, which technically captures the web and allows you to embed it in the page, but is it really displaying data from the web? Are we implying live transmission? Do you see what I'm talking about? like, having Emacs as a client that's sort of getting data from the web and then displays in Emacs, like using API or using web script. So yeah, like the hreader package or a few packages mentioned in my talk. Yeah, that's a good question. I mean, I really don't know how many. So from my experience, maybe I use like 10, less than 10 packages that do these things. And among these packages, maybe it's half of them are org, Is that what you said? but that's just based on the packages I use. I haven't done a survey about this. the answers. I mean, you already demonstrate a lot of competence and you talk about all the things you approach with your particular setup, So you don't need to have all the answers. Okay. All right, moving on to the next question. Have you tried EAF, i.e. The Emacs application framework and its browser? If yes, what is your opinion about it? I try to remember why I haven't tried it. It has a browser. I assume the browser executes JavaScript by default. I have to check. Emacs.daf slash daf browser. and you know whenever you want to report to the pad you know you write a little blurb haven't tried it. that's cool. We're gonna move on to a question that is a little bit off topic, but I've also been interested about your nickname on IRC. This is not really relevant to the talk, quoting the question, but I'm curious about your nickname. You have some connection to Norway. Your nick indicates an interest in the architectural style inspired by the decoration on Viking ships that was popular in the early 20th century because Dragonsteel, I assume in Norwegian, is Dragon style. Are you familiar with this? style, I think. I mean, I lived in Sweden for like 2, 1 half years and yeah I went to Norway once and I saw like this church in Lofoten Island, on Luton Island. Right. it was amazing. So, yeah, that's exactly why I chose that as my nickname, because it's my favorite architecture style. the viewers, so I hope you feel validated in Yuchen, do you have any thoughts about Nixed, about its name, its approach, its relevance? About Nixed, the browser, N-Y-X-T. Oh, Nixed. Well, I mean, it's not Emacs. It's kind of similar. I think it tries to do something similar to Emacs, but The problem with Nix is that very early on I encountered an issue with keybinding. So the first thing I want to do is to make all its keybindings emax-y. So that's obviously... So what was the problem? So yeah, I couldn't even do that. I thought, I was expecting that it could... There shouldn't be any issues with setting up whatever key binding you want. So I, the, the issue was that when I tried to do when I tried to bind Ctrl S Ctrl R to the prompt going up and down, so I use I was I complete and I'm used to like the control S and control R to go, to cycle through the selections. And so I want it the same in next in its prompt like when, for example, typing a URL and get completion from history. But it has a conflict with the... And also, I try to bind the hint. So when I want to follow a link, So I press a hint key and then like all these links are highlighted with like little letters that I can like choose which 1 I want which link I want to follow. So I try to bind that 1 to J sort of like Control C, Control J, or mode. But apparently there's a conflict here. So when I do both these prompt mode binding and the document mode binding, Yeah, the prompt no longer works. And I reported the bug to Nixt. And yeah, and there was response but there are so many bugs there, and I don't think that bug is very high priority. So yeah, I basically stopped trying that because key mining is very important to without key bindings I can't like, I won't. So, okay, I feel this is a very basic functionality. I'm kind of reluctant to So yesterday with Stefan we were talking about sane defaults and when he was sleeping today we talked about it again with a speaker. We did the mentor talk. Feel free to re-watch it afterwards. But it's funny how, you know, regardless of how big the package actually is, they always provide some kind of sane default and with Nixed, obviously, it's built with a Vim mentality and modality of key bindings. And for us, we are more used to the Emacs way of doing things. It's a complete blocker. No matter how great the pieces of functionality behind Nixed are, just the fact that UX-wise we cannot get into it or we cannot have it behave nicely with what we do. It's a massive block that is preventing appropriation of such tools. So it might seem very basic to bounce a package at the level of key bindings but that's what we all do. we have about 2 more minutes of questions and I see people are writing more questions. Did you want to add something, Yucheng? On what we're saying? I'm going to ask you to be quick about this

1. I'm going to read the question,

Questions or comments? Please e-mail id@ypei.org