dennis-tra

Content-addressing decouples the hoster from the data itself. Anyone can serve content-addressed data and you can locally verify that you’ve got served the correct bytes. IPFS implements building blocks for such an alternative web.

What irony that this article is about crawling content-addressed data.

> There are no written documents, it’s only that a boat landed there hundreds of years ago

Talking about Kiel, the non existent document was signed there: https://en.wikipedia.org/wiki/Treaty_of_Kiel

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.

I’d like to add

  please = push —-force-with-lease

for rebase-heavy workflows

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.

I’m currently working on a new version of pcp [0]. Based on croc, magic-wormhole and the likes it doesn’t require a relay. It uses the IPFS DHT as a discovery point to connect two machines. Haven’t touched the currently released code in two years but the new hole punching capabilities of libp2p show promising result so I’m working on a new version.

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

It’s gone from the ipfs.io gateway but the CID is still available in the network. Take your own IPFS node (e.g. companion or Brave’s built-in) and you should be able to resolve it

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

A few months ago I built a CLI frontend for Hashicorps shamir secret sharing implementation in Go. You can find it here: https://github.com/dennis-tra/shamir

It combines the two separate commands in the article into one.

Sorry, you’re totally right, I just quickly searched for “photopea source” and found the github page.

If you’re happy with the feature set of ~Photoshop CS2 you may want to check out Photopea [0]. It runs in your browser, has a similar UI to Photoshop and (for me) has all bells an whistles. It’s also open source [1].

[0] https://www.photopea.com/

[1] https://github.com/photopea/photopea

Same here! I once came across a similar question that asked where energy goes when light red-shifts from distant galaxies.

Steganography is a very exciting topic and is not limited to image data but can also be applied to, e.g., audio data.

I’ve done something similar in the past and embedded Merkle tree nodes in an image to allow partial integrity validation. It was a fun little project:

https://github.com/dennis-tra/image-stego

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).

What makes you so certain about that? What's the relation between both?

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...

While I’m also terribly sorry for what happens in Afghanistan and think the discussion on HN will be more thoughtful than in many other places on the internet, I believe these kind of submissions don’t belong here.

https://news.ycombinator.com/newsguidelines.html

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.

A couple of days ago I’ve released an IPFS DHT crawler and named it Nebula [0] if I knew that this was such a crowded place…

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

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.

https://share.ipfs.io/#/ is also very convenient for simple p2p file transfers.

I‘ve also built a file transfer tool (CLI) with emphasis on decentralization. It’s a fully decentralized p2p file transfer tool based on libp2p:

https://github.com/dennis-tra/pcp

I‘m currently trying to make it interoperable with https://share.ipfs.io/#/ which resembles the functionality of the posted tool.

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.