Comment by koolala
3 days ago
Would be great to have a new modern alternative to the E-mail standard that is usable for both public and private messaging.
3 days ago
Would be great to have a new modern alternative to the E-mail standard that is usable for both public and private messaging.
ActivityPub can be used for both public and private messaging, though I don't think the e-mail standard needs to be retired anytime soon.
There was once an idea named IM2000.
Then the world invented pull-style electronic communications systems via another route. You're looking at one.
* https://jdebp.uk/Proposals/IM2000/
There's DIME[0]. I wish I heard about the effort more often, as it's sorely needed.
0. https://en.wikipedia.org/wiki/Dark_Mail_Alliance
We might be able to do this with permissioned spaces. There are instances or use-cases where you want an outside entity to make changes to a user's repo
- email / inbox [or @mail since it is @atproto :]
- unsubscribe from email
- notifications / rsvp
The cool thing is that we could use the stackable moderation infra for dealing with bad actors
https://bsky.social/about/blog/03-12-2024-stackable-moderati...
stackable moderation for ignoring senders is a cool idea. I'll keep an eye out for permissioned spaces, is there encryption and signatures involved at all? (everything on bluesky is signed with PKI, iirc?)
And just unsolicited feedback but "Blebbit" is a deeply terrible name. It turns my stomach for some reason. I don't even know what a bleb could be or what it could represent besides, like, an ulcer.
Your content is signed with a key, but there isn't PKI in the same sense as certificates
There are two efforts around "permissioned" and "encrypted" spaces/content, where encrypted is the E2EE / signal like stuff and permissioned is more like Google Docs or the Discord like permissioning systems. There are use-cases for both
re: name, the second person to dislike, outnumbered by those who do like, will add you to the tally
the name is a play on plebeians / plebs / blebs, not to belittle, but to emphasize this is for the people, not the oligarchs.
Credible Exit Philosophy is important to me and the ATProtocol ecosystem. It means that users can leave an app without losing their data, that they can move their database without losing access, that the majority of Bluesky users could switch to an alternative if they become adversarial.
What it means is that ATProtocol bakes competition into our shared social fabric that all apps build on
there shouldn't be a rush to replace the things that have stood the test of time. Lindy's law would suggest a protocol that's been around 40+ years is fundamental and won't be going anywhere anytime soon.
When it comes to SMTP for email, time has only served to highlight its inadequacy.
DMAC, DKIM, SPF, S/MIME, PGP are all ugly workarounds. The issues are fundamental.
those ugly workarounds are actually brilliant signs of adaptability (not signs of failure). SMTP isn't inadequate, it's resilient. There's a good chance we'll still have SMTP around another 50-500 years.
1 reply →
email has come a long way with SPF, DKIM, and DMARC, and its cool that anyone can purchase a slice of the global namespace that is transferable between providers, but AFAIK the biggest road block to using email in a distributed self sovereign way is reputation and getting your messages delivered to google and outlook users partially because of the nonstop spam.
Do we have any new tools to prevent spam in a post-email world? Or can we just use the current email structure with some better GUI around PGP and Hashcash and force anyone who wants to send a message to burn 10 cents worth of electricity ?
I'm curious what you're looking for in an email standard ?
A quick back-of-the-envelope calculation says that USD 0.1 would be about 700 Wh, so, give or take, a high-performance desktop processor running full tilt for over four hours.
Personally, I'd prefer something like an expansion of how XMPP works. By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not. I think it's a mistake that email servers have been given the responsibility to filter unwanted traffic. Email servers should have only ever simply passed along whatever they received (excluding excessively large messages, of course).
> By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not.
Any email client could implement this policy. You could even prioritize mail over who sent it or whether it's a reply to a mail you sent or have already read.
1 reply →
There’s a fairly direct route to solving this with email. The problem that needs to be solved is that knowledge of an email address is the only thing needed to send to it. Introducing recipient consent as an additional requirement solves spam and phishing.
The first email a sender sends to a recipient has an attachment that serves as a request to email them for a specific purpose (e.g. human:human, mailing list, transactional). This email is not delivered to their inbox immediately, but to a separate “friend request” style queue. When the recipient approves, the sender receives a Biscuit token [0] and the email is delivered to the inbox.
Subsequent emails are sent by attenuating a one-time-use token from the master token, which is included in a header. Because they have verifiable authorisation, this can skip all existing spam heuristics because the receiving mail system knows for certain the recipient authorised this sender.
Biscuits can also be attenuated to reduce scope. Want the hotel you are staying at to only be able to send you email for the next 30 days? No problem. Mailing list providers can reject tokens that are scoped to transactional email. A sender can reduce blast radius of compromises by attenuating new tokens to give to third-party providers.
Authorised senders who spam can have all their historical emails quarantined at once and their ability to send in the future removed. Recipients can see who gave spammers their email address.
People who send mail are incentivised to implement this because it improves delivery rates by bypassing all existing spam filters, including IP reputation. “Ask for a token and you’ll never hit a spam filter again” is something a lot of people would jump at the chance for. No need for providers like Mailchimp, you could go back to sending mail directly from your own servers.
Recipients are incentivised to implement this because it will cut down on spam and phishing significantly.
This can be implemented independently of the other side because the fallback situation is the status quo – the initial email just has an attachment that goes ignored, and subsequent emails are sent without tokens and are subject to existing spam filters.
It’s possible for spammers to send lots of unsolicited contact requests, however separating things out into a spam-free inbox and a “this new person wants permission to email you” queue makes it far more manageable than the current ocean of potential spam in an overflowing inbox. Determining “is this new contact legitimate?” a handful of times is much easier than determining “is this email legitimate?” thousands of times more often.
What you’re essentially doing with this is bootstrapping a social graph on top of email. You can then add a bunch of other nice things on top of that, like public key cryptography, but the actual diff between current email and this system is surprisingly thin.
[0] https://www.biscuitsec.org