Thanks for your suggestion. I tried peek.nvim and found some cons:
- It required Deno runtime
- It does not support Table of Contents
- It does not have Dark/Bright mode button
- It does not support PlantUML
- It does not support term definition
- It does not support Sequence Diagrams
- It does not support Flowcharts
- It does not support Graphvis Dot
- It does not support Charts
- It does not support local images
> what they do, or what dot file managers they use, but there's something to be said for building a workflow that works for you
Like consuming time. If there is a tool which does what you need like chezmoi then you should use it, so that you don't have to spend maintaining something bespoke which consumes your time that could be better spent on other things.
Stupid argument. With this logic, nothing new is ever explored, nothing is learned, no insights gained, or shared. This logic even questions the need for chezmoi - stow existed for decades before chezmoi. You think chezmoi sprang into existence with all its features? High chance it was someone's toy project because they didn't want to use stow.
stow's approach of using symlinks is extremely limiting. For example, it means you can't have templates (for small machine-to-machine differences and secrets) or encrypted files. chezmoi does have a symlink mode, like stow, but using symlinks has multiple downsides: https://www.chezmoi.io/user-guide/frequently-asked-questions...
chezmoi was actually inspired by Puppet, not stow.
Yup, I tried a number of dotfile managers. I think yadm was the first one I started with and then ended up with chezmoi.
The main reason was because I discovered the power of templating. With Yadm it required an external dependency, envptl, then j2cli, and both of these became unmaintained, while chezmoi used the text/template standard library. After the task of converting my jinja2 templates to gotmpl I never looked back.
One of the other things I like about chezmoi is I significantly cut down any "scripts" to just a few as most of the logic became "deterministic", ie I would set conditions based on the host in chezmoi.toml.tmpl and then that would define how everything under that would run across multiple hosts, and devices.
To be honest after reading that, I only come to the conclusion they're a bit antisocial.
> I'm not interested in collaborating, I like to work alone. Or with people I hire. If I hire people I find you, you don't need to message me.
How would you even know that if you never can be contacted?
> I'm not interested in fixing your printer or WiFi router.
I don't believe I've ever received an email with something like that as the subject. My email is pretty public and in some fairly prominent places.
> Unless it's Indiehackers or a podcast I listen to myself like Joe Rogan.
> Talk is cheap and ineffective while creating something is much more challenging and effective to make change in the world.
More elitism. It just reeks of "I am so good I don't need anyone else".
> Spending time with people that spark my curiosity.
How are you ever going to know that if you're totally unreachable. What I've learned in life is sometimes friends can be found in the most unlikely of places.
> I'm on Twitter too if you'd like to follow more of my stories
Like why, I understand having a blog but these days I cannot see any good reason to be on Twitter.
I always find these comments hilarious, because at some point Windows 10 will no longer have any security support. It certainly won't come as OEM with new hardware.
This is not a big deal. Most laptops have TPM 2.0, and most motherboards can have a dTPM accessory if they don't have it onboard.
Windows 11, has a lot of useful things, which 10 did not, for example DoH in the system resolver and a variety of other security benefits.
It's literally like people complaining if Windows doesn't work on old-BIOS only computers, it's not going to make much difference as nobody has those. If they do have those then a cut down Linux OS makes more sense as those devices likely won't have much RAM either to run a modern browser etc.
They will always need to strengthen requirements to strengthen security. In the past Microsoft has too heavily aimed for compatibility at the cost of security. This was pretty much their thing in the Windows XP days and everyone laughed at all the ways they screwed up.
There seems to be a clear focus on attestation and preventing persistent malware from taking root in a system's boot chain and potentially firmware.
> because at some point Windows 10 will no longer have any security support.
Just FYI, Windows never had any security "support". The fact that Microsoft releases some security patches, is just a fact. With Windows you, as an individual, were always on your own regarding security.
While that's certainly the plan, Matrix is still not at the "can't use it wrong" stage Signal has gotten to. Verifying multiple devices is still inconsistent and often requires multiple tries (may be an issue with the matrix.org server, dunno) and "Unable to decrypt" errors are still somewhat a common sight.
It has gotten much better in recent times, but not quite there just yet.
I have criticized omemo in the past -- it breaks backwards compatibility way too readily resulting in XMPP clients not being able to talk to each other in levels that I hadn't seen since the Jingle debacles. However I just can't stand this article's tone (the accompanying imagery doesn't help), and then he has the balls to complain about the rude response he gets from the spec authors (even showing it off as if to elicit empathy from the reader), when if anything my impression is that his article itself is way more disrespectful.
He keeps criticizing one client while trying to pass it off as criticism of the specification (said client doesn't even implement the latest version of the specification, either), complains about the protocol changing too much and the protocol changing too little, and to top it off seems to promote Signal as the better alternative, completely missing the elephant in the room -- Signal being centralized with its decisions even more whimsical at the hands of one group only. Curiously, he does that right after criticizing omemo's choice to follow Signal's choices as lacking justification.
This sort of rant is unfortunately fairly common in the world of cryptography. Things can be mostly driven by what the writer feels about other people working in the same space. So they attack their technology as a way to attack them.
Note that the author of the linked article complains about getting the same sort of article in reply. That is also common...
The main reason we won't list it on privacyguides.org is the encryption is not always on by default.
There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation.
One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer.
If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc.
There is a fair bit of metadata on the server side
What does STARTTLS have to do with a MITM attack based on certificate substitution? What XMPP servers still allow unencrypted client connections by default?
> the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that.
> There is a fair bit of metadata on the server side
This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment.
> Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
> This is much less critical when the protocol is federated
False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix.
The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
> Routing data between servers and networks you literally control
This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting.
TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population.
> Leaking metadata to a centralized service is simply inevitable by pure physics
https://simplex.chat/ has lesser metadata than Signal[1][2], Matrix and XMPP. SimpleX Chat is going to move to Groups V2[3] very soon to make the experience much better.
XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points?
Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels.
There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
Yes it does, because the threat model there is not the server itself. You trust that as it's your employer's server and you're using it for work related purposes.
> Timing alone is enough to clearly distinguish a sender
It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
> You trust that as it's your employer's server and you're using it for work related purposes.
Yes, that is the point. Or it is my home server sitting at my router serving my family. I have been arguing that if I can trust the server then the discussion about E2EE becomes less relevant.
> It's a lot harder to pull off than doing an MiTM attack with STARTTLS and then just observing the person's roster being sent to them when they connect lol.
And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
> Or it is my home server sitting at my router serving my family.
That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet.
For a lot of people it wouldn't even be possible if they wanted to and that's not getting into the technical investment they would have to make in knowing how to do such a thing in the first place.
> And here you make the dangerous mistake that I most hate. It's not only trivially easy for the server operator to leak metadata, it's actually HARD to avoid it.
It's a lot easier than simply not having that data server side in the first place like Signal for example.
> That works in your situation, but not for most people who don't want to have to maintain a moving part. Also hosting in general on a residential connection can depend on the provider and even availability of good internet.
Frankly, that works for the majority of XMPP users -- let's not forget about that. But yes, this is a problem today for many consumers. However, I see this as a much better direction for the Internet as a whole to take -- see efforts such as ownCloud and the like -- , rather than just conceding defeat and accepting a centralized Internet, or worse: the extremely dangerous idea that centralization increases security. Which should only be seen as the non-sense it is.
> It's a lot easier than simply not having that data server side in the first place like Signal for example.
You still do not get the point here at all. This is not about storage. This is not about the server implementation. As long as there is a communication at all between me and the server and then my contacts and the server, it is irrelevant if you are storing the roster or not. ANYONE (*anyone with access to that server) can easily pick it up. In fact, it is HARD not to leak it up, even by accident. Barring a P2P Freenet-like thing, this is _unavoidable_. (and even with P2P/Freenet/Onion/whatever it's not trivial) And due to the nature of IMs, metadata is practically as big an issue than protecting the payload itself.
> conceding defeat and accepting a centralized Internet
I think you can still have decentralization without having to be a sysop. That may be server operators that run small servers etc.
Decentralization doesn't inherently mean privacy though and it's important to remember that.
> You still do not get the point here at all. This is not about storage
Pretty sure signal servers can't intercept messages or decrypt them. In regard to the client you cannot send unencrypted messages. We do know that lawful interception warrants sent to Signal are not particularly effective only registration time and last connection time is available. https://signal.org/bigbrother/
> Pretty sure signal servers can't intercept messages or decrypt them. In regard to the client you cannot send unencrypted messages. We do know that lawful interception warrants sent to Signal are not particularly effective only registration time and last connection time is available. https://signal.org/bigbrother/
Please, I'm really trying to put the emphasis on metadata, and definitely Signal servers can intercept that at will. Even here on HN there was recently an article of how "lawful interception warrants" were targeting Apple's and Google's _push notification servers_ (those _by design_ really only have access to metadata -- that should speak about how important metadata is for law enforcement). The Signal server has access to significantly more metadata about you and your communications than your typical push server. Again, there's just no contest here: simply avoiding the issue of using their server in the first place is much better than anything they claim* to do (or even better than anything they could _physically_ do).
* I absolutely detest these type of "our privacy is great, believe us!" pages. Time and time again it shown that they are absolutely useless. Where did Apple report that their push notification servers were tapped?
The fact that a server collects enough data about you that it is a tempting target for authorities should be cause for concern, not relief.
> Apple's and Google's _push notification servers_
This never effected signal as no data that is sensitive was ever sent via that. Again though warrants against Signal are not new, and for years law enforcement has been getting the same answers to their subpoenas. If it was "possible" as you say and that "they do", pretty sure the ACLU would not be making submissions to a court that "this is all that is available <registration date> & <connection date>" especially as the source code is open, it would be easy to verify if that was in fact true.
> I absolutely detest these type of "our privacy is great, believe us!" pages
The page literally has the legal request and reply, these would be able to be checked against court records. Remember being in contempt of a court order is actually punishable, so if there was more I'm sure Signal would have been fined by now lol.
> This never effected signal as no data that is sensitive was ever sent via that.
How are you still missing the point that this is _about metadata_? No one is sending "sensitive data" through a push notification in the first place. You have to go out of your way to do that. My point was to show you that the authorities _are_ after metadata.
With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
* Conversations uses two different OpenPGP implementations. (It doesn’t)
* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely
* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)
* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
> * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.
Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.
"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.
Combine that with https://asdf-vm.com for the deno runtime.