He didn’t found it, he found it.

👍 the English language is great

It wasn’t a condition of his initial investment, but rather of a lawsuit settlement five years later, in 2009 (six years after Eberhard and Tarpenning actually founded it).

it isn’t wrong tho

which indirectly benefits US foreign policy

See the last part of my response to this article for one of the other ways it benefits the US.

It doesn’t seem like the Signal Foundation received US government funding

The article doesn’t say that Signal Foundation did, it says Signal did… which is well-documented in OTF’s annual reports among other places.

I agree that this article has lots of other problems, though; I describe more in my comment about it in another thread.

It isn’t expected that a quantum computer will be able to instantly break symmetric encryption, as is used in full disk encryption. It will give an enormous advantage (halving the number of bits of security) but attacking that will still require a large amount of time and energy. What a CRQC will very quickly break is the asymmetric primitives, as used in TLS, encrypted email and chats, etc.

On the other hand, using default parameters from not so long ago, it is cheaper than you might expect to brute-force your disk passphrase already today without a quantum computer… which is why you should use a stronger key derivation function (in addition to a strong passphrase, of course).

I really hope that there isn’t a cryptographically-relevant quantum computer built in our lifetimes, but we should still assume that there likely will be and accordingly should switch everything to use (hybrid) post-quantum cryptography ASAP.

Bluesky’s federation doesn’t exist yet. Maybe they’ve written some code, but I can’t self-host something that Bluesky users can follow.

You can run their code today and federate in their sandbox environment, but yeah, their “production network” still doesn’t federate yet. They said a while ago that the remaining work to be done was mostly around moderation; currently they say they expect to enable federation early next year but they have several other things on their pre-federation TODO now.

You can find details about their federation sandbox here and here.

From what I understand even in the federated mode all accounts have to be verified by a central server?

Not all, but currently most are. The long-term account identifiers are DIDs, and they currently support two DID methods: the w3c-standardized did:web method (which makes your identity reliant on your DNS name), and bluesky’s centralized did:plc method (which gives you a verifiable cryptographic identity not reliant on you keeping a domain renewed, but which they are responsible for the availability of and could censor).

The log of all operations on the centralized did:plc server is public and auditable, though, so, if i understand correctly, if/when they do censor it that can be detected and people can/will make the various components of the system use uncensored mirrors of it to continue using censored did:plc identities. And other people will choose to use did:web for their identities and be subject to the DNS rules instead (and this choice will be invisible to other users; all implementations are expected to support both methods).

In my opinion, the decoupling of long-term identity from everything else (including your display name, which is also DNS-based but can be changed at any time) is a pretty good idea, and I expect they’ll probably support more than these two DID methods in the future.

In ActivityPub, posts, comments, and users themselves are identified by URLs consisting of DNS names and small sequential IDs, with the same entity having a different ID at each instance it is federated to. For example, the comment I’m replying to is ID 6283426 on its home instance, and 5909380 on my instance, and 5405408 on the home instance of the community this thread is in.

In ATP (bluesky’s protocol) everything is identified by cryptographic hashes and digital signatures, while the DNS-based URL of a user’s current “personal data server” at the time they created a post is not part of the post’s identity.

The difference in data models is a major impediment to bridging the two protocols. If two different bridges convert the same post (or other entity) from either one of these protocols to the other, they will always be creating duplicates.

I’m not an expert on either protocol but it seems to me that the only way to bridge them in a way that works well would be for both protocols to be substantially modified for the specific purpose of interoperating with each other, and so far I haven’t seen any indication that either side is interested in doing that.

Which metadata? Please elaborate

• When you are online
• Where you are online from
• When you receive messages (and their size)
• When you send messages (and their size)
• Who you are communicating with (including individuals, and what groups you’re in).

Those last two are supposedly hidden by their “sealed sender” feature, but, that is a farce because you’re connecting to their servers from the same IP address to send and receive and you need to identify yourself (with your phone number) to receive your messages. So, the metadata-hiding property that “sealed sender” purports to provide cryptographically is actually relying on their (Amazon’s) network infrastructure not to correlate the information available to it.

Signal says that they don’t retain any of this metadata, and I think it is likely that Signal employees are sincere when they say that.

But if someone with the right access at Signal’s ISP (Amazon) wants the Signal metadata, they can get it, and if they can, then anybody who can coerce, compel, or otherwise compromise those people (or their computers) can get it too.

One can say that the adversaries they’re trying to protect against don’t have that kind of capability, but I think it isn’t reasonable to say that Signal’s no-logging policy (much less their “sealed sender” cryptographic feature) is protecting metadata without adding the caveat that routing all the traffic through Amazon does make the metadata of the protocol’s entire userbase available in a convenient single place for the kind of adversaries that do.

And if you’re completely confident that the adversaries you want to protect against are unable to compromise the server infrastructure, why would you need e2e encryption at all?

waaahh centralizing millions of slightly-privacy-aware people’s metadata on Amazon’s servers costs a lot of money, waaah