miloignis

Ah, thank you for pointing that out! I was wondering what it was.

True, and Matrix has the weaker version of the feature: https://spec.matrix.org/v1.16/client-server-api/#redactions It should absolutely work in normal situations across all servers and most all clients.

No, that's not true - the change was that you could only install software from verified developers, not only from the app store, and now they've partially walked that back too and "are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified." ( https://android-developers.googleblog.com/2025/11/android-de... )

You could buy ETFs and then short the stocks you don't like more, I suppose.

Perhaps I wasn't clear - I don't know enough to say if the job was good or bad just by inspecting it, I know the first job was bad because it didn't solve the problem, and then a more expensive contractor explained why, and did solve the problem.

Our issue was water intrusion along a side wall that was flowing under our hardwoods, warping them and causing them to smell. The first contractor replaced the floor and added in an outside drain.

The drain didn't work, and the water kept intruding and the floor started to warp again.

When we got multiple highly rated contractors out, all of them explained that the drain wasn't installed correctly, that a passive drain couldn't prevent the problem at that location, and that the solution was to either add an actively pumped drain or replace the lower part of the wall with something waterproof. We ended up replacing that part of the wall, and that has fixed the issue along that wall. (We now have water intrusion somewhere else, sigh).

If anything, I was originally biased for the cowboy, as they came recommended, he and his workers were nice, and the other options seemed too expensive & drastic. Now I've learned my lesson, at least about these types of trickier housing issues.

Also, no one mentioned evaluating someone by how they're dressed - the issue was family/friend recommendations vs online reviews, and I while I do take recommendations from friends and family into account, I've actually had better luck trusting online (local) reviews.

When we needed some work done, we asked family and friends too, and ended up with a cowboy. When the work needed to be re-done, we looked up local reviews for contractors, and ended up with someone who was more expensive but also much more competent, and the work was done to a higher standard.

Sorry, I should have been more concise - the two big differences are:

1) everyone gets the same code

2) it doesn't change too quickly

This means you can (esp with reproducible builds) audit that the code is correct and know that everyone is getting the correct code, and that misbehavior will be identified.

For me, the key problem being solved here is to have reasonably trustworthy web implementations of end-to-end-encrypted (E2EE) messaging.

The classic problem with E2EE messaging on the web is that the point of E2EE is that you don't have to trust the server not to read your messages, but if you're using a web client you have to trust the server to serve you JS that won't just send the plain text of your messages to the admin.

The properties of the web really exacerbate this problem, as you can serve every visitor to your site a different version of the app based on their IP, geolocation, tracking cookies, whatever. (Whereas with a mobile app everyone gets the same version you submitted to the app store).

With this proposed system, we could actually have really trustworthy E2EE messaging apps on the web, which would be huge.

(BTW, I do think E2EE web apps still have their place currently, if you trust the server to not be malicious (say, you or a trusted friend runs it), and you're protecting from accidental disclosure)

Very cool - played around with it, and it seems quite featured, and my test podcast worked!

I really appreciate the local-first, self-contained but very portable architecture, with an optional server connection to handle CORS and index and whatnot; that's a really solid approach.

Hopefully this isn't too annoying, but I saw you open-sourced what looks like the backend, do you have any plans/interest to open-source the front end as well, for people who might want to self-host?

From the docs, to get around CORS: https://docs.wherever.audio/blocking.html#proxied-requests-f...

I believe they are or will be transitioning to Swift: https://x.com/awesomekling/status/1822236888188498031

I highly recommend GrapheneOS - it really is Android as it should be. More secure, more open, no ads or tracking.

If you use those apps. All of the apps I use, including my banking app, work fine on GrapheneOS.

Agreed, more or less, but I would argue you could make a distinction for a "streaming" situation where say no more than 10% of the data is on your computer at any one point in time, vs "downloading" where the data exists in its entirety at once.

You could encode these terms in a contract or something about allowed usage of a service, I believe.

Presumably you don't have WebGL enabled or supported - the main page is just a cute 3D landing page.

You may be interested in https://github.com/vortex-data/vortex which of course has an overview and links to their docs and benchmark pages.

Not that I imagine most people would change it, but notably ntfy means that notifications don't have to go through centralized services. (As you can set what ntfy URL you want to use, including to your own server)

This feels more like a proposal for whatever emoji-picker you're using than for Unicode - I don't use most of the scripts defined by Unicode, and I don't use most of the emoji either. No one is forcing me to use every Unicode codepoint.

Them being defined is only a benefit to me if I do happen to need to use them, say to copy-paste Sanskrit to translate it, or if I want to make a joke about bigfoot with an emoji punchline.

I mentioned this yesterday on the Google only allowing verified developers story, but my banking app works fine on GrapheneOS, as do many others. There is a crowd sourced list of their status here: https://privsec.dev/posts/android/banking-applications-compa...

What does high-end mean to you/what specs do you find to be too low? I've found them plenty powerful for a dev machine.

Another consideration that has really come true for me is repairs - I accidentally spilled a bottle of gin over my framework and was able to only replace the main board for under half the cost of a brand new machine.

I'm very happy with my framework!

My banking app works fine on GrapheneOS. There is a crowd-sourced list here with current status for many of them: https://privsec.dev/posts/android/banking-applications-compa...

GrapheneOS + F-Droid is a joy to use, for me. I'm kinda shocked when I use anyone else's phone, now.

If they start selling their own devices, I will buy one and (assuming it turns out how I hope it will) recommend it strongly.

Notably, tab completion is an explicltly called-out exception to this policy, as detailed in the changed docs.

Thanks for checking! Incognito blocks me too, no idea whats up. Maybe I'm getting tripped up by IP reputation or something (though I shouldn't, normal residential connection).

It also instantly blocks me on GrapheneOS, both Firefox and Vanadium. Very odd, as I've never had an issue with Anubis before.

Your Phoronix link shows clang as faster than GCC (more is better on the graph). The benchmark game results seem to go back and forth.

I don't think that it's convincing evidence that clang is slower than GCC.

For Firefox, I can normally click Advanced -> Accept Risk and Continue, which I think is about the perfect amount of friction.

I'll chip in with another datapoint that a seriously ergonomic keyboard helped me as well - in my case, the glove80. Expensive, and there might be a better option on the Pareto curve, but I got freaked out, bought the most ergonomic keyboard I could find, and it did solve my problem.

I've heard good things about voice typing with Talon too, but never tried it.

Maybe, I do think it really depends on the type of software/situation.

In an argument about how much someone is able to use something, I think you could argue that a copyleft license turns more people away than it would force to participate, so the overall amount of work that is freely available is less than it would have been with a permissive license. (That is, if 10% using a permissive license don't contribute back and 90% do, you end up with more contributions than if 100% of users contribute back to copyleft but you only have 50% as many users.)

I do think it's very situational though - clearly Linux being GPL has been a huge boon in forcing contributions, and I think the killer bit here is that forcing those contributions means that people are able to use their hardware that might otherwise only run proprietary operating systems. That is, it's the forcing open of something that hardware companies would otherwise keep closed.

On the other hand, I don't see any huge reason why a good regex library, for instance, shouldn't be permissive - making a regex library copyleft isn't going to force open some proprietary software, they'll just use some other (maybe worse, maybe equivalent) regex library, and you might get fewer overall contributions and end up with a worse overall available library.

I looked up the spec, and it seems like they just tiebreak on time and hash and throw away the losing commit:

https://github.com/nostr-protocol/nips/blob/001c516f72943081...