rodarima

By the way, there is a CSS bug in HackerNews that we discovered today[1] that is causing most of the rules to be wrongly parsed. I'm not sure if hn@ycombinator.com is the proper place to report it.

https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman...

Here is the bad rule:

    input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; }

This is the 3.1.0 first release candidate. Please report problems if you can test it.

Thanks, Rodrigo.

The problem is fixed now in master. It was caused by an attempt to shutdown the SSL session (which requires sending data) in a closed file descriptor, which is handled different between OpenSSL (no thread error queued) and LibreSSL (badsectoracula was using LibreSSL, which queues a thread error), and later causes an assert to trigger as it was not expecting any error in the queue. See[1] for more details.

[1]: https://github.com/dillo-browser/dillo/pull/59

Thanks again for the report, these type of issues are hard to reproduce without using different environments.

Thank you! :-)

Thanks for your DPI work. I tested the gemini plugin and works very well.

My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that.

For now I uploaded Charles plugin written in shell script[1], which always trusts the certificate.

[1]: https://github.com/dillo-browser/dillo-plugin-gemini/

But I'm considering switching to the Go version if I can find a way to improve the UX.

Also, I kindly ask you to add the tag "dillo-plugin" so you can make Dillo plugins easily discoverable by searching for the tag in GitHub[2].

[2]: https://github.com/topics/dillo-plugin

> I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

This was done initially[3] (before 2007) but it was moved to the browser itself[4] in 2016.

[3]: https://github.com/dillo-browser/dillo/commits/afd2763caa56d...

[4]: https://github.com/dillo-browser/dillo/commit/bf5a7783f4a192...

Author here. I haven't used in years so is probably pretty broken. There is a "wire" branch that implemented some debugging of the different encapsulation layers in a plain text format.

Also, last time I was using it I needed to use a throwaway number as WhatsApp was detecting and banning anything that resembled a non-official client.

This may (finally) change with the Digital Markets Act [1][2] in Europe, but sounds too good to be true.

[1]: https://digital-markets-act.ec.europa.eu/index_en

[2]: https://techcrunch.com/2023/09/11/whatsapp-has-started-work-...

> only stuff behind cloudflare gives any issues (unless you're running a local proxy to handle ssl).

This used to be a problem because Dillo didn't implemented SNI, but should be okay now. If you still have some site that doesn't connect with Dillo from git (there is an updated dillo-git AUR package in Arch Linux), please report it :-)

AFAIK, Cosmopolitan only works well if your program only depends on the libc. Even if you statically compile Dillo and the FLTK, you still would need a graphic Xorg server. For Linux and BSDs may work, but in macOS I think it won't, as for that platform you need the FLTK to link against macOS graphic libraries.

> Wow, this is so stunning. Thanks a lot Rodrigo, and obviously to the dillo team, Jorge Arellano Cid, etc.!!

Thanks!

> follow the "from git" installation instructions here [1] BUT, before running `./configure`, run these export commands [2] to make sure that the openssl files are found

I should add that to the install instructions for macOS, although in the CI it seems to work without the include flags (keep in mind I don't own a Mac, so my testing abilities are limited).

The modern web won't stop surprising me :-D

> If we could agree on some kind of "low-tech web" (a subset of html, a subset of css, a subset of javascript -- or maybe no javascript at all?) then Dillo could be the champion of this.

There is a "movement"[1] called the small web (smolweb?) which basically does what you are describing without being so restrictive as Gemini. AFAIK Dillo should be able to render most of those features properly.

[1]: https://smolweb.org/guidelines.html

> Interesting to see a mix of C and C++ in the same codebase, that always makes me curious if there is some internal/mental "pressure" to convert the C code to C++ since that does seem simpler in many ways if you're already using C++.

The initial Dillo was fully written in C and it used GTK+. As it moved to FLTK it began rewriting parts in C++.

> Also, does anyone know why the functions have a (to me, incredibly random) "a_" prefix? Like this, from "dicache.h" [1]:

This is something Jorge came up with around 1999[1] for the C part, so the "a_" prefix states functions that are used outside the module (like public in C++), while the others are not. The choice of "a" is explained as:

> Why the "a_" prefix? > > Because it reads better "a_Menu_create" than "d_Menu_create" cause the first one suggests "a Menu create" function!

[1]: https://dillo-browser.github.io/old/NC_design.html

I don't think this alone is a good choice, as one should better use "static" to enforce it.

> I used to test out sites on Dillo a lot to see if the experience was absolutely broken

Thanks! That should be done more often :-)

> Shame to see a project moving from a self-hosted Mercurial repository to a US-megacorparate-owned Git repository in Microsoft GitHub

Agreed. I decided that it was a good starting point moving to GitHub as a first start, to increase the chances the project gets more visibility and hopefully attract more contributions. I also trust GitHub to be alive for at least 5 to 10 more years, so I can put a redirect notice on the main webpage.

But yeah, I agree it would be better to self host or move to a federated forge. There is an issue to cover other options[1], but our current problem is that other forges like Codeberg don't have a way (as a free account) to run the CI pipelines in other platforms like MacOS. My idea was to eventually get hold on some real hardware so we can setup our own runners and also test in different architectures. Feel free to add other alternatives and I will take a look.

[1]: https://github.com/dillo-browser/dillo/issues/39

Keep in mind also, that because the project was previously self-hosted (including the mail server) that created a gigantic single point of failure (which failed very badly) that I'm trying to avoid.

> But at least the maintainer is committed to accepting email patches so folks aren’t required to create accounts / accept ToS with them.

Yeah, I'm thinking in creating a mailing list for that purpose, but apart from sourcehut (at least on alpha) and googlegroups, I don't know that many places that offer one free of charge.

Good idea. I think it may be this one[1] as it is also from the same region Valparaíso in Chile as Jorge. I don't use LinkedIn, but if someone can message him that would be great, thanks!

[1]: https://cl.linkedin.com/in/renatobravo

Thanks, raphlinus as in Raph Levien! I was just reading your bytesink document [1] from around 1997 and checking the history of gzilla, the precursor of Dillo.

[1]: https://sources.debian.org/src/gzilla/0.1.5-3/bytesink.doc/

PS: Maybe you could give us a hand contacting Jorge :-)

> The default site is still dillo.org which crashed the browser when it tried to visit it. Same with duckduckgo.com (crashed). Actually the crash seems to be related to some assert failure with OpenSSL as recompiling Dillo with mbedSSL lets me visit these sites.

Thanks for testing! I need to replace that with the new website. Could you open an issue on GitHub with some details of your system and OpenSSL version so I can try to reproduce it?

> I tried to login and reply to this thread but for some reason it wouldn't login (no error or anything, after entering my username and password and clicking login, i'd remained logged out).

This is likely because the cookies are disabled. See the Cookies docs:

https://dillo-browser.github.io/old/dillo3-help.html

https://dillo-browser.github.io/old/Cookies.txt

By default, Dillo has all cookies disabled. You have to either manually enable them per site (recommended) or globally:

  $ echo "news.ycombinator.com ACCEPT" >> ~/.dillo/cookies.txt

Then reload the dpi daemon to read the cookies config again:

  $ dpidc stop

I always pronounced it as the Spanish "armadillo" word /aɾmaðiʎo/ but Jorge uses "dil-oh":

https://youtu.be/A6mb9qt2-3o?t=212

Also, the video explains a lot about of the project, but in terrible quality :-D

I would recommend not opening suspicious pages in any browser at all. If you don't have the choice, then maybe download it with curl(1) and then inspect it with hexdump(1) or more(1), so you can see the content before sending it to an HTML parser.

Assuming you don't use Javascript, kind of.

Dillo supports XEmbed, so you can run it embedded in another X windows. This is done by Claws Mail to render emails as HTML [1].

[1]: https://www.claws-mail.org/plugin.php?plugin=dillo

I'm not sure how those other browsers are in terms of memory requirements, but Dillo runs fine with low memory (assuming you load normally sized pages). Here is an example where Dillo opened the single page HTML5 spec, which is 12.9 MiB of HTML, and google.com (sizes in KiB):

  % ps vp $(pgrep dillo)
      PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
   919059 pts/1    S+     0:01      0   458 59425 46884  0.2 dillo https://html.spec.whatwg.org/
   919584 pts/6    S+     0:00      0   458 28589 17360  0.1 dillo https://google.com

I'm collecting some pictures of Dillo on different computers, with the idea of adding them to a gallery. Here are some on the web:

[1]: https://en.wikipedia.org/wiki/Gateway_HandBook#/media/File:H...

[2]:http://damnsmalllinux.org/dmesg-screen-1.jpg

It would be nice to see it running in some remote location :-)

I also had it running at some point in my old Android phone (running Xorg directly on the framebuffer), but I don't know where I saved the picture.

Dillo targets HTML4.1 and CSS2.1, although it incorporates some little features from HTML5 too. For CSS there is a list of "tests" [1] that more of less give you an idea of what works.

[1]: https://dillo-browser.github.io/old/css_compat/index.html

Here [2] is the original development plan, which was focused on making the floating elements work well, but the main developer of that area, Sebastian, sadly passed away.

[2]: https://dillo-browser.github.io/old/Plans.html

I'm planning to add better support for the most common attributes that break the layout the most (margin: auto) and also keep a proper table of the support status.

Feel free to upload some more:

https://github.com/dillo-browser/dillo-browser.github.io/pul...

I have no news, but I hope HN could reach him :-)

> * w3m's bookmark system is implemented using local CGI; it seems Dillo's bookmarks are implemented as a dpi plugin too.

Yeah, a lot of things [1] are implemented as DPI in Dillo. Some of the plugins implement "websites" like file:, vsource: and ftp: but others implement other features like the handling of cookies, downloads or bookmarks. As they are a different process, if you close the browser, the downloads continue.

[1]: https://github.com/dillo-browser/dillo/tree/master/dpi

> * w3m can use urimethodmap + local CGI to implement additional protocols. I guess DPI can do that too? (At least the custom man: scheme in dillo-plugin-man seems to indicate it can.)

Yes, there is a file (~/.dillo/dpidrc) that associates the protocol to the plugin binary (like this "proto.man=man/man.filter.dpi"). There is also gemini: gopher: and even git: available as external plugins.

> I had no idea any browser supported this besides w3m. I mostly imitated w3m's design in my own project (which includes the twist that support for every protocol, including HTTP, is implemented on top of a similar plugin system); I guess I have a second reference point now :)

In fact, not so long ago, the HTTPS protocol was implemented as a DPI plugin, but it was changed to be part of the browser.

I'll have to do an in depth analysis first, I have very little experience with NetSurf.

I would say that the plugin system is one of the things makes Dillo a bit different.

I had some ideas to do performance tests and also check how well the rendering engine works with choppy connections (while content is still slowly downloading), but I didn't do any tests yet.

There were some very old results against firefox comparing memory usage in the old page [1].

[1]: https://dillo-browser.github.io/old/memory.html

I think most of them are from Charles, and he maintains a scuttlebutt-web interface, so you can download them from the homepage:

https://celehner.com/projects.html#dillo-plugins

I already talked with him about keeping a copy of them in GitHub under the dillo-browser organization.

> and if you're interested I can zip them up and send it to you to be forked and worked on the project

Feel free to open an issue and upload it there, so we can keep a copy of the zip. Thanks!

> I used to use dillo on my main desktop too, for browsing documentation that wasn't too heavy on CSS - having 20 to 40 tabs open would gobble up a lot of RAM in Firefox, whereas dillo happily stayed around 100MB no matter what I threw at it. My current desktop has enough RAM this not a concern any more, but I have fond memories of using dillo on memory-deficient machines and am a current user still.

This is precisely the objective Jorge had in mind, so people on other parts of the world with less capable machines where still able to access the web.

While I was in university, I was using an old Pentium 4 at home (which I still use) which couldn't open a single tab unless you wait around 30 seconds for it to load. So I was mostly using Dillo and failing back to Google cache and then Firefox to read something that required Javascript.

I used it for years and it always was super fast. Also, my network connection was not very fast, so loading only the HTML helped a lot.

> So thanks to everyone who continues to work on this, I really appreciate the work you do! Dillo is a fine piece of software that I have enjoyed using for at least 15 years now, and I hope it will be around for many years to come! <3

Thanks :-)

Yes and it has been discussed in the mailing list before [1].

[1]: https://groups.google.com/g/dillo/search?q=javascript

However, I don't think the machines that Dillo is targeting would benefit from adding support for it and it would increase a lot the surface for security problems. Maybe my advise would be to use another browser if you have the computing power to run JS.

This is already supported via plugins, check:

https://git.scuttlebot.io/%25n7g%2BJlKZjPV6CRfSQL5YUWk%2BxYg... https://github.com/boomlinde/gemini.filter.dpi https://celehner.com/projects.html#dillo-plugins