"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"

(and it's mostly "don't deploy your own", if you want to experiment that's fine)

This is true both for GPG and S/MIME

Email encryption self-compromises itself in a way Signal doesn't

Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.

Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.

> You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?

How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.

GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.

Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.

You technically can sign with age, but otherwise there's minisign and the SSH spec signing function

Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.

You want special purpose tools. Signal for communication, Age for safer file encryption, etc.

What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself? Age has yubikey support and can do all you described.

> if your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.

This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.

Downgrade protection, malleability protection, sidechannel protection, disambiguation, context binding, etc...

You want software to be implemented by experts using known best practices with good algorithms and audited by other experts.

They absolutely must define a much stricter mode that actually means something, and distinguish it from what they have now (which is essentially prototype level in terms of security model)

Since USB Armory supports pinning multiple keys for secure boot (and IIRC protected storage), you could even deliver it set up with a manufacturer attestation key and allow the user to load and pin their own attestation key (useful for an organization like a news company) as well as allowing "dual boot" between the attested firmware signed by the pinned manufacturer key and the user's own firmware. I've wanted that kind of behavior in consumer hardware for a long time, where you have full freedom between using the locked down OEM environment or your own and switching between them freely.

(I assume the USB Armory might also not be ideal in terms of ability to sleep and boot speed, etc, but if you have a quicker smaller controller that's the main board then it could wake the one that supplies attestation and make that functionality available after it's done booting)

There's already third party clients, account hosting servers, etc, as well as different apps building on the same system (and which can use the same accounts and data store!) like blogs and more. Most devs are trying to coordinate their custom extensions so it doesn't cause conflict.

If it weren't coordinated we'd easily end up in the same place as Mastodon with their spurious server blocks where large parts of conversations are broken for most users.

The platform can not be called better, with more bugs and errors than ever.

Why don't they apply those rules to Republicans? Why can they specifically post stuff like private info about Hunter?

And instead of censoring "secretly" in partnership with the US government they do so in partnership with the Indian government as well as individual Republican politicians.

SQLite simply stores those posts and that signed Merkle tree. The PDS account host server also has another SQLite DB with a list of its accounts.

They have fancier stuff in their appview server and relay server

It's the kind of thing where it's preferable that either everybody switch at once, or that new applications with different "lexicon" (post types / social media format) picks a new default from the start.

This type of API copyright would post likely not just mean the paper form is under copyright protection, but that the software to OCR scan it and parse it would also likewise be protected - as it is an ordered series of keywords with types, etc. It would then be a license infringement to parse forms without a license.

Independent creation is legal defense, not a cause for dismissal of a suit. You need to prove it - which becomes harder if they can argue you saw their work first and imitated theirs.

There's precedence where people have created their own works from scratch and held to be infringing because they mimicked an existing work too closely (like one case of a photo of a red London bus), and in civil copyright lawsuits the other copyright holder only needs to show its likely, which may reduce to showing you knew their work existed.