The road to iroh 1.0
49 points by Frando
49 points by Frando
I like iroh's simplicity from the user-facing marketing angle: it provides you a primitive, dial by public key instead of IP, and everything else is built on top of that or serves it in some way. Networking is not my area, so when I read about most networking/p2p projects, I'm suitably impressed but don't walk away with a good understanding of what they really do or how I would use them. But iroh is simple enough that I can understand what problems it solves and how I could use it.
I'm not sure if this is how they got there, but the style of engineering I've been gravitating towards for years is starting from the intended user interface and working backwards. It consistently results in the strongest APIs, the cleanest abstractions, and the most intuitive tools I've found of any other 'paradigm'.
I do this when writing the code too: start with how I want the method/class/system to look and then work backwards until the implementation delivers that.
Linus Torvalds is on our front page for other reasons today, but he has a quote from years ago that's been floating around:
Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
I'm more reluctant to call a programmer "bad" than Linus is. But there is something to be said for the technique of defining the shape first and working backwards from that. (Whether the "shape" is the data structure, the class interface, the API…)
I agree, but it's also really easy to derive this guidance from a question: is your product the code or the tool? Too often it's easy to get lost in the weeds on the code and forget about the actual product. And a corollary is adding too many features or making things more generic than they need to be in the product. The tighter the constraints are, the better the code will be in general.
But in the end it's just guidance, not a rule. There will be trade-offs to make for when early generalization is a good thing too.
That backwards thinking applies to both? When you're building some product you're necessarily making decisions and performing work on behalf of your users, so it still makes sense to think about what they're going to be doing and interacting with and how from the outset.
To a degree, they're the same thing. If you're making an API or library, your product is the code and your users are other developers. They're not really substantially different, it's all about knowing your audience.
Cool to see a good use case for raw public keys! A friend and I jointly implemented that feature in rustls, sponsored by the Solana Foundation, and I was really hoping it would be useful outside of blockchain tech (I have no love for blockchain stuff). It looks like the timing was just right for iroh to start using it :)
Thanks. We were so happy when we could switch to raw public keys in TLS from that weird machinery we were using before. That was when the decision to stick with TLS was proven correct in my opinion.
DNS-over-TLS is the other usecase for raw public keys: see "SPKI" in https://www.rfc-editor.org/info/rfc8310/
This is no worse than typical deployments of SSH or Wireguard.
I've been building a community hosted object store using Iroh and the API has been such a breath of fresh air. Iroh does a lot of the heavy lifting. The Iroh discord is super helpful too. Shameless plug: https://arkeldata.com