I’ve been putting together a proposal for cooperative email infrastructure built on atproto. The core idea is roughly:
PDS operators pool transactional email through a shared SMTP relay, solving the volume problem that kills individual self-hosted email
An attestation lexicon lets operators publish signed records about their mail server configuration
A labeling service verifies DNS setup and applies reputation labels to member DIDs
ROOST’s Osprey handles enforcement using the same pattern as the existing osprey-atproto integration
Members collectively build enough sending volume that Gmail/Microsoft’s algorithm recognizes the cooperative organically
Like Let’s Encrypt, but for mail server reputation.
The full vision doc is here. It covers mail server evaluation (Stalwart vs. mox vs. Maddy), the atproto integration architecture, ROOST/Osprey feasibility, the privacy model (including how Permissioned Data changes the picture), and a phased implementation plan.
A few questions for this community:
Would anyone want this?
Is someone already working on something like this? I found some relevant chatter here
Alright I think I’ve got a working Phase 0 implementation (atproto foundational work, labeler + lexicons). With this, I was able to label my own did with an attestation that I am a verified mail operator.
I would love to use this for self.surf PDS, its currently only used for two of my projects (linkna.me + reads.at) but it is open for other app devs to join and use the PDS.
The ePDS enables me to create passwordless login, its not the default ePDS either, Im doing a little magic in order to make sure people can authenticate and log in while remaining on the main app domain (user is never redirected to auth.self.surf and remains on linkname url throughout account signup & login for best ux possible).
I need to properly document this and push the changes live to a repo for people to review.
What concerns or objections come to mind?
Since I am not running a default PDS, it should still be fine for me to implement this - but it might add more overhead to do this with a non-standard PDS, if this is out of scope I can also just dive into this myself.
UX concerns:
Previously I had password reset emails be sent from self.surf domain, I have with the ePDS switched the email domain to be linkna.me in order to reduce possible points of confusing people when they receive an OTP email from another domain other than the app they signed up with.
My concern here is, if there is one PDS with one url domain, and 5 different apps using it, it will become a point of churn/friction for new users to be onboarded if they see a different domain url send them an email for login OTP.
Things that could be done to prevent this, eg., the PDS could become a brand like “magic.link” or some other OTP service that other apps/devs/businesses could use. But now this entire PDS itself becomes a business of its own and that adds overhead (I dont want to monetize the PDS, since its basically free to run and offer).
Would there be a way for each app to have their own custom domain, so that linkname user get OTP emails from linkna.me domain, and reads.at users get the OTP from the reads.at domain, etc. this would require adding one domain per app (and for the PDS to send out emails from multiple domains).
I recently read the FAQ of eurosky.tech, and maybe it would be worth for them to actually build a small brand that solves for exactly this problem.
A brand similar to existing OTP email services, for app devs to utilize, during signup flow there could be a brand icon like “Secured by (logo) (brandname)” and when the user then receives an email from that brandname url, they already know and expect this to happen so this mitigates points of confusion/churn/friction for the end-user.
maybe something to think about for the eurosky team!
Also: since (if this is built on OTP, which it should because why would you not want the best UX possible), it will scale a lot more and require a lot more emails for people to login. And hence, it would be a valid reason to have a generous free tier for devs + add monetization for higher tiers, would be a new revenue source for eurosky to become financially sustainable!
Phase 0 is working and checked in, including multi-domain support. Each app domain signs with its own DKIM key through the shared infrastructure, so users see the domain they signed up with. Phase 1 is working locally too, I’m sorting out a small legal structure (LLC, not a full co-op yet) before I start routing other people’s mail through shared infrastructure. DM if you’d like to help me test!
Any organization like EuroSky would be welcome to join as a member and use the relay. For now I’m trying to build it as its own thing, but open to seeing how it fits into the broader ecosystem.
As for governance, sending email through the service doesn’t require participating in it. Most members would just send mail. However the option to have a say in how the infrastructure is run needs to exist, because without it, we’re no better than Gmail.
This is super cool, and would love to help in any way I can.
I’ve been exploring using SMTP to deliver E2EE messages between ATProto users. I wasn’t focussed on solving the problem of delivering “legacy” emails to current providers, but still need to way to reason about trusted providers for messages sent within the atproto ecosystem.
Woo, I’ve got a working Phase 1! I need to review all of the code before sharing it and I’m in the process of setting up the small LLC to start testing with other users (please reach out if you’re interested!)
Here’s a screenshot of delivering mail to my Proton account from atmosphere-mail.org:
