Sorry, that was an unduly inflammatory framing from me. You’re right that keys.openpgp.org runs smoothly, particularly in contrast to the previous generation of SKS hosts. I don’t think it comes close to meeting the definition of a decentralized identity distribution system, however.
fyi, I would consider this as a general statement to be the disrespectful attitude of an asshole, and I don't think I'm in the minority with that. Things people build don't have to be fantastic or free to deserve respect.
Even as a builder myself, I prefer to get unfiltered unabridged reactions from my users, emotions and all. I think it's more disrespectful when you tell someone they've built something good when you don't really mean it. It's a form of condescension and betrays that either you don't believe the person can do better, or you don't care to help them do better.
Truthful feedback is always a gift even if it hurts.
For anyone relatedly wondering about the "schism", i.e. GnuPG abandoning the OpenPGP standard and doing their own self-governed thing, I found this email particularly insightful on the matter:
https://lists.gnupg.org/pipermail/gnupg-devel/2025-September...
> As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and has no automated CI. If GnuPG were my project, I
would also be anxious about each change I make. I believe that because of this the LibrePGP draft errs on the side of making minimal changes, with the unspoken goal of limiting risks of breakage in a brittle codebase with practically no tests. (Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. But that's surely not a failing of RFC 9580.)
Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war.
>Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG.
Traditionally the OpenPGP process has been based on minimalism and rejected everything without a strong justification. RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard. It contains a lot of poorly justified stuff and some straight up pointless stuff. So just supporting RFC-9580 is not the answer here. It would require significant cleaning up. But again, just supporting LibrePGP is not the answer either. The process has failed yet again and we need to recognize that.
>RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard.
That sentence is too long, it should read:
>RFC-9580 is basically everything
The RFC has every idea that anyone involved in its creation ever thought of tossed into it. It's over a hundred pages long and just keeps going and going and going. Want AEAD? We have three of them, two of which have essentially zero support in crypto libraries. PRFs? We've got four, and then five different ways to apply them to secret-key encryption. PKC algorithms? There's a dozen of them, some parameterized so there's up to half a dozen subtypes, including mystery ones like EdDSALegacy which seems to be identical to Ed25519 but gets treated differently. Compression algorithms? There are three you can choose from. You get the idea.
And then there's the Lovecraftian horror of the signature packets with their infinite subtypes and binding signatures and certification signatures and cross-signatures and revocation signatures and timestamp signatures and confirmation signatures and signature signatures and signature signature signatures and signature signature signature aarrgghhh I'm going insane!
The only way you can possibly work with this mess without losing your mind is to look at what { GPG, Sequioa } will accept and then implement a minimal intersection of the two, so you can talk to the two major implementations without ending up in a madhouse.
Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was to leave gnupg behind. This is a bonkers decision for OpenPGP as an ecosystem, but it was not made in ignorance of the consequences. And as far as I'm aware, even with today's hindsight, noone involved in the process regrets making the decision.
Yes, the OpenPGP standards schism was all about personality conflicts. Those conflicts still came from a fundamental difference of philosophy. Who's idea was it to have Koch lead the most recent attempt at a process? Why was that supposed to make a deadlocked process somehow work?
None of this matters now. Everyone is cheerfully walking into an interoperability disaster that will cause much harm. There isn't any real chance GnuPG will lose this war, it is pretty much infrastructure at this point. But the war will cause a lot of harm to the PGP ecosystem, possibly even to the point that it becomes unusable in practice. This is an actual crisis.
Either faction can stop this. But at this point both factions are completely unreasonable and are worthy of criticism.
Sorry, but no. This is not a 50/50 situation where a bonkers position is inexplicably backed by half the populace. There is one faction that is a single person on a large lever, and another who are everybody else. Werner made it clear he will accept nothing less than an unquestioning BDFL hierarchy, but has over many years demonstrated no competence to actually fill that role (TFA being a small example of this).
Your product might actually relevant for me, but browsing your website I gotta say it's quite the turnoff that there is nothing there on your company. I could not find out, within reasonable time, where you are incorporated.
For anyone looking into this who doesn't want to design their own layout from scratch, a well maintained layout for small keyboards is Miryoku. Worked very well for me (in qwerty base + vim directional keys mode) on a keyboardio atreus
Miryoku is a solid layout. Designing your own layout is definitely time consuming, and not something most should try diving into if they are new to small form factor keyboards.
Can't say I agree with the sentiment. Miryoku's layout looks pretty arbitrary, as is any other <60% setup. I daily drive a Planck (4 more total keys, but very similar levels of layout restrictions) and my layer designs are wildly different.
I would say just find or build a keyboard with support for Via or Vial so that you can change things on the fly when it feels wrong. If you're going down the small form factor keyboard path you're already committed to rewiring muscle memory, you might as well design your layout to meet your specific needs too. It's highly unlikely you will encounter someone else's Miryoku layout in the wild and need to type on it.
I don't think Miryoku is a good layout for many either, it will depend on your usage.
A strange thing is that many come in to the small split keyboard world and then don't have the motivation to come up with something that works for them. You can make anything work, so a lot make Miryoku work but I doubt for many that would be the best layout for them.
I code a lot and find that its layout would not suit me. I have 99% of what I need on a the base layer and one more layer for doing development work - on a 36 key board. I could not imagine that I would want to switch layers as much as I would have to for a continuous stream of alphabet/symbols and numbers.
I think Miryoku would be fine if you were an average computer user editing documents, emails etc and I do sometimes forget that there are a lot of guys out there using Miryoku doing only that.
I use this on my 42-key Corne: https://mark.stosberg.com/markstos-corne-3x5-1-keyboard-layo...
It's a sensible starting layout that I've made very few changes to. I added a mousekeys/macro layer, moved single quote to put semicolon on pinky, added print screen bind, and added a homerow combo J+K for esc.
It's not super complex. I ended up just modifying the locations of the layer toggle keys. In the default Miryoku layout, in order to switch the keys to a different layer on the right hand you need to hold a button on the left hand. I found this to be annoying since some actions like entering and using a navigation layer can be done on 1 hand.
I just got a toucan. The touch disc on it is great. Having a pointing device in fingers reach makes it appealing enough for me to consider upgrading from a corne.
An AI can not meaningfully say "thank you" to a human. This is not changed by human review. "Performance" is the completely wrong starting point to understand Rob's feelings.
If you are surrounded by a class of people that makes you genuinely second-guess the optics of your (appropriate) em-dash usage, I think that tells you a lot about what you need to change in your life. Likely you'll be happier in the company of people who know how to pick up a professionally written book or article.
This is false, SAML and LDAP are available. Zulip self hosted has all features with no restrictions, except for mobile notifications which require a subscription for $3.50/u/m (unless you are less than 10 users or are not a non-profit of any kind)
Oh, yes. This seems like nothing short of necessary for the long term viability of the project. I really hope this effort succeeds, thank you to everyone pushing this!
I can't find it now but I recently saw a graph of new Debian Developers joining the project over time and it has sharply declined in recent years. I was on track to becoming a Debian Developer (attended a couple DebConfs, got some packages into the archive, became a Debian Maintainer) but I ultimately burned out in large part because of how painful Debian's tooling makes everything. Michael Stapelberg's post about leaving Debian really rings true: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
Debian may still be "getting by" but if they don't make changes like this Git transition they will eventually stop getting by.
Hey, I take issue with that. keys.openpgp.org is just about the only thing running smoothly in the openpgp ecosystem :P