networkimprov

What's your opinion of Etherpad? Does their roadmap overlap with your vision?

Wow, have to ask whether you're interested enough to contribute? :)

    > You can't use a volatile cache ...
    > all this work to juggle JSON in flat files

I really don't think I've misused the cache! I didn't use SQLite because ordinary admins need to be able to inspect and occasionally fix the database. That decision can be revisited down the line.

    > Companies don't want to host heir own email servers

TMTP is more like HTTP than SMTP. There must be many ways to host a service, just like a website. Any admin must be able to bring up a TMTP server. (It's nothing like getting a new MTA host to work with the SMTP network!)

I discuss the E2EE issue on the mnm website FAQ. Only certain kinds of TMTP sites will want it to be the default. If a consumer tech brand offers an online TMTP client, it would present a proprietary API to the browser, as Gmail does; TMTP can't protect those messages.

    > synchronization between multiple client devices?
    > permissions in groups?
    > identity verifications?
    > mobile clients which don't want to open dozens persistent connections?
    > the demo doesn't actually use the protocol?

Client sync is implemented already \o/ - that's the replicas feature. It already has simple, user-defined groups. Admin-defined groups is on the roadmap; need user input to chart a course here. I've implemented OpenID Connect auth for new account registration. It could also be required per login, if there's demand. JMAP offers a model for how to do non-persistent connections on mobile devices. The demo is just the browser-based UI to the client, reconfigured to use canned data. (The client is a localhost web app.)

And, hey, can't a protocol can be a work in progress? I'm only willing to spec what I am ready to implement!

A TMTP client can subscribe to any number of TMTP services at different sites.

FWIW, most of the roadmap for this project is not described on the website nor defined in the protocol.

This is a deep topic, and "messaging" is not the only goal, nor even the principal one :)

(Author here.) I imagine that existing web-based bulletin boards would simply copy messages to TMTP users if requested.

Conversely, TMTP groups/lists could be copied to a read-only website.

(Author here.) The message format definition is included in the protocol doc only as a convenience. Ultimately it would be two standards.

Trying to "upgrade" the email ecosystem is an impossible goal, and the requirements I'm working to can't be shoehorned into the email model.

(Author here.) Thanks for your interest & support!

Yes, the default concept for an Internet messaging service is "everyone can reach anyone". This isn't helpful for online services and businesses who need to reach their members/customers directly & securely, and with a rich content model (e.g. survey/form in message, and structured result in reply).

(Author here.) Development has been paused for ~1y as I've been at work creating a vehicle to take this forward.

The protocol specifics (e.g. identifiers & types) aren't polished, because I focused on features in working code. Thanks for the feedback!

You can't have alias collisions; it checks whether the string you propose is acceptable & available :)

A sender's alias is (or will be) checked against their recorded aliases.

The reason why lack of E2EE in email is a serious problem is that email traverses at least two "federated" services, which are typically third parties with whom you have no intrinsic need for a relationship. A TMTP message passes through a single service which you explicitly joined.

I don't see how your feedback justifies "poorly thought out"; it's merely an unpolished preview.

(Author here.) TMTP clients maintain concurrent (possibly intermittent) connections to any number of TMTP services, and each service gets its own inbox. So you don't need a separate app instance per service.

Inboxes for a set of related services could conceivably be merged, tho I haven't done any work on that yet.

(Author here.) The client UI is designed for desktop. A mobile frontend is in the works. Tentatively planning to use Ionic Framework with Vue.

Hi, author here, AMA!

Here are a few fundamentally different async protocols in development which could challenge SMTP:

DIME - https://en.wikipedia.org/wiki/Dark_Mail_Alliance

Math Mesh - https://mathmesh.com

TMTP - https://mnmnotmail.org (my work)

Oddly, the Web Monetization spec, probably essential to ILP adoption, doesn't indicate how browsers would contact an Interledger network site.

https://webmonetization.org/specification.html

https://github.com/WICG/webmonetization/issues/195

It's the underpinning of the Web Monetization effort backed by Mozilla.

https://webmonetization.org

https://grantfortheweb.org

"mnm" enables a safer, better, decentralized email network. It's open source (and not blockchain).

https://mnmnotmail.org & https://twitter.com/mnmnotmail

Because SMTP will not be fixed, here's why: https://mnmnotmail.org/smtp.html

---

Related protocol projects in development include:

https://mathmesh.com/

https://en.wikipedia.org/wiki/Dark_Mail_Alliance

I have sketched a plan for a venture, for which I'd need co-founders (e.g. mobile app code & UX expertise) -- feel free to reach out via Twitter @mnmnotmail (link above).

Those big corporate advocates necessary for the success of a new email protocol are fortunately not the major email hosting players! See the mnm FAQ #2 for a plausible adoption path.

At this early stage, I'd say the biggest obstacle is reaching a wide enough audience; I have no prior fame, and no PR budget yet.

And yet none of those corporations has displaced email, despite the fact that it has become a universal cyberattack channel, with a stagnant UX that doesn't address most real-world use cases for email!

I saw a need for a safer, better, decentralized protocol for email, so I drafted one (TMTP) and implemented client & server. More at:

https://mnmnotmail.org/ & https://twitter.com/mnmnotmail

Related protocol projects in development include:

https://mathmesh.com/

https://en.wikipedia.org/wiki/Dark_Mail_Alliance

The success of a wide variety of messaging and discussion apps demonstrates that the network effects of email are not necessarily a high barrier. What these products have lacked, which email has, is an open protocol. (XMPP had early success, but never addressed the main use cases of email, and has major design flaws.)

A handful of credible alternative protocols are now in development:

DIME - https://en.wikipedia.org/wiki/Dark_Mail_Alliance

Math Mesh - https://mathmesh.com

TMTP - https://mnmnotmail.org (my work)

Email was designed in the 1970s & 80s for an Internet whose population and topology have dramatically changed since. We no longer need a messaging system that allows anyone, claiming any identity (i.e. "real name"), to send you any content, without limits. Federation was necessary for the topology of the early Internet, but today it is a drawback -- making email by far the most effective method to initiate cyberattacks.

You might like TMTP from the mnm open source project (my work).

Didn't XMPP originate with a single vendor? And JMAP? Didn't SMTP also originate in the field?

Are you saying that the Matrix authors won't submit an RFC?

Could you define "real open protocol" vs "public API"?

If the former entails an adopted RFC, isn't it common practice to prove need via a product before proposing a standard?

Asking because I'm at work on a safer, decentralized protocol for email, TMTP.

Have a look at TMTP from the mnm project.

The primary problem for email at this point is that it's a highly effective cyberattack channel, because it allows anyone, claiming any identity, to send you any content, without limits. This cannot be "fixed" as it's the intended function.

No one was working on an alternative that addresses this problem, so I drafted & implemented "TMTP". It also addresses a variety of other common email problems.

https://mnmnotmail.org/

https://twitter.com/mnmnotmail

Great story of "market-based" engineering management & collaboration, where different teams could trade resources (in multiple categories) with other teams to optimize each component while staying in-bounds with the mission requirements.

Before ditching SMTP/etc, we'd need something to replace them.

TMTP (my work) is a candidate. More at https://mnmnotmail.org/

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...

Not yet! See TMTP from the "mnm" project (my work).

I know of two:

DIME - Dark Internet Mail Environment

mnm - mnm is not mail (my work)

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]