1,160 karma · joined February 19, 2015
First iroh was marketed as "solves communication behind NAT". Then we went to application level NAT busting vs node level NAT busting. Then we went to distributed vs client-server, then we went to stable IPs for non-server devices (your original comment). Now we moved to "true peer to peer" and "public keys".
This just tells me that the marketing site doesn't explain what Iroh actually does.
The fact that so many other people (apart from me) asked about the connection to Tailscale is also interesting.
For this simple scenario (just exposing your laptop to a public IP) there are already a gazillion alternatives (e.g. ngrok)
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
If I wanted to share something internal with a friend I would use ngrok or any of the million alternatives.
Anyway, this is exactly why my top-level comment says that this project needs a "versus" page in the docs.
You need urgently a "versus" page that talks about tailscale/netbird/netmaker/zerotier/twingate/openziti
Looking at the use cases, right now I don't see anything that cannot be done with Tailscale...
Starlink only makes sense as a last resort if LTE coverage is not available in your area.
Depending on your area you don't even need an external one. A simple 4g dongle would do.
Doesn't this suffer from the opposite problem though? There is a very brief hiccup for Stripe and instance 7 triggers the circuitbreaker. Then all other services stop trying to contact Stripe even though Stripe has recovered in the mean time. Or am I missing something about how your platform works?
"The SDK is fail-open by design. If our service is unreachable, it falls back to the last known breaker state.
If no state has ever been cached (e.g., a cold start with no connectivity), it defaults to closed, meaning your protected calls keep executing normally. Your app is never blocked by Openfuse unavailability."
I understand the sentiment, but it is really strange that the people that are pushing for agents.md haven't seen https://contributing.md/
Is it even mentioned at GitHub docs https://docs.github.com/en/communities/setting-up-your-proje...
Any well-maintained project should already have a CONTRIBUTING.md that has good information for both humans and agents.
Sometimes I actually start my sessions like this "please read the contributing.md file to understand how to build/test this project before making any code changes"
If a team has one senior/seasoned person and 3 juniors will adopting ai be a total positive move? Or the senior person will just become the bottleneck for the junior devs?
1. Learn/Improve yourself with each action you take 2. Create better editions/versions of yourself 3. Solve problem in areas that you were not trained for simply by trial and error where you yourself decide if what you are doing is correct or wrong
citation? source? Who is we?
This implies that you are an expert/seasoned programmer. And not everybody is an expert on this industry (especially the reviewing code part).