How do you get someone to review your product if you're one of N? Paid reviews? Not independent anymore. Paying money to get some exposure and sales is the best of all bad options.
I'm not a betting person but I am looking forward to the postmortem, whether or not AI was involved, and what their code to production verification stuff looks like now. This kind of thing should have been caught by automated tests.
There is an enormous amount of money invested in trying to prove the opposite, for this reason not only they will never admit it, they will actively negate AI was used. It happened before:
10 layers of approvals to get a reasonable change implemented, but this shit gets pushed to production instantly. AI is driving leaders insane - they actually believe they can stop operating with humans and take all of the money. Remember your pay is transactional. Never give them more than written in your contract, and there is no shame in playing dirty politics to advance within.
And with that 37k a day, or 185k per 5-day work-week, what exactly has he achieved?
I don't see any actual output coming from these AI tools, despite how many are saying it's greatly increased their productivity. Where are all the new businesses and tools? I only see more shovels being sold.
A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation.
If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh transfers to traditional QUIC connections and vice versa.
Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.
We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.
> We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.
Bravo, because they always get it wrong.
DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case.
No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.
I might be crazy, but I got a side project to write a DHT using iroh. The key is to use QUIC 0-rtt connections to keep the connection overhead minimal.
But at this point it is just a toy project to push the limits of what is possible with iroh and 0-rtt. It is not used in prod and won't be any time soon :-)
Even 0-RTT connections still allocate connection state. IPFS learned this the hard way.
The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood).
It's much worse for DNS-like services, which is why after all these years DNS still uses UDP. Imagine if the root zone servers had to allocate connection state!
But it all depends on what you're using the DHT for. If you've decided "let's write a DHT that won't be used for naming or DNS-like purposes" then you'll probably get away with it.
I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.
But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.
Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.
It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.
Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api
Forgive me if this is an ignorant question, but does your use of the Mainline DHT mean that Bittorrent clients will be responding to P2P address lookups from Iroh?
First of all: the p2p address lookup is an optional feature. You have to explicitly enable it.
Mainline is incredibly frugal in terms of resource use, but we want it disabled by default so mobile apps don't look like bittorrent clients and get flagged by the OS.
When we do a p2p address lookup, every mainline server node could possibly be responding. Any bep_0044 record gets stored on 20 random mainline server nodes.
So a bittorrent client that participates in the DHT as a server and is long running enough to be included into the DHT routing tables will respond, yes.
Ever experienced being the founding engineer and getting 0.5-2.5%? The amount of work done by the founding engineer for the amount of equity they usually get, there is definitely an unfair exchange here. I'd say the founding engineer is 99% of the time better off finding a non-technical co-founder and building something for 50% each.
Strongly agree from a purely economic perspective! However, founding engineer is a good way to watch the ups and downs of a startup before doing it yourself.
Additionally, since most startups fail, the founding engineer is typically better compensated than the founders. It’s only in the success case that it is a raw deal economically. However, in the rare case that it is a successful company, the founding engineer does alright and then also knows more about how to do it again.
The difference between founding engineer and founder is typically the difference between starting before any money came in or joining after (basically guts/conviction)
Yes, and I've also personally been responsible for cutting about a million dollars per year in AWS expenditure, and never saw a single cent in bonus payouts or equity. It just got repurposed in the budget. Same with building launching a product that brings in hundreds of thousands of dollars a month.
Maybe it depends on who you work for, but that was my experience.
Anecdotally, on my few visits to the US (NY and Colorado), the driving I saw was absolutely atrocious compared to Europe. People were swerving and failing to stay in their lanes on Interstates, everyone was speeding well above the limit (everyone speeds on Motorways, but it seems it's taken to another level in the US). Then you have turn right on red meaning drivers just don't care and turn regardless. Then you have everyone driving massive fucking trucks where you can't see anything from inside.
It seemed every morning I got up and turned on the hotel TV, there was another news about some crash on the Interstate that morning
A difference I haven't seen mentioned here is: the police.
In the US there's a melange of different police forces in any area. Only one of them (Highway Patrol) cares about driving. And in my experience they don't care much about anything pre-accident (except for revenue-raising efforts like speed tickets for 10mph over the limit).
E.g. in the US you'll see countless vehicles with one headlight not working. In the UK (at least when I last lived there) you'd be pulled over and fined for even headlights that aren't correctly aimed.
Totally agree. When someone in my family got their license in the US they had to drive around a parking lot, parallel park and pull into a normal parking lot. That’s it. This was during COVID so the tester wasn’t allowed inside the car.
It absolutely reflects in the quality of drivers today.
I often drive in Europe for business and cry a little on the inside when I’m back on New York streets.
