Encrypted Messages · Issue #449 · w3c/activitypub
github.com
Here is a simple way I would like to purpose implimenting E2EE messaging in ActivityPub. Simply by using OpenPGP. Every single account on activitypub will have a new field that is not visible to th...

i should stress that no development has been made to this since last month and the only recent development was the sole contributor suggesting the idea to the official ActivityPub repo last week.

the contributor proposed sending an E2EE message as follows, using PGP keys that are stored with password encryption on the instance's server:

  1. It requests the recipents public key
  2. If there is a recipent public key, it sends the recipents public key to the sender
  3. If there is a recipient public key, it encrypts the message
  4. If there is no recipient public key, it will warn the user that this message will send unencrypted and the user can reject sending the message or continue sending the message with encryption.
  5. The message is sent to the user

currently, fediverse services just use existing E2EE services (Matrix, XAMPP, etc.) and while the demand isn't big i think it would be really convenient. especially as a part of ActivityPub, E2EE messages would work over different fedi services to any fedi account, as opposed to separate, incompatible implementations maintained by each fedi service.

what do you guys think about this idea? cool or no?

edit: btw if you don't know, "private" messaging on fediverse is equivalent to mentioned-only posting, meaning the instance admins can read them as plaintext. this is why Lemmy has a disclaimer warning that your messages aren't private, has a Matrix account field on your profile to securely message with and why virtually no fedi services have tried implementing E2EE encryption

  • will_a113@lemmy.ml
    ·
    3 months ago

    I think E2EE would be a great addition -- and certainly a necessary one for proper DM support -- but what I would really love to see is a version where the instance can act like a certificate authority in a SSL/TLS-like trust chain, so that each user could publish and revoke keys for different purposes. Then I might have separate keys for different groups or individual members, kind of like Google+ (remember that?) used to have "circles" and now FB has Friend List or X/Twitter has Circles.

    • asante [comrade/them]
      ·
      3 months ago

      great idea! definitely consider commenting your idea on the GitHub issue. plus it would prevent @notfromhere@lemmy.ml's problem of the public key possibly being changed by being able to verify that the keys don't match.