Interesting counterpoint to the stuff we sometimes talk about here. It's more for public chat rooms though. MLS (RFC 9240) still interests me and I've been wanting to try coding it.

top 5 comments

sorted by: hot top controversial new old
[–] 13 points 1 year ago* (2 children)

This is just one of the comments on the Revolt E2EE issue, I guess the author felt so proud of their opinion to make it into a blog post, I wouldn't say anything if they at least revisited the whole discussion and tried to make a reasonable summary.
The argument provided in the article against features is simply "too hard to develop, too hard to maintain, nobody cares enough".
If nobody cared, nobody would go on Matrix, if everything that was hard to develop were just dropped before even trying, we would have stopped at the hello world (not implying I'm not a lazy developer, but I surely don't want to imply that there aren't brilliant people out there who can undertake scarily big tasks).
Giving another feature as a sort of replacement: federated identities, is not a replacement at all, it's a completely different scope. I just can't empathise with the point that they try to make

  • source
  • hideshow 2 child comments
  • [–] 4 points 1 year ago (1 child)

    I do think their point about not using E2EE enabling better moderation is worth considering, because it’s absolutely true that the server being unable to filter malicious content makes moderation harder. Still, imo any decent chat client should support it as an option, because if I’m talking to friends I don’t want any servers having access for any reason. Large guilds for public info, like the KDE matrix for example, shouldn’t be E2E encrypted for this exact reason (iirc it’s not, because matrix allows the choice and KDE has chosen correctly). Lack of encryption doesn’t mean all moderation issues are solved, though, cuz that same unencrypted KDE matrix had a pretty major problem with CSAM being spammed a while back.

    So IMO the ability to disable E2EE is valuable for a discord replacement, but the author’s idea that E2EE shouldn’t be implemented… does not follow.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 1 year ago

    That was well thought out. Thanks for sharing

  • source
  • [–] -2 points 1 year ago (1 child)

    Downvoter's did not read the article they just saw "don't federate" and downvote lol.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    1 comment in c/privacy@lemmy.dbzer0.com view that post
    [–] 3 points 1 year ago

    Different models for different cases, right? It's only a counterpoint if one believes that the message is "federate everything."

    There is no privacy guarantee in federated systems. There's no privacy in public forums, full stop; nor should there be any expectation of any. You can barely achieve any privacy trust in 1:1 communications, and much less any form of many-to-many.

    Anonymity is another matter - you can have anonymity, if you're careful, but privacy? No. Federation is not about providing privacy, or even anonymity - there's no section either in the AP specification.

    For private communications, you use different technologies; P2P is a good option, but you can get privacy and anonymity in federated systems like Nostr, which - while capable of being a public forum - has all the parts needed to achieve anonymity and privacy.

    Tox has a good model which they can't seem to get to work. 0xchat is interesting.

    It gets said repeatedly: you tailer your solution to your threat model; there's one size fits all.

  • source