During 2010-2017, I worked on creating a "pocket server", the size of a keyfob, which would be the basis of a pads/tabs/boards personal computing environment. It would connect to any number of local screen devices via Bluetooth or Wifi Direct.
It failed because I had no prior experience of developing hardware, and had rather a lot of back luck with HW engineering contractors and contract manufacturers. Some of the story is recounted at https://changelog.com/posts/how-i-volunteered-to-rearchitect...
it's a little disheartening that all of the sites you link to include conglomerated tracking mechanisms, e.g., proprietary tracking for wikipedia (even if this is relatively benign), google for the latter two, plus wordpress for human-id.org.
I made a stupid typo, once SMTP gets in your brain it's hard to get it to rattle its way back out I guess. It's corrected now but the old link continues to work.
That could be, but I'd rather they made the case. When SMTP came out, it was indeed very simple. In college in the 1980s, I could send email just by doing something like:
% telnet mail.umich.edu 25
MAIL FROM: <william@umich.edu>
RCPT TO: <joe.blow@umich.edu>
DATA
From: William Pietri <william@umich.edu>
To: My Skeptical Friend <joe.blow@umich.edu>
Subject: Who needs a mail client?
You can send email without a mail client!
.
It's harder now, because spammers. But to me it's amazing that something like has been working for nearly 40 years. For perspective, it came out the same year as the Commodore 64.
Sorry folks, I thought it was OK to resubmit links that didn't make the front page.
I never got a "Show HN" link on the prestigious Show page because someone else posted it and made the front page. So I tried some other URLs.
I don't think there's an issue with posting relevant comments with a link, but I agree I should disclose authorship.
--- Flagged post above ---
And because cybercrime, which is now doing staggering damage, much of it initiated via SMTP.
SMTP was designed when the Internet's topology and population were vastly different, and we desperately need to replace it, e.g. with TMTP from the "mnm" open source project: [link]
There is definitely an issue with posting your project over and over and over, because that's a sign you see it as relevant even when other people don't. That's certainly the case here. If you wanted to make the "and cybercrime" point, there are a zillion more relevant links than yours.
That looks like spammer behavior to me, which makes your desire to replace email absurd.
The incredibly damaging and widespread exploitation of SMTP for cybercrime (via phishing, etc) implies that the correct model for Internet messaging is non-federated, i.e. more like HTTP than SMTP. That's not to say that federation isn't valuable in other applications, e.g. social media.
Federation in SMTP was necessary given the Internet's topology when email was invented. That network is long gone.
See TMTP, from the mnm open source project, which implements both the client & server:
I strongly disagree. If email was non-federated (like HTTP) then either it wouldn't be so ubiquitous, or a single company would control the digital communication of most of the world's citizens.
Either of those outcomes would result in a poorer world.
The fact that facebook, telegram, whatsapp, etc are all centralized doesn't seem to stop criminals using those platforms.
Zillions of websites have active discussion boards, despite the success of Reddit and FB Groups.
A handful of webmail providers have centralized a large fraction of all email users. They already have the control you're concerned about.
Non-federated email means you have accounts at several sites, and most sites have membership requirements (customers-only, employees-only, etc). A client app keeps track of all your accounts. A webmail intermediary is unnecessary. The mnm demo gives a sketch of this [1] and the FAQ gives more detail [2].
If email worked the way those sites do, I'd need a microsoft webmail account to talk to microsoft webmail people. And a gmail account to talk to gmail people. And an apple account to talk to people there. And so on. That would be a much worse experience of email than we have today.
Federation in email is used constantly and ubiquitously. Why would anyone want to turn it off?
Given that you could easily "unfederate" SMTP/pop3 and have the exact same model, I don't see how exactly the lack of federation will be a selling point.
I see any value in TMTP in the improvements as a protocol and I think it will be only be hurt by having no provision for federation in the protocol.
A TMTP server could act as a proxy between a client and service; there are a few use cases for that (mentioned in FAQ, but not in current protocol draft).
I'm not aware of any use cases for store-and-forward federation that aren't better served by a client-server network. And I've been thinking about this around the clock for four years :-)
It’s certainly a worry, but at least other options do exist. And if you own a domain name, you can move your email hosting (including all your addresses) to the provider you like the most.
And it’s certainly a much better situation than other chat systems, where your identity is fundamentally tied to your account on that particular service. You can’t move to signal without moving everyone else to signal at the same time. I only need one email provider and one email app. But for messaging, everyone ends up needing signal, and WhatsApp, and Facebook to talk to each other. Imagine if you needed half a dozen email apps and accounts for each one to use email. “Oh, you’re emailing a company who uses Microsoft? Better open the Microsoft email program and remember your Microsoft login”.
I don't think federation is the core issue with e-mail. I see the core problem as terrible MUAs don't use nearly enough signals to interpret identity of senders.
SMTP has means to identify servers and domain ownership, web browsers have infrastructure to identify and verify arbitrary websites, and S/MIME exists. Most MUAs ignore basically all of this and instead trust whatever address is in a message's From header.
DMARC is only as effective as the domain's suggested policy and the receiving server doing the right thing. It also doesn't have much if anything to do with the MUAs as they don't see any of the SPF/DKIM operations happening. DMARC doesn't do and isn't intended to do anything to verify the content or validity of an individual message.
A second root problem is the insanity of public SMTP on today's Internet: allowing anyone, claiming any identity, to send you any content without limits.
I started the "mnm" open source project to enable a new email network, on a new protocol.
This problem is partially solved by DMARC/SPF/DKIM. There a few issues with DMARC, but the main one - adoption by senders is well below 100% so you just cannot block mail without DMARC.
But the main question I have - does a typical mail users actually care about sender domain? I suspect - not at all. And I see two main reasons for this. First notion of domain is de-emphasized everywhere - browsers turned address bar into a search bar and make real URL hard to notice, MUA (e. g. Outlook) don't show full email for senders in an address book. Second problem - legitimate senders often behave in exactly the same way as phishers - use unrelated/unknown domain and give no way to verify that the domain is legitimate. For example Charter/Sirius ISP sends mail from domain customeremailnotifications.com [1] and I found no ways to see for sure that is domain is owned or used by Charter. My memory is fuzzy, but PayPal (or ebay) AFAIR used a phishy domain too, something like managemypaypal.com. A largish ZA utility sends mail from eskomstatements.co.za having the main domain eskom.co.za and of course there is no good way to verify that both domains owned/used by the same company. List can be continued. All this conditions users to trust mail which is coming from a random-domain-registered-by-phishers, because legitimate senders do the same.
>There a few issues with DMARC, but the main one - adoption by senders is well below 100% so you just cannot block mail without DMARC.
I wonder if this could be fixed by email clients marking emails that fail DKIM as spam/attaching a large warning. Most users use email clients and they really don't do a great job of notify users of potential spoofing issues (with Gmail, you have to find "view original" to see that DKIM fails). I'm sure that spam filters would notice after a few hundred/thousand emails, but a successful spear-phishing attempt may not require that many emails. If customers complain about legitimate emails being marked as actually fraudulent, I'm sure adoption rates will increase.
However, if an org needs email, why can't they just configure their filters to move everything from outside the org in a special folder, and email server could further filter any link and put it through a warning page before redirecting to the link.
We already have DKIM and SPF to verify if the domains of the sender. Just setting up these can work.
This is a relatively deep look into the bottomless task of considering a candiate for a role in an organization. It bears multiple readings.
It suggests that you may not learn much from interviews with the candidate, and may learn much more from face to face interviews with their references.
It encourages the reader to seek both the genius and dysfunction of every person (candidates and references), for each context they've worked in. (Altho I'd refer to these as their inherent irrationality and ingenuity; dysfunction and genius are the extremes.)
For personal backup/archiving, there's replication to multiple clients, also described on the website.
Someone will create a web service that implements a TMTP client to replicate your account in the cloud. That's fine for many consumers, but must not be the default.
Actually I think I'm not understanding this properly... does the phrase 'messaging service' mean the email service, i.e the server? So the server would not store my mail, but the client would?
I guess the answer is obvious. Sorry, I didn't read this properly. Good work on this!
For 25 years you've pleaded for an SMTP replacement. But all you got was SaaS, sans interop.
Now at long last, here it is. (We're so sorry it's taken so long, but we're only human!)
TMTP is a sane network protocol for email, to end attacks and promote productivity.
You can download client and server, written in Go, from the mnm open source project:
It failed because I had no prior experience of developing hardware, and had rather a lot of back luck with HW engineering contractors and contract manufacturers. Some of the story is recounted at https://changelog.com/posts/how-i-volunteered-to-rearchitect...