I have good news for you:

https://www.polygon.com/24074441/gigantic-game-relaunch-rampage-edition-steam-release-date

Mercurial has comparable features (though maybe not obvious to someone accustomed to git) without the usability problems that still plague git nearly two decades later. Hg’s interface was made with humans in mind. Git’s was made to cut you.

(And it has cut so very many people that it’s consistently among the most popular topics in Q&A forums, and has even inspired comics.)

Thankfully, git’s early cross-platform shortcomings were eventually fixed, so that’s at least some progress. I hope its UI and docs eventually get some love, too.

I wish Mercurial had won.

deleted by creator

The interface is the best I know of, a lot like pre-Microsoft github. Especially important to me is that It doesn’t intercept my browser’s built-in shortcuts like github now does, or require javascript or bury things under submenus like gitlab does.

The promise of federation is appealing, too.

I plan to use it for new public projects, and might even move my old ones over.

disallow list of known bad email providers.

Imagine giving someone your phone number, and having them say you have to get a different one because they don’t like some of the digits in it.

I have seen this nonsense more times than I care to remember. Please don’t build systems this way.

If you’re trying to do bot detection or the like, use a different approach. Blacklisting email addresses based on domain or any other pattern does a poor job of it and creates an awful user experience.

(And if it prevents people from using spam-fighting tools like forwarding services, then it’s directly user-hostile, and makes the world a worse place.)

Checking MX in your application means you needlessly fail on transient outages, like when a DNS server is rebooting or a net link hiccups. When it happens, the error flag your app puts on the user’s email address is likely to confuse or frustrate them, will definitely waste their time, and may drive them away and/or generate support calls.

Also, MX records are not required. Edit to clarify: So checking MX in your application means you fail 100% of the time on some perfectly valid email domains. Good luck to the users and support staff who have to troubleshoot that, because there’s nothing wrong with the email address or domain; the problem is your application doing something it should not.

Better to just hand the verification message off to your mail server, which knows how to handle these things. You can flag the address if your outgoing mail server refuses to accept it.

By the way, please don’t write regex to try to validate email addresses. Seriously.

Amen.

There are libraries for that; some of them are even good.

Spoiler alert: Few of them are good, and those few are so simple that you might as well not use a library.

The only way to correctly validate an email address is to send a message to it, and verify that it arrived.

The art style reminds me of Scavengers Reign.

he’s gone off the rails in the last 6-12 months - complaining about needing more linux devs

It’s also ironic in light of his history of loudly bashing linux and linux game development.

I can’t think of anything good to say about Tim Sweeney.

I might give Backpack Battles a try. It doesn’t look like my usual style, but I heard there’s some good strategy under the surface, and I like that it’s made with Godot.

Are there any 5.5 physical sourcebooks? Were they ever planned at all?

I haven’t been following One D&D news, but I got the impression they were focusing on a subscription-only model, so I’ve been planning to stick with my 5e books or switch to an ORC-licensed system.

how discouraging
should have used an asterisk
not a comic book

This is misleading. Matrix respects the e2ee setting that you choose when creating a room, and it’s enabled by default.

Whether to use encryption is a per-room setting, not per-server. It’s controlled by the person who creates the room, not the server admin. It’s on by default, and cannot be switched off later.

Rooms can be created without it because that makes sense for large public rooms, like those migrating from IRC, where privacy would defeat the purpose.

Keybase was popular with some Hacker News users for a while, but now that it’s owned by Zoom, anyone concerned about privacy ought to think twice before using it.

XMPP might be worth considering if you’re hosting for yourself and all your contacts. I suggest avoiding it for public use, mainly because features are piecemeal and coordinating them across everyone’s clients and servers is a bit complicated. (Also, I don’t know if there’s a good XEP for encrypted search.)

Back when encrypted search was being developed for the Electron app, I think someone had it working in a standalone browser as well. Perhaps that was with the help of a browser add-on; I don’t remember for sure. I suspect github.com/t3chguy would know, as he seems to be active in discussions of that feature. It might be worth asking him about it.

Does it have feature parity with Element yet?

Not yet. It’s in beta.

https://element.io/labs/element-x

EDIT: Nheko is NOT a mobile client.

If you specifically meant mobile, you could have said so. Your statement was, “every other client has even more drawbacks when it comes to E2EE.” Nheko disproves that statement. It also suggests that some alternative mobile clients might handle E2EE at least as well as it does. You might want to try them.

By the way, text search with end-to-end encryption happens to be tricky to implement, and Matrix projects aren’t funded by corporations with deep pockets. Tempering your expectations regarding development speed is probably worthwhile here.

Correcting some misconceptions…

Element for Android doesn’t support searching in encrypted channels

That’s true of regular Element for Android, but it’s being replaced with Element X (which is built with Rust). I would expect search to be added there if it isn’t already.

and I think you can’t use E2EE in the browser at all(?)

I have done it in Firefox, so that’s false. Perhaps you had trouble with a specific browser?

plus basically every other client has even more drawbacks when it comes to E2EE.

Nheko handles E2EE just fine, so that would seem to be false as well.

Since you’re looking for recommendations, it would help if you said which clients you tried and what problems you had with them.

In case you haven’t seen it, you can set a Features: E2EE filter on this list:
https://matrix.org/ecosystem/clients/

Not really an answer to your question, but just to make you aware of some options:

Have you considered using subkeys for each of your machines, signing things with those, and keeping their master key someplace safe? That would limit your exposure if one of those machines is compromised, since you could revoke only that machine’s key while the others remain useful (and the signatures they have issued remain valid).

Are you setting expiration dates on your keys? That can bring some peace of mind when you lose your key/revocation data.