HackerLangs
TopNewTrendsCommentsPastAskShowJobs

b_fiive

no profile record

comments

b_fiive
·geçen ay·discuss
sup steb, this is expede's work!
b_fiive
·4 ay önce·discuss
Now, see. that's what I said as well. But the rest of the team was tired of me trying to name the hosted iroh "n0des", which I'm now ready to admit was a stretch. And so now here we are spelling n0q as noq. c'est la vie.
b_fiive
·4 ay önce·discuss
It's been a draft for a long while, and was only recently approved
b_fiive
·4 ay önce·discuss
disclosure: I work on the team behind noq. Can't emphasize enough that the quinn maintainers are really lovely people, and quinn is an excellent project.
b_fiive
·5 ay önce·discuss
worm-blossom crew is just a delightful bunch of humans doing really great work
b_fiive
·9 ay önce·discuss
delighted to hear! iroh-blobs is Rüdiger's love letter to BLAKE3, and hot dang has he taken this piece of machinery quite far. Much of this is covered in the post, but some highlights:

* fetch any sub-sequence of bytes, verified on send & receive * fetch sub-sequences of bytes in collections (sets of blobs / directories) * store on disk, inlining small blobs into the database for faster lookups * fan in from disk & the network * "multi-provider" fan in that can re-plan a fetch on the fly * should land support for WASM compilation (browsers) soon! https://github.com/n0-computer/iroh-blobs/pull/187

We're hard at work on making the API more ergonomic, but as a foundational protocol it's truly impressive. Rudi has been working with the BLAKE3 authors on both perf testing & the hazmat API.

disclosure: I work on iroh
b_fiive
·geçen yıl·discuss
less configuration. more reliable. less pure p2p (iroh uses relays)
b_fiive
·geçen yıl·discuss
ah very sorry, I can see how this isn't all that clear. In the comment you've mentioned when I say "custom protocol" I mean a custom QUIC ALPNs: https://datatracker.ietf.org/doc/html/rfc7301

When we talk to mainline it's for discovery, which is separate from iroh connections, which always uses QUIC. Specifically: our fork of quinn, an implementation of QUIC in rust. Iroh is tightly coupled to quinn, and isn't swappable. Getting no_std support for us basically boils down to "can we get quinn to support no_std?". For that, see: https://github.com/quinn-rs/quinn/issues/579
b_fiive
·geçen yıl·discuss
yep totally doable. You'd use iroh configured with mainline, Then write a custom protocol for the grpc bit: https://www.iroh.computer/docs/protocols/writing

We use this a bunch for writing rpc protocols on iroh: https://github.com/n0-computer/irpc , but there's no reason you couldn't write one with grpc.
b_fiive
·geçen yıl·discuss
keys are always ED25519, we use raw public key bytes, without prefixes.

Applications are more than welcome to use prefixes, but the use of ED25519 is not configurable
b_fiive
·geçen yıl·discuss
Yeah, no_std is going to be very hard. We need a no_std implementation of QUIC that can be wielded by mere mortals first, which I don't think we'll be able to start on for at least a year.

Right now we can get down to an ESP32, which we think is a decent start.
b_fiive
·geçen yıl·discuss
There's no reason this _can't_ be built. The thing that's missing is simulating a raw UDP socket.

We could adapt the pattern from dumbpipe wrapping a TCP listner: https://github.com/n0-computer/dumbpipe?tab=readme-ov-file#t... which is exactly the "here join this ticket" you're describing
b_fiive
·geçen yıl·discuss
(disclosure: I work on iroh): you're selling yourself short! All of this is accurate, except for maybe the BGP stuff :)

Dumb Pipe & Sendme me are indeed demos, we do provide a set of default, public relays to use for free. The relay code is also open source, and if you want to pay us we can run a network for you.

We try to provide a few different options for discovery, the one we think has the most general utility is a custom DNS server, but both local mDNS and Bittorrent Mainline are also pluggable options.
b_fiive
·geçen yıl·discuss
hey I work on this! AMA!