HN user

dennis-tra

965 karma

Reach out hn@dtrautwein.eu

Posts50
Comments40
View on HN
probelab.io 21d ago

How We Made IPFS Content Publishing 10x Faster

dennis-tra
183pts61
www.kielinstitut.de 1mo ago

Endgame: Russia's war economy hits its limits

dennis-tra
2pts1
probelab.io 1mo ago

Optimistic Provide: How We Made IPFS Content Publishing 10x Faster

dennis-tra
1pts0
bsky.app 1mo ago

How many days of the week have a fish in them?

dennis-tra
11pts4
tangled.org 2mo ago

Tangled – tightly-knit social coding

dennis-tra
2pts0
probelab.io 4mo ago

Optimistic Provide: How We Made IPFS Content Publishing 10x Faster

dennis-tra
1pts0
probelab.io 4mo ago

Optimistic Provide: How We Made IPFS Content Publishing 10x Faster

dennis-tra
2pts0
probelab.io 4mo ago

Peering into Privacy: A Deep Dive into the Monero Network Topology

dennis-tra
3pts0
arxiv.org 11mo ago

Language Model Can Be a Steganographic Privacy Leaking Agent

dennis-tra
3pts0
www.nzherald.co.nz 1y ago

Taranaki mountain becomes legal person

dennis-tra
2pts0
github.com 1y ago

Beancount: Plain Text Accounting

dennis-tra
2pts0
github.com 1y ago

Tailscale: Move away from inet.af domain seized by Taliban

dennis-tra
16pts0
github.com 2y ago

Show HN: Nebula – A network agnostic DHT crawler

dennis-tra
68pts22
github.com 2y ago

Nebula – A Network Agnostic DHT Crawler (IPFS, Ethereum, Polkadot, and More))

dennis-tra
3pts0
blog.ipfs.tech 2y ago

Amino – The Public IPFS DHT Is Getting a Facelift

dennis-tra
134pts111
github.com 2y ago

OrbitDB reaches version 1.0 after 8 years of development

dennis-tra
1pts0
community.plotly.com 3y ago

Plotly.js CDN Throwing 403s

dennis-tra
3pts0
blog.ipfs.tech 3y ago

What happens when half of the IPFS network is down?

dennis-tra
87pts9
blog.ipfs.tech 3y ago

What happens when half of the IPFS network is down?

dennis-tra
3pts0
github.com 3y ago

Paperless-ngx v1.14.0 released with multi-user permissions

dennis-tra
2pts0
www.ietf.org 3y ago

Six Applied Networking Research Prizes Awarded for 2023

dennis-tra
1pts0
github.com 3y ago

Steganography-Based Image Integrity

dennis-tra
3pts0
github.com 3y ago

Call HN: Decentralized Nat Hole Punching Measurement Campaign

dennis-tra
3pts1
github.com 3y ago

Decentralized Nat Hole Punching Measurement Campaign

dennis-tra
3pts0
github.com 3y ago

Decentralized Nat Hole Punching Measurement Campaign

dennis-tra
2pts0
dl.acm.org 3y ago

Design and evaluation of IPFS: a storage layer for the decentralized web

dennis-tra
193pts68
arxiv.org 3y ago

Design and Evaluation of IPFS: A Storage Layer for the Decentralized Web

dennis-tra
1pts0
ipfs.io 3y ago

Design and Evaluation of IPFS: Measuring the Deployment and Performance [pdf]

dennis-tra
3pts0
ipfs.io 3y ago

Design and Evaluation of IPFS: Measuring the Deployment and Performance [PDF]

dennis-tra
2pts0
github.com 4y ago

Go-IPFS v0.13.0 has been released

dennis-tra
2pts0

Had the same issue that the blue dot won’t disappear. I was able to clear the dot with:

gh api notifications -X PUT -F last_read_at=2025-10-06T00:00:00Z

Just change the date to today. I also got that line from a gh issue somewhere - maybe it was the same issue that you’re referring to.

Can someone explain to me why the compiler can’t do struct-field-alignment? This feels like something that can easily be automated.

This is an excellent article!

The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this:

You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go.

However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0].

This is especially true if networks block UDP traffic which is also acknowledged:

For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic.

My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity.

[0] https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...

I had the exact same thought for years but never came around experimenting with it. I also hoped that one could eventually hear that something is off.

I think this can happen by either recognising the "rhythm" in which sounds appear and/or recognising different tones.

As a first step, my idea was to write a logger that plays different beep sounds for different log levels. That way you could mostly identify the “rhythm” because I guess most log messages would have the same severity. However, to a tiny degree also by the pitch of the sound.

Then as a second step I thought of mapping the log message to a scale of sounds by e.g., hashing the message. This obviously would only work if there’s no dynamic content in the message.

It’s just running a very lightweight libp2p host that speaks the DHT protocol. It’s basically just taking the bare minimum part of Kubo (IPFS) that’s necessary to interact with the DHT.

It’s then relying on the rest of the IPFS network to propagate the record for discovering the sender and receiver.

Hi HN,

during December 2022, we are running a measurement campaign to investigate decentralized NAT hole punching success rates using the libp2p DCUtR protocol [0]. Ubiquitous peer-to-peer connectivity is still a big challenge. If successful, NAT Hole Punching can be a game-changer for decentralised applications and networks!

For that we are searching for participants who would run a lean client on their machines that performs hole punches with other peers and then reports back the results to our server. We explained the measurement methodology in this video [1] and the linked repository above.

Running such a client certainly has privacy implications which are documented here [2]. Most importantly, we record public IP addresses, successful NAT port mappings, and the login router page (to draw conclusions about which routers work better than others).

Optionally, you can also sign up here [3] and provide additional information about your personal network and receive a personal API key so that we can link your data to your information. Obviously, this has stronger privacy implications - but this is totally optional.

The most frictionless way to participate is to head to the releases page [4] and download a client that suits your platform and needs. No sign-up required.

[0] https://github.com/libp2p/specs/blob/master/relay/DCUtR.md

[1] https://www.youtube.com/watch?v=fyhZWlDbcyM

[2] https://discuss.libp2p.io/t/call-for-participation-nat-hole-...

[3] https://forms.gle/h1ABCpS87jYmg9a48

[4] https://github.com/dennis-tra/punchr/releases/tag/v0.9.0

This post resonated with me and the inconsistencies certainly don’t add to the already bad discoverability of CLI arguments. Personally, I find using -h/—-help the most sane way (YMMV).

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development).

[0] https://multiformats.io/

What a coincidence, just today I had a conversation about the decreased quality of Google’s search results. Glad, I’m not alone.

I’ll give you.com a full weeks trial as it wasn’t mentioned that often in the comments yet.

Their CEO is following the twitter thread [0] and comments here [1] but is probably hesitant to advertise it here on HN.

So, I’m doing it now as I have high expectations. I’m not affiliated in any way.

[0] https://twitter.com/richardsocher/status/1477748601539411971...

[1] https://news.ycombinator.com/threads?id=richardsocher#293994...

Could you elaborate why you don’t think it’s a good idea?

I think the author made clear why he/she thinks it is.

Exactly these kind of posts are what is needed for technologies like IPFS to gain traction. Tinkering, trying, sharing, one step at a time.

I’m glad the author shared his/her journey to scratch an own itch - which I believe is valuable for more.

Magic wormhole isn’t strictly peer to peer nor uses WebRTC as the traffic is routed through a relay server. This was my motivation to build one of these hundreds file sharing tools [0]. My aim was to build a truly decentralised file sharing CLI as basically a drop-in replacement for croc/magic-wormhole - so it seems relevant to mention it here. It’s based on libp2p and comes with its own trade offs.

lotharrr (the author of magic-wormhole) gave kind and valuable feedback when I posted it on HN [1].

[0] https://github.com/dennis-tra/pcp

[1] https://news.ycombinator.com/item?id=26127923

There is a server involved for mediating peer discovery but the file transfer itself is p2p.

Regarding your second point: I’m actually not sure if the file is copied into memory or if the browser just keeps a reference. I haven’t tried it with large files yet.

I really enjoyed learning about all the concepts [0] and it's amazing what libp2p is doing for you behind the scenes - I'm thinking especially of NAT handling and relaying.

I think the APIs to have simple, sequential request/response communication with a peer could be easier. How to close communication and be sure data was received by the peer was also a tricky one. Just because you have written the data to the libp2p stream doesn't mean it was transferred to your peer. So I was continuously closing the stream too early, which resulted in data loss. Took me a little while to figure this one out.

I can recommend having a look at the examples [1] if you're planning to build your project in Go. They helped me a lot to understand how the APIs are supposed to be used. At a few points there outdated though - especially how to close streams (I just saw the examples were updated 2 days ago, so this is probably an outdated statement).

[0] https://docs.libp2p.io/concepts/ [1] https://github.com/libp2p/go-libp2p-examples

That's indeed correct and was exactly what I meant with

I haven’t covered edge cases

So, thanks for your suggested solution! I think that's how I would implement it as well.

The receiver looks for two windows and the sender broadcasts new entries when 5min are over.

The Public-Key verification was intended as an additional sanity check and I considered it not secure enough to just rely on it alone - so I added the PAKE step as well.

As lotharrr mentioned other flaws, you may want to check out his suggestion which seems like the way to go for me. This to eliminates this "sanity check" step all together.