There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.
"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)
The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.
This is true both for GPG and S/MIME
Email encryption self-compromises itself in a way Signal doesn't
You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.
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.
What you described IS WHY age is the better option.
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
Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.
Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.
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.
C2PA has the problem that it has a ton of optional metadata support and no well-defined strict validation procedure, so it's trivial to make fake photos appear valid using currently available C2PA enabled software.
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)
Also, the RPi is the wrong kind of hardware for attestation, at least use something like USB Armory which provides a user programmable ARM TrustZone environment.
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)
Everything is open source so yes you can, it's mostly a question of practicality.
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.
Most of that doesn't deserve to be called an improvement. That message encryption is one of the worst designs I've ever seen. The algorithm isn't open enough that anybody can see if what it's doing matches the code.
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.
It's used in a not particularly advanced way - bluesky uses repositories per each user for all their public social activity (posts, likes, etc) and it creates a Merkle tree as an index for them and signs that index (this enables stuff like authenticated content addressing and efficient verification).
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 currently built into the applications, not configurable by default. It's preferable if everybody in a thread / space / community uses the same one because otherwise differences can cause validation failures and conflict and thus break threads, resulting in that people can't follow many discussions, thus applications don't really expose it.
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.
Re forms: I did primarily mean rather simple ones (like say attendance forms), but there's a bigger argument here;
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.