mastodon-e2ee-specification
mls-architecture
| mastodon-e2ee-specification | mls-architecture | |
|---|---|---|
| 11 | 2 | |
| 195 | 65 | |
| - | - | |
| 10.0 | 8.3 | |
| over 1 year ago | 24 days ago | |
| Makefile | ||
| GNU Affero General Public License v3.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mastodon-e2ee-specification
-
The Apes Shitstorm Shelter (ASS) - the censorship state of reddit and subreddits - Part 2
No end to end encryption in mastodon: https://github.com/soatok/mastodon-e2ee-specification
- Mozilla’s setting up shop on Mastodon and trying to reinvent content moderation
- Discussion Thread
- Is that all you need?
-
Towards End-to-End Encryption for Direct Messages in the Fediverse
What Moxie wrote was about his decisions with Signal. It's not that relevant to this post for distinct two reasons:
1. One of the stated anti-tenets of what I'm proposing is competing with Signal. https://github.com/soatok/mastodon-e2ee-specification#anti-t...
2. Cryptography has matured greatly since Moxie wrote that post.
I feel confident about rolling out a v1 E2EE protocol for the Fediverse in 2023, and then a v2 in 2024 or later.
Migration is a two-putt, but it's tractable. I've worked on similar message format migrations before.
1. Roll out read-only support for v2.
2. Enable writing. Now people can start using v2.
3. Later, once the new version is ubiquitous for the scope of your concern, disable v1.
It's not as fast as if you own the whole stack (like Signal does).
-
AMA with Eugen Rochko, Founder and lead developer of Mastodon, a decentralized, open-source social media platform based on open web protocols. Ask your questions here!
This is a very hard problem to solve. I know it's being worked on by some smart people though, see https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/
-
End-to-end encrypted messages need more than libsignal
Related: https://soatok.blog/2022/11/22/towards-end-to-end-encryption...
-
tankies mad about sites that actually have ToS
The good news is that because Mastodon is open source, and development is done in the open, anyone with the needed skills and interest could implement it right, and there is a project spearheaded by cryptography experts to do just that. https://github.com/soatok/mastodon-e2ee-specification
mls-architecture
-
RFC 9420 a.k.a. Messaging Layer Security (MLS) – An Overview
Does anyone know the status with respect to support for deniability / repudiation? I can't tell from this paragraph where they landed:
https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite...
Previously, their designs had explicitly lacked this feature, and they said they actively didn't want it, citing "terrorism", resulting in arguments with Ian Goldberg, the developer of Off-the-Record messaging. The arguments on the bug tracker about power imbalances were maybe a bit better, but I still personally believe this to be an important property (and one which clients need to fully embrace, allowing the ability to edit any part of the message history so easily anyone could figure out how to do it).
https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN...
https://github.com/mlswg/mls-architecture/issues/50
-
End-to-end encrypted messages need more than libsignal
Notably, this design lacks reputability, which for some reason they didn't even want (as it might be used by "terrorists"), which led to arguments with Ian Goldberg, the developer of Off-the-Record messaging. The arguments on the big tracker about power imbalances were maybe a bit better, but I still personally disagree.
https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN...
https://github.com/mlswg/mls-architecture/issues/50
What are some alternatives?
mastodon - A glitchy but lovable microblogging server
matrix-spec-proposals - Proposals for changes to the matrix specification
GpgFrontend - A free, open-source, robust yet user-friendly, compact and cross-platform tool for OpenPGP encryption. It stands out as an exceptional GUI frontend for the modern GnuPG (gpg).
user_pinger_2 - Bot + accessory services for pinging groups on a subreddit
joinmastodon - The official Mastodon project homepage
mastodon-block-tools - An attempt to list as many different projects/tools/scripts related to Mastodon & fediverse block management as possible
documentation - Mastodon documentation
rathole - A lightweight and high-performance reverse proxy for NAT traversal, written in Rust. An alternative to frp and ngrok.
gitlab
libsignal - Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.
frp - A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.
BirdsiteLive - An ethical bridge from Twitter