Even though it doesn't federate over OStatus, private messaging within an instance would be helpful.
If it doesn't federate, it means local users are privileged over remote ones in the software, which runs counter to the principle of transparent, seamless federation.
Some more thoughts - although it does sound like transparent federation is a knock down reason not to implement this...
Against: On Twitter, DMs became a terrible spam vector and links in them were banned to try and mitigate this.
I don't think private messages is part of the core offer of a short messaging service, this is well catered for in many other ways.
For: If two individuals meet on mastodon social and want to message privately on another channel confirming each other's identity is a slightly tricky, but not impossible.
More practically, many people won't want to share their real email and won't bother to set up a throwaway.
One solution would be to add a contact field on your profile page, but make it selectively available only to those you choose. Presumably there is no way to federate this (I promise to read about OStatus soon!), but it does help with the spam issue and saves implementing a full messaging system.
What if email is the solution? What if [email protected] was not only a unique handle for GNU Social, but a valid email address?
That would work, honestly! Set up MX records, then if there's some way to accept incoming mail through Rails a system could be built around that because e-mail is already federated
I don't know if this is the right solution, but I very much admire the ingenuity of it. It makes the spam problem someone else's.
Would it forward the email to the email account you registered with?
It could, or we could have a UI for private messages
I was thinking both of these things. I almost wonder if you could do some kind of verification - e.g. only accept a message if it was from a Mastodon instance/the Mastodon user it claimed to be from.
Ooh! Something like DKIM, but for individual users! Give users a signing key that's in their profile or a Toot, and then you can verify that the email was sent by them.
Accounts actually generate an RSA keypair already which is used for verification of Salmon slaps.
Huh, so we could actually have encrypted/signed private messaging, between Mastodon instances, over email, utilising existing accounts and credentials, and presented to the user as a UI/API?
I mean, one hand, yes. On the other hand, since the keypairs are generated and stored by/on the server, rather than to the end user, it's not truly secure. Plus there's no key rotation. I'm comfortable using them for server-to-server verification, but not for user-to-user/end-to-end integrity! I don't have the cryptographic background to really judge that.
That makes sense. Still, it means we can stop generic email spam, because we have an easy way to verify it's from a Mastodon instance.
Most helpful comment
If it doesn't federate, it means local users are privileged over remote ones in the software, which runs counter to the principle of transparent, seamless federation.