I want to share a little idea for a new extension with the goal of adding direct messages in #twtxt https://github.com/tanrax/twtxt-direct-message-extension

I promise I will! It’s the next step 😄

interesting idea. I’m not personally interested on having DM conversations on twtxt (for now), although I see the community could be interested in.

I’d suggest to enable the Discussion section in your Github repo to receive comments, as we did for timeline https://github.com/sorenpeter/timeline/discussions

my first thought is that encrypting messages with Elliptic keys is not as easy as with RSA, although I tried doing something similar a few months ago with ECIES
https://github.com/eapl-gemugami/owl/blob/main/src/app/controller/ecies_demo.php

another one would be to allow changing public keys over time (as it may be a good practice [0]). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:

!<nick url> <encrypted_message> <public_key_hash_7_chars>

Also I’d remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)

[0] https://www.brandonchecketts.com/archives/its-2023-you-should-be-using-an-ed25519-ssh-key-and-other-current-best-practices

I haven’t read the entire specification, but I think there is a fundamental design problem. Why would someone put an encrypted message on a public feed that is completely useless to everybody other than the one recipient? This doesn’t make sense to me. It of course depends on the threat model, but wouldn’t one also want to minimize the publicly visible metadata (who is communicating with whom and when) when privately messaging? I feel there are better ways to accomplish this. Sorry, if I miss the obvious use case, please let me know. :-)

@prologic@twtxt.net @lyse@lyse.isobeef.org First, please leave me your comments on the repository! Even if it’s just to give your opinion on what shouldn’t be included. The more variety, the better.

Second, I’m going to try to do tests with Elliptic keys and base64. Thanks for the advice @eapl@eapl.me

Finally, I’d like to give my opinion. Secure direct messages are a feature that ActivityPub and Mastodon don’t have, to give an example. By including it as an extension, we’re already taking a significant leap forward from the competition. Does it make sense to include it in a public feed? In fact, we’re already doing that. When we reply to a user, mentioning them at the beginning of the message, it’s already a direct message. The message is within a thread, perhaps breaking the conversation. Direct messages would help isolate conversations between 2 users, as well as keeping a thread cleaner and maintaining privacy. I insist, it’s optional, it doesn’t break compatibility with any client and implementing it isn’t complex. If you don’t like it, you’re free to not use it. If you don’t have a public key, no one can send you direct messages.

I updated the specification with base64, Curve25519 and more examples: https://github.com/tanrax/twtxt-direct-message-extension

@andros@twtxt.andros.dev How about putting the whole encrypted conversation into a sperate twtxt-file. Just like the archive feature (?). That way, the general clients don’t have to cope with the decrytption stuff and it won’t break the general public conversations.