-
-
Scout Monitoring
Rennaisance engineers rejoice! 1 gem 5 min to app monitoring. 5-minute onboarding. No sales team. Devs in the support channels. No DevOps team required. Get the free app insights every engineer deserves with Scout Monitoring.
-
>I as a developer have yet to even figure out how it's supposed to work
You go to https://joinmastodon.org/, click on "join" (or pick another server if you are adventurous), fill in your username and email and you're good to go.
Why do people invent fictional horror stories about a service that's at this point functionally as easy to use as any bog standard website?
> but at the very least I think Bluesky could start with generating a private key on each client device, and then using a simple box algorithm to encrypt messages towards the user they want to talk to.
Furry cryptography nerd here.
No. This is inadequate.
> I don't think https://tweetnacl.cr.yp.to/ is hard to mess up.
Yes it is! If you're doing to encrypt some things in a constrained use-case, sure, NaCl is better than hand-rolling it yourself. But it's not sufficient for end-to-end encryption. Here's a few things that TweetNaCl (and other NaCl variants) is, without further protocol design, inadequate to protect against:
1. Invisible Salamanders. NaCl uses xsalsa20poly1305, which is not key-committing.
2. Key Compromise Impersonation. See also, Toxcore, which built atop NaCl: https://github.com/TokTok/c-toxcore/issues/426
3. How do you do group messaging? If you do it as just pairwise, do you use the same public key as your p2p messaging? If so, how do you make sure you don't have a nonce reuse condition between both interactions. Oops.
There is a damn reason end-to-end encryption involves authenticated key exchanges and forward-secure double ratchets.