Hacker News new | past | comments | ask | show | jobs | submit | turblety's comments login

I really hope this fixed a bunch of encryption and key issues.

We ran Element for our dev team for 6 months and had to give up because frequently a person would just not be able to decrypt a message, warnings would appear but there was no way to solve this. So literally people where missing messages and just having to ask people to post the message again (because there was no way to request the keys be sent). It was a complete disaster and only got worse over the 6 months.

The notifications icon was a mess too. You would frequently see the "unread messages" indicator for a message that was in a thread sub conversation somewhere, even though all the messages had been read. So again people were missing messages.

Despite numerous people begging for threads to be disabled while Element fixed the bug, they refused to put that option in.

In the end, we had to give up and just move to Slack. I really want Element/Matrix to work. I feel like we need it to work, but the lack of support and understanding from the development team would make be warn people to not use this in a professional/day job environment.

That being said, I'll defo be trying it out again personally with the hope they've listened to the community and fix these important bugs.


We have done a huge amount of work on fixing E2EE issues - when running latest matrix-rust-sdk clients (e.g. Element X) and matrix-js-sdk using matrix-rust-sdk-crypto (e.g. Element Web/Desktop), "unable to decrypt" bugs should be unheard of.

So, the point of this blog post is to try to spell out that we've fixed this.

Meanwhile if you see ANY unable to decrypt errors, PLEASE submit debug logs on both the sender & receiver, and we will jump on it aggressively.

In terms of threads: yes, the stuck unread notification bug(s) were a disaster, but also fixed last year. Behind the scenes, 2023 was an absolutely awful year for Matrix & Element along many axes, c.f: https://matrix.org/blog/2023/12/25/the-matrix-holiday-update.... Sorry that you got caught in the disruption.


btw, there should be a great talk The Matrix Conference tomorrow about this: https://cfp.matrix.org/matrixconf2024/talk/8BVVT3/

See also https://cfp.matrix.org/matrixconf2024/schedule/ for all the other Matrix stuff happening over the next 2 days :)


I have had similar experiences, but not on professional context. Random E2EE key issues (not often) that maybe sometimes resolve themselves or with some additional action like bringing all clients online. Matrix is still the best choice for me, though, and I expect it to improve like it has over the years.

Last time I tried the threads-feature (with Element) maybe a year ago, it was still in beta.

Anyhow, if you're ok with Slack, then you probably could have just not use E2EE at all and avoid issues related to that?


i havent seen any encryption issues since about q3 2023, notifications are still a thing tho, they are reliable but setting them up the way you want is still a pain

my experience is based on regular old element clients and my own server and will be moving to x and sliding sync probably at the end of the year


I presume solar power?

No, way too little sun out here. The sun is just a dot far away. The Voyagers both use RTGs, radioisotope thermoelectric generators. Decaying plutonium, essentially. That's for the electrically powered systems. The thrusters use liquid hydrazine, which is common for those kind of thrusters.

Edit: There's more about that in the NASA link in a sibling comment.


Solar has nothing to do with it. Voyager uses hydrazine, of which over 80% has been used up over the years. They simply use not that much of it as it's not for thrust, but for aiming at Earth more or less.

Even with something like an ion engine (which I'm not sure were available when Voyager was launched), you would need leftover reaction mass.

Lol. How would that work exactly?

> How would that work exactly?

Light sails. Laser propulsion. Photon rockets. None of which apply to Voyager. But none of which are laughably dismissible.


I just installed it on Chrome, and it hasn't worked on a single site, but upvoting as I love the idea as horrible as the whole consent banner thing is :(

For example bing.com, britishairways.com all show their consent popup. It does try and do that minimize thing, as something flashes to the bottom right. But the model still appears in the same place as always.


I've been using this on mobile for a couple of years now, I've noticed it failing in the way you mention quite often in the last 3 months or so. I'm not sure how maintained the rules are, they might need updating. Previously it was working nicely, although probably only on 40% or so of pages. I've also used ublock to block cookie consent popups, which catches more but occasionally has to be disabled as sometimes it will break scrolling or interaction with the page.

Really nice! I made a small cli tool that has an extra step of basically printing out a tree, so you can ask the ai what files you want to output:

https://github.com/markwylde/ai-toolkit


The real tragedy is the proprietary bootcode.bin gpu code that is a blackbox and we don't have the source code for.

How horrible that a tinkering/hobbies project has to have these hidden secret blackboxes that can't be modified.


> The real tragedy is the proprietary bootcode.bin gpu code that is a blackbox and we don't have the source code for.

The Pi firmware is ThreadX, later bought by Microsoft and renamed Azure RTOS.

It is now FOSS.

https://www.theregister.com/2023/11/28/microsoft_opens_sourc...

That does not mean the whole Pi firmware is automatically FOSS -- drivers are not -- but they could if they wanted.


I'm guessing that having the source of the bootcode available would allow for extreme tinkering to the point that RPI can no longer guarantee it functioning properly? Or maybe it has something to do with proprietary drivers loading? Curious as well what's in there that they need to keep it closed source.


Well, you can already do extreme tinkering to the point that RPi can no longer guarantee it functioning properly :)

IIRC it's just that the bootcode.bin file is provided by Broadcom, and not the RPi foundation, so they can't open source it because they don't have the license to do so (this isn't the only proprietary blob in the default Pi distribution, but most of the other ones have open source alternatives/aren't that necessary/are open source now that they use the RP1 chip instead of broadcom peripherals).

There's similar, slightly more open arrangements, with the Pi Pico W, where they can't provide the firmware for the Wifi chip, but they can provide a library to interface with it, with the caveat that the license _only_ allows for that library to be used with the RP* family of microcontrollers [1]

[1]: https://github.com/georgerobotics/cyw43-driver/blob/faf36381...


Other than broadcom licensing, I can guess that there's a warranty issue because the firmware controls the voltage.


You can kill Pi with a thousand ways. I don’t really understand how could a warranty work outside of obvious cases…


The firmware is in control of the clocks, and in case too high of a clock is specified in config.txt it burns a 'warranty void' fuse.


Thanks for the recommendation. I've just given it a try and it looks great. I had tried coolify.io before, but the multi node/swarm support wasn't great, and the registry didn't work. Dokploy seemed to work straight out of the box.

One thing I wish it had to preview deployments though. Coolify had that. But I can live without it.


The experience is awful if you don't want any of the Python stuff.


so you never install any language and tool other than that of js? That's not a realistic expectation in modern software development imo. Just accept it and use the best tool for the job. jupyter is for playing around anyway so the fact that you don't have to think about how it affects production makes it not as complicated as it sounds.

You don't need to use the web client, all IDEs have jupyter integration these days, Zed even has it built-in. Just one "pip install" away.


Really cool. Your demo would have been even better if you add contenteditable on there so the user can edit and see how it works:

<pre contenteditable="plaintext-only" class=""><code>...


I guess you missed the playground part?


I'm constantly dumping several files from my project into chat ai's, so made this simple cli tool that can dump the file tree, print all file contents or get the typescipts definitions for all files.

It works best on small/single responsibility projects.


I think the closest you might get is something like the bittorrent dht. There are still bootstrap servers for the first few connections, but there's really no getting away from that, right?

https://github.com/webtorrent/bittorrent-dht


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: