49 karma · joined February 21, 2020
This is really a great manifesto, but I fear that it might go a bit too far to be realistic. Perhaps rethinking the filesystem and databases is not the top priority.
Fedora 43 and LM Studio with Vulkan llama.cpp
There was a push to prevent browsers to be too lenient with the syntax in order to avoid the problem that sloppy HTML produced (inconsistent rendering across browsers)
There is however a weakness of SQL is that it's purely declarative and it's difficult to make sure it does the right thing. I often find myself in front of queries that are badly optimized and I'd welcome a language that would be less declarative where you could tell the database engine which index you want to use and how explicitly. The optimizer has table metrics but with the domain specific knowledge the programmer has generally better insights.
The proposal in the video is actually not bad (domain at the start followed by actual URL) if they can put back tge http(s):// prefix in the URL part.
I'm using Hugo and for my purposes, I always start without any theme. Basically, I start to write a markdown file for each page, and an HTML template, then if I need more complexity I have the power available underneath.
Static website generators are not necessarily complex to use, and they generally stay compatible from version to version so you only need to learn the new features and only if you want to use them.
Full p2p is technically complicated and does not work well for small devices not always connected, we should keep servers to host the discussions.
The servers should be able to subscribe to a moderation. You don't want to host a discussion illegal in your country gor example. Users should also be able to move servers painlessly. If the users trust their servers with their identity, it does not need to use crypto for user identity. On your profile page on a server you can link other servers identity and that's enough and simpler.
If a discussion group is private, it should only be hosted in servers of their members and not elsewhere.
I started working on such a system https://github.com/mildred/disputatio.nim but beyond the technical stuff I have no idea how this could gain adoption.
The problem with IMAP is that some requests are not possible efficiently, and the real breakthrough of JMAP is that those requests are now possible and clients are now allowed to be fast. For that though, the server-side JMAP needs to access the indexed mail store directly.
I started looking at implementing that
Also, the fact that JMAP makes it convenient to only download part of a message, and let the server do all of the message parsing does not encourage the client developer to do much processing client-side and keep e-mails blob in cache to be processed offline.
Also, the great idea behind JMAP is to chain requests so a series of tasks is performed on the server and the client then get the end result. This works great for the majority of cases but the replacement syntax (to replace results from a previous request in a following request) is not powerful enough in some cases (when trying to reuse complex responses in follow-up requests)
The other issue is that there is no way to easily groups e-mails from a given contact. There are JMAP extensions for CardDAV and CalDAV that can be of some use but it's difficult to bridge them with the Email spec and get all e-mails from a given contact for instance.
Last, it lacks editing features like appending a custom header to existing e-mails. The fact that JMAP abstract away all of the MIME format is great, but makes it difficult to just add a single header to an email.
JMAP main benefit is that it allows a mail client to to things efficiently in JMAP that are extremely difficult to do in IMAP or take a long time to do. Merely adding JMAP support in Thunderbird will not add any benefit.
The benefit will come if Thunderbird is refactored internally to make use of the nice properties of JMAP, but then there will be a problem with IMAP compatibility which must be kept.
JMAP is nice for new mail clients that can move away from a folder-centric paradigm, but if you already managed to use IMAP then it's less useful.