Twitter: You're at the whims of a billionaire.
Threads: You're a data machine cog, but the billionaire doesn't care about you specifically.
Mastodon: You're either at the whims of your server admin, or you can't find anything.
Bluesky: Eventual whimmunity, can find stuff, but _everything_ is public.

But it’s not two-way!

If A blocks B in ATP, this *didn’t prevent B from seeing A’s posts *.

All it means, afaict, is “A is announcing they will not observe any of B’s content.”

Even that may not be true!

That’s one of the key reasons I’m concerned about user expectations.

So an ATP “block” Is completely different than a Twitter “block”.

I am tempted to call the former something different like “admonition”, “reprimand”, “censure” because those sounds closer: public announcements about the blockee.

If you're an open source ai product person or a hacker, please build this for me:

An AI that quickly finds the original source alluded to in any news/social post.

Broken link

I'll bet efficiency on ARM is more important for wide adoption of a secure hash function than efficiency on recent Intel/AMD laptop/server machines, because everything is a lot slower on (most) ARMs, and the use cases sometimes come with hard performance requirements.

On http://bench.cr.yp.to/results-hash.html#aarch64-pi4b, BLAKE3 is one of the most efficient secure hash functions, but in reality BLAKE3 is much *more* efficient than shown there, because it uses ARM NEON (which is not shown in that benchmark) and because of the new BLAKE3 v1.4.1 speedups.

If you benchmark the new BLAKE3 v1.4.1, especially if it is against your particular use cases, let us know what you see!

On http://bench.cr.yp.to/results-hash.html#aarch64-pi4b, BLAKE3 is one of the most efficient secure hash functions, but in reality BLAKE3 is much *more* efficient than shown there, because it uses ARM NEON (which is not shown in that benchmark) and because of the new BLAKE3 v1.4.1 speedups.

Awesome that you are offering to contribute. Tbh i don't, but I'm not much involved with maintenance of crypto libs anymore.

I'll bet efficiency on ARM is more important for wide adoption of a secure hash function than efficiency on recent Intel/AMD laptop/server machines, because everything is a lot slower on (most) ARMs, and the use cases sometimes come with hard performance requirements.

Kudos to the Zebra team, the NCC team, and also kudos to the Zcash Foundation for funding this security assessment — that must have been expensive!

🔚

I also like how the long, arduous process of writing an independent implementation of the Zcash protocol and getting a team of experts to scrutinize it also gives me more assurance that there aren't vulns lurking in the math or the original implementation — zcashd.

⤵️

The content is really encouraging. It looks like the Zebra engineers have done good high-quality work, and that the NCC reviewers scrutinized it pretty carefully. I especially like how all of the findings were addressed by Zebra (or, in one or two cases, by my team at ECC). Quality takes care!

⤵️

I noticed that one of the NCC Group reviewers was Thomas Pornin, whose work in cryptography and cryptography engineering i know of as good work.

⤵️

I like that they call it a security "assessment" rather than a security "audit". The word "audit" suggests that it is pass/fail, and a lot of people treat security audit like that, but they really shouldn't, so "assessment" is a better word for this.

⤵️