Okay...so Substack is basically a social media platform now.
"Substack writers and readers can now send private one-on-one direct messages to others on the platform, the company announced today. The highly requested feature works similarly to DMs found on social networking apps like X and Instagram, though it is optional and can be disabled."
So you might know by now that DMs (here called Private Mentions) work differently on Mastodon (maybe other fediverse platforms?) in that anyone you @ mention will receive the message, unlike on Twitter, where tagging someone does not add them to the conversation.
Who here learned this the hard way? Share your stories!
CKAN is an open-source DMS (data management system) for powering data hubs and data portals. CKAN makes it easy to publish, share and use data. It powers hundreds of data portals worldwide. (AGPL 3 License)
It powers the open data at Government of Canada. (and Singapore, and Australia)
It uses Python 3.8+, and documented using Sphinx + ReadTheDocs!
> "According to #Kolektiva, the seized database, now in the #FBI’s possession, includes personal information such as email addresses, hashed passwords, and IP addresses from 3 days prior to the date the backup was made. It also includes posts, #DMs, and interactions involving users on the server. As is the nature of the #fediverse, this also implicates messages and posts from other instances.
Once upon a time, #twitter#DMs worked exactly the same way they work on #Mastodon, except there wasn't a visibility setting, instead you had to manually put 'DM' at the beginning of a tweet.
Yep, it was easy AF for your intended DMs to accidentally go public 🤣
If you notice, DM stands for 'DIRECT Message', not 'PRIVATE Message'. There should be no expectation of explicit privacy in a direct message - it simply goes directly to the mentioned users, not privately, and as on early twitter, it's possible for user error to fuck it up.
Adding #e2ee to DMs on the fediverse sounds relatively simple, but is actually more complicated than I initially thought.
A property for a public key could be added to the object contains info about a user (name, pfp, inbox, etc).
This public key can then be used to encrypt the contents of a message/note, except for the recipient.
The remote server will still be able to see what server the message came from and who the message is for.
The recipient's client then needs to decrypt this message, but where is the decryption key stored?
Perhaps it can be stored on the server encrypted using the user's password?
Upon logging in, the encrypted decryption key would be sent to the user.
This wouldn't actually work, a server admin can always modify the server code to log passwords.
Encryption would have to be implemented client side separately.
The private key can't be stored on the server securely. The user needs a way to create a key pair, then send the public key to the server and store the private key.
On browsers this would require JavaScript that needs to be downloaded from the server, which can be modified to add a backdoor. On apps this would work a lot better.
But when a user just installed a new app/client, they won't be able to see their older DMs.
The only realistic way of implementing this is as an extension to the mastodon api, it's too easy to backdoor on browsers by either server admins, malicious browser plugins or network admins.