end-to-end VS bogbook

[1] No warning on decrypting Tag 9 (no integrity protection) packets

In contrast, companies like Standard Notes actually uses their own home-built encryption library, which is why it's a bit more critical that they go through these audits more often and quickly than others. And despite the audits, this home-brewed encryption library puts them at a much bigger risk, due to the fact that it's never going to be as thoroughly battle tested as an open industry-standard encryption like OpenPGP, used by much larger companies like Google, Protonmail, etc.

https://github.com/google/end-to-end ?

When Google was looking at implementing E2E mail via a browser plugin, it gave up in part because of the difficulties of doing it right. They published the library and documentation, but the more valuable part was the threat model. In it they examine the assets to protect, threat sources both inside and outside the threat model, UI threats, message threats, key-related threats, cryptographic threats, and other threats. It's an excellent walk-through of just how difficult it is to do general encryption right, and why doing it in the browser is so hard.

With that in mind, secure messaging in a browser is a nightmare. Google tried to figure out a way to do end-to-end in a browser, mostly in the context of e-mail but it could be extended to chat applications. They wrote up a threat model that you really should read. They identified five threat sources within the architecture and six more that they acknowledge but don't delve into. They also discuss four UI-based threats, four message-based, four key-based, and two cryptographic threats, and each of those threats has subthreats. Finally, they wrap with three "Other" threats. They dropped the project soon after.

Google E2E Library — Unsure how up-to-date this ... limited GitHub activity.

> One adjustment to the protocol that seems to me like a quick win (but presumably has some technical hitch I can't see, since I don't recall anyone suggesting this) would be to not include the post's body in the “block” (in the message itself that gets hashed and signed by the next message), but rather as a “blob” (essentially an attachment) which others don't need to download in order to verify the feed.

There's nothing to prevent you from taking this route, you just sign a blob hash instead of an entire message object.

I work on an experimental SSB-like-protocol in my spare time that does exactly what you've suggested: https://github.com/evbogue/bogbook

I don't know if this makes the network forget more, but the aim is to reduce the time it takes to sync and get started.