Hacker News Reader

networkimprovon Slack is down

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org.

The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative, to my knowledge. So I decided to[1]. The current draft omits federation (although I wouldn't rule it out in all cases yet).

[1] https://github.com/networkimprov/mnm/blob/master/Protocol.md

networkimprovon The Great Software Stagnation

That's the widespread failure to apply insights from Human Factors and HCI research, much of which has been around for decades.

A different problem than better programming paradigms.

networkimprovon Msmtp: About Authentication Methods

You haven't computed the effect of phishing on the fate of email.

At least 100M users have already seen intra-office email replaced with chatrooms. (Which, altho it solves the phishing issue, has created new productivity problems.)

TMTP doesn't have to replace SMTP overnight to be successful.

I'll leave it at that; thanks for the discussion!

networkimprovon Msmtp: About Authentication Methods

Goodness; and here I thought mnm was ambitious! :-)

I think we'll see better results by defining and implementing a simple new protocol that addresses all of the significant security and productivity problems with email.

Note, the current draft isn't a 1.0 candidate; there's more to come, for instance meta-messages.

networkimprovon Msmtp: About Authentication Methods

Thanks for your question. There's a lot more to TMTP than limiting who can send you arbitrary content.

One of its features is that your correspondence does not transit a TMTP server operated by a third party. As with HTTP, its client connects directly to the ultimate host.

Re "users should only receive..." TMTP allows arbitrary content only from approved senders, and limited content from others (see Ping & GroupInvite). There's no manual addition to your address book on the receiver's part.

networkimprovon Msmtp: About Authentication Methods

Are there usable PAKE implementations? Audited ones?

networkimprovon Msmtp: About Authentication Methods

If anyone's interested in a modern rethink of SMTP, here's TMTP:

Why TMTP? https://mnmnotmail.org/rationale.html

Protocol draft: https://github.com/networkimprov/mnm/blob/master/Protocol.md

Twitter: https://twitter.com/mnmnotmail

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

I suppose I could have borrowed aspects of IMAP, but the result wouldn't interoperate with other IMAP software.

Here's the protocol draft:

https://github.com/networkimprov/mnm/blob/master/Protocol.md

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

Here's a live link: https://mnmnotmail.org

If you set up the mnm server and would like to let others make accounts on it, please add it here:

https://github.com/networkimprov/mnm-hammer/issues/4

networkimprovon Zig 0.7.1 Released – 69 bugs fixed

Zig will be production-ready (for some definition of "production") when it reaches 1.0.

The question of when will Zig be as mature as Rust is impossible to answer.

networkimprovon How to Think for Yourself

The purpose of these essays might be more PR exercise for YC than an effort to foster efficacy among would-be world-beaters.

"When E.F. Hutton speaks, people listen" ;-)

networkimprovon The Few, the Tired, the Open Source Coders

The article fails to mention new companies that are trying to solve this problem, e.g. https://tidelift.com

networkimprovon Servo’s new home

Plenty of pre-production software is built with pre-production dependencies.

Does it not work for a useful subset of HTML/CSS?

networkimprovon Servo’s new home

I looked for a list of projects currently embedding Servo, or planning to, but didn't find one.

Is any software embedding it now?

networkimprovon Eleven Years of Go

Marketing & branding -- esp to enterprise IT -- is really not in the Go team's wheelhouse.

A third party could take it on, but that would require a different governance structure for the project. Outside entities have little influence now.

networkimprovon No More Free Work from Marak: Pay Me or Fork This

> Most software libraries aren't products

This is the rationale for https://tidelift.com

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

Other comments in this sub-topic:

An example - https://github.com/golang/go/issues/41467#issuecomment-69804...

A fix - https://github.com/golang/go/issues/41467#issuecomment-69689...

A clarification - https://github.com/golang/go/issues/41467#issuecomment-69692...

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

This looks promising, but has a major gap -- it can produce different results on various filesystems.

https://github.com/golang/go/issues/41467#issuecomment-69689...

networkimprovon Why Not Rust?

Will the compiler performance eventually match C++, or are there fundamental limits to it?

networkimprovon Statement Regarding the Zen Programming Language

I'm sad to hear that the Zig community is burdened by this. I've filed a couple proposals there, and hope to use it post 1.0.

But what a PR opportunity! Here's an outfit selling Zig (because it's good enough already), which won't even hit 1.0 for "two years" \o/

("Two years" is from Andrew on a recent podcast.)

networkimprovon Why is there a normal galaxy sitting at the edge of the Universe?

It's not a new idea... I first heard of it in the intro segment of this Cool Worlds Lab vid

https://www.youtube.com/watch?v=jgOTZe07eHA

networkimprovon An interesting mistake with Go's context package

You have to be able to direct a signal to the thread blocked on the syscall to be terminated.

Go has no way to obtain the Id of that thread. That's what the issue I linked above covers.

networkimprovon An interesting mistake with Go's context package

Contexts are generally regarded as a workaround for the fact that Go doesn't offer goroutine-local storage -- a design feature that's often criticized.

networkimprovon An interesting mistake with Go's context package

Rust also permits termination of blocking syscalls.

Once upon a time it automatically retried many syscalls after EINTR, but it dropped that design flaw.

networkimprovon An interesting mistake with Go's context package

Most blocking syscalls in Go cannot be terminated by any means. [1]

It seems unlikely that the stdlib os API will add dozens of variants taking context.Context. The new FS API proposal makes no mention of deadlines or contexts. [2]

[1] https://github.com/golang/go/issues/41054

[2] https://github.com/golang/go/issues/5636#issuecomment-661926...

networkimprovon Don't trust default timeouts

Apologies if I got this wrong, but you've linked read(), and I'm referring to mkdir() et al.

Have they taken out the EINTR retries which were added for the issue I linked?

networkimprovon Don't trust default timeouts

The Rust filesystem API works (or once did) as I described. This can render an application unusable when trying a network filesystem or storage device that's unavailable.

https://github.com/rust-lang/rust/issues/11214

To support user intervention when a task takes longer than expected, all blocking syscalls should be interruptible.

networkimprovon Don't trust default timeouts

Go, Rust, and Zig make it impossible to interrupt most blocking syscalls, because they automatically retry on EINTR. [1]

Go supports timeouts on network & file read/write ops, which can be used to interrupt them.

[1] https://github.com/golang/go/issues/41054