networkimprov · HackerTrans

networkimprov

no profile record

Submissions

[untitled]

1 pointsby networkimprov4 yıl önce0 comments

[untitled]

1 pointsby networkimprov4 yıl önce0 comments

[untitled]

1 pointsby networkimprov5 yıl önce0 comments

mnm is not mail – a sane network protocol for email

twitter.com

11 pointsby networkimprov5 yıl önce6 comments

mnm is not mail – email protocol to end attacks and promote productivity

twitter.com

2 pointsby networkimprov5 yıl önce2 comments

mnm is not mail – a sane network protocol for email

twitter.com

3 pointsby networkimprov5 yıl önce1 comments

Why are Go executable files so large? (updated)

dr-knz.net

4 pointsby networkimprov5 yıl önce0 comments

mnm is not mail – a sane network protocol for email

twitter.com

5 pointsby networkimprov5 yıl önce0 comments

mnm is not mail – a legitimate email replacement

twitter.com

2 pointsby networkimprov5 yıl önce1 comments

mnm is not mail – a legitimate email replacement

twitter.com

3 pointsby networkimprov5 yıl önce1 comments

mnm is not mail – a legitimate email replacement

twitter.com

3 pointsby networkimprov5 yıl önce1 comments

Show HN: Demo of mnm, an open source project to replace email & SMTP

mnmnotmail.org

4 pointsby networkimprov5 yıl önce1 comments

If cybercrime was a natural disaster, it was worse than 2020's climate disasters

twitter.com

2 pointsby networkimprov5 yıl önce1 comments

Show HN: How I volunteered to re-architect Internet email

changelog.com

3 pointsby networkimprov5 yıl önce5 comments

Show HN: FAQ for mnm, an open source project to replace email/SMTP

mnmnotmail.org

2 pointsby networkimprov5 yıl önce1 comments

In 2018, US Diplomats Warned of Risky Coronavirus Experiments in a Wuhan Lab

politico.com

49 pointsby networkimprov5 yıl önce15 comments

Show HN: FAQ for mnm, an open source project to replace email/SMTP

1 pointsby networkimprov6 yıl önce4 comments

Show HN: mnm, an open source project to replace email and SMTP

7 pointsby networkimprov6 yıl önce3 comments

The Go os.File.ReadDir() proposal is broken

github.com

2 pointsby networkimprov6 yıl önce1 comments

Go proposal: os.File.ReadDir() for lightweight directory reading

github.com

2 pointsby networkimprov6 yıl önce1 comments

comments

4 yıl öncediscuss

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

4 yıl öncediscuss

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!

4 yıl öncediscuss

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

4 yıl öncediscuss

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 :)

4 yıl öncediscuss

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

4 yıl öncediscuss

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

4 yıl öncediscuss

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

4 yıl öncediscuss

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

4 yıl öncediscuss

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

4 yıl öncediscuss

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

4 yıl öncediscuss

Hi, author here, AMA!

4 yıl öncediscuss

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)

5 yıl öncediscuss

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

5 yıl öncediscuss

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

https://webmonetization.org

https://grantfortheweb.org

5 yıl öncediscuss

"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

5 yıl öncediscuss

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.

5 yıl öncediscuss

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.

5 yıl öncediscuss

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

5 yıl öncediscuss

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.

5 yıl öncediscuss

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