I attempted to handle some of what you're suggesting via the plugin ecosystem utilizing a vector database for RAG, and LLMs to auto-suggest tags or related docs. None of the plugins seem to get this quite right. The extensions were pretty brittle, and limited in terms of what they could do with the open doc. I now do most of my new note creation/editing and organization through cursor and custom built agent flows. The obsidian app is now just for mobile access and sync.
Cursor is better suited for enterprise. You get centralized stats and configuration management. Managers are pushed for AI uptake, productivity and quality metrics. Cursor provides them.
Agree. Also testosterone. I was lucky enough to have lab work before and after getting covid twice. My T numbers halved in less than a year. I was still within the “normal range” so it took some arguing with the doctors to get a prescription for a very low dose. Within 24 hours of starting, I felt like myself again. Brain fog was gone, energy was back, my mood rebounded. No negative side effects thus far. I had tried a lot prior to starting: intense therapy, ketamine, lots of exercise, losing weight, supplementation, lots of lab work. Nothing was as impactful as getting that jab.
Side note: the normal range for T is so wide that it’s meaningless.
> A significant proportion of male COVID-19 patients also display persistent low testosterone levels, reminiscent of absent or aberrant GnRH production, and SARS-CoV-2 has been shown to invade the brain. Taken together, these findings raise the possibility that in such patients, the GnRH system may be infected or dysfunctional, leading to the accelerated aging and cognitive deficits observed in patients with “long-COVID” or post-COVID syndrome. However, in what way and for how long GnRH neurons or their function may be affected in COVID-19 patients is still unknown.
This piques my interest because when I first started noticing these symptoms that's actually the first thing I thought of. I'm in my mid 30s and I've heard that's around when T starts to drop off. Probably worth mentioning this to my doctor eh?
Doesn’t hurt. Be prepared for resistance though. The steroid taboo means there are very few doctors in the US that are both experienced and comfortable prescribing.
I saw massive results at 1ml per month, try pitching that. The dose is so low it rules out abuse and lowers the possibility of side effects.
F1 isn’t even about max performance, it’s about trying to maintain an element of driver skill as a factor of outcomes. It’s why they outlawed the Williams continuously variable transmission (CVT). A lot in F1 is done to maintain the suspense/excitement of a race for the TV audience.
This is sort of highlighted by other comments, but GC is only good at small quick requests. If you're dealing with large or slow requests it results in large or long lived allocations which causes havoc with GC. This is true for any generational GC, Java included.
Also node will only perform well if that IO is offloaded to the kernel or CPP code and behind a future via epoll etc... If it's in the actual node runtime it'll perform poorly because it'll block the thread.
I call B.S.. He's conflating two things. One is a deployment infrastructure, another is an application pattern. I can deploy a monolith in k8s and I can deploy micro-services on a single server or a fleet of on-prem servers using any of the legacy dev-ops deployment automation tools. Sure k8s makes doing micro-services easier because it’s got a lot of the raw building blocks necessary to handle the CD process but in no way are the two concepts related. They’re tackling different problems. He's making the same mistake that he's criticizing others for by equating the two. What he is really describing is an organization doing a “big bang” refactor with poor planning and execution.
I was an engineer at PGP from 2004-2011 and ended up running the server team as lead engineer. I wouldn't disagree with most of the points brought up by the author, both the code base and standard has accreted over time and it's incredibly complex. There were only a couple of people on the team that really understood all the facets of either the OpenPGP or SMIME/x509 standards. It's made worse in that it was a hack on top of another system that had accreted over time (email) and that system was never intended to be secure. We had massive database of malformed or non-compliant emails from every email client since the beginning of time. The sub-packets that the author mentions were primarily used for dealing with forwarded chains of encrypted email messages where each previous message had it's own embedded mime-encoded encrypted/signed messages and attachments.
The problem is that no-one else has gone through the process of establishing a community/standard that's capable of replacing it. Each system has built their own inoperable walled garden that doesn't work with anyone else, and none of them have a user base large enough to make encryption easy and pervasive.
My own secret hope is that Apple is forced to open iMessage as a part of an anti-trust action and that acts as a catalyst for interoperability.
Forcing iMessage to open will immediately result in MITM iMessage proxies that users can use to store iMessages that are meant to auto-delete, so that they can violate the wishes of the other party. These do not exist today because Apple binds iMessage to your hardware and bans your entire device when anyone is found to be operating such a service, either for themselves or others.
Do you want open source clients that can be altered to ignore all privacy criteria — or do you want closed-source clients that make a good faith effort to adhere to auto-deletion protocols?
You can violate the wishes of the other party by taking a screenshot or, in the extreme, a photo of the screen. You're only preventing the very lazy/unmotivated from retaining messages.
Correct, screenshots are a viable attack against both closed and open source platforms. Preventing casual retention is the best you can hope for, and is a worthy goal regardless that it does not result in the perfection of a Faraday cage’d clean room
So, your threat model includes MITM servers, but not cameras? It seems a little silly to worry about the MITM problem when you can simply snap a photo already.
They are both valid threat models, but ones which for me have different meanings.
Screenshotting or photographing the screen of a device owned my my intended message recipient is a reasonably small problem to me. If my recipient wants to expose a message I've sent them, they're going to be able to do that. I never expected any more privacy for that message than I'd have accepted based on my trust in that person.
MITM servers are a whole other thing. Large scale surveillance of all users of a specific server, "full take" collection and searchable databases of messages available effectively forever to unknown current and future opponents?
Different threats. Yeah, I'm happy enough to accept the risk of cameras in the hands of my correspondents. Way happier than I'd be with MITMable servers (or services that can add "ghost users" as the UK seems to be proposing).
I might be missing something, but how would large scale surveillance with searchable databases be possible with e2e encryption? They could save the messages, but they would still be encrypted.
If you have to get into a legal battle with someone about misuse of information, it's much better that you are able to focus on the sender and the recipient of the information as potential sources for that information instead of also having to go after every potential network hop as well.
For me, the two choices in settings are "after two minutes" and "never", nothing in between. As you said, this is not a security setting, it's a storage space-saving setting.
This is unrelated to the current discussion and not meant to contradict your "Your point is moot", but instead just as a hopefully useful anecdote: In my experience, this requires the sender to choose 'Keep' too. I have been bitten several times by me sending an audio message to my wife because I was in a situation in which typing was complicated for me (outdoors, plenty of sunshine, I don't have the best eyesight), only to find that she never even got to see it because it got self-deleted after a few minutes.
My conjecture from looking at how this has worked for me is that the sender must choose 'Keep' so that the audio message stays on the receiver's phone until listened, and the recipient must choose 'Keep' so that the audio message stays on their phone after listening.
I, of course, have no proof of this other than my own experience on devices a few years old (iphones 5 and 6).
I also had some odd occurrences like this, and I simply stopped using voice messages over iMessage. It hasn't really penetrated the local phone culture so to speak, so it isn't a problem. Those that I do use it with happen to be on WhatsApp, which retains messages forever or something.
> The sub-packets that the author mentions were primarily used for dealing with forwarded chains of encrypted email messages where each previous message had it's own embedded mime-encoded encrypted/signed messages and attachments.
If you ("you" here being the PGP team) knew going into the design that the use-case of ASCII-armored-binary (.asc) documents is specifically transmitting them in a MIME envelope... then, instead of making .asc into its own hierarchical container format, why didn't you just use MIME, which is already a hierarchical document container format?
I.e., if you're holding some plaintext and some ASCII-armored-binary ciphertext, why not just make those into the "parts" of a mime/multipart container, and send that as the email?
Then all the work of decoding—or encoding—this document hierarchy would be the job of the email client. The SMIME plugin would only have to know how to parse or generate the leaf-node documents that go into the MIME envelope (and require of the email client an API for retrieving MIME parts that the SMIME parts make reference to.)
And you'd also get the advantage of email clients showing "useful" default representations for PGPed messages, when the SMIME extension isn't installed.
• Message signature parts would just be dropped by clients that don't recognize them. (Which is fine; by not having SMIME installed, you're opting out of validating the message, so you don't need to know that it was signed.)
• Encrypted parts would also be dropped, enabling you to send an "explanation" part as a plaintext of the same MIME type to the "inner" type of the encrypted part, explaining that the content of the message is encrypted.
I guess this wouldn't have worked with mailing lists, and other things completely ignorant of MIME itself? But it would have been fine for pretty much all regular use of SMIME.
I can't see that happening: There are multiple other messaging apps that are clearly successful and popular on iOS and macOS, and neither iOS nor macOS are the majority OS.
Using our library you can generate PGP keys using any key derivation mechanism for a large variety of key types! When using it right, this will greatly improve how you can generate and back up your keys!
