dignifiedquire

tailscale also is written in go, making the integration on mobile especially, often times a lot harder and more expensive

thank you!

are we?

Which I just finished updating to 1.0. But it is currently lacking in breadth of API, so if you start using it let us know what you are missing. In the meantime https://github.com/n0-computer/iroh-ffi has the other language bindings with a more comprehensive API

thank you!

Yes, but libp2p was mainly designed around the limitations of tcp, as quic simply wasn't there yet when the design started. Iroh gets the benefit of having been designed and built from the ground up, based on quic.

I would love to see that P2P DNS you are talking about

the zen life advice will come if you use it long enough :)

Tailscale is built to be global to your device, while iroh is built to be embedded into each application. This allows application developers and users a much more fine grained and bespoke setup, than having a single global bridge.

While it doesn't solve all the issues that come up through the current segmentation, it is very much possible today to assemble components that let you forget about segmentation while you use it. And it is designed from the ground up, to use existing internet technologies, while avoiding the lock in and dependencies on browser vendors or other large players.

we have been doing this for a while now, you can find some of our highlights listed here https://www.iroh.computer/solutions

As others have already mentioned, iroh the core library and protocol is fully open source. But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.

hey, I helped make this :) will try to answer questions where I can

relays _can_ be used to resolve IDs, but so can mDNS, an email or any other form of third party channel

thanks everyone for all the love <3

[maintainer of iroh here]

we do have https://github.com/n0-computer/iroh-c-ffi which is lowlevel but directly usable from any c like language

appreciate the feedback, it was a hard decision to make, but has felt more right everyday since we made it

this would be great to have, but as we rely heavily on quic, we first need an implementation of quic in no_std which is the current biggest challenge

this made my day

While rpgp is slowly gaining support for this format (the aid users to be able to talk to anyone they want) it will keep emitting the broadest compatible format for a while by default, until the whole ecosystem has upgraded. The aggressive stance from gnupg is really hurting people and removes one of the biggest benefits of pgp, broad interop with compliant implementations.

Fun fact, the main reason I developed rpgp in the first place was to power the pgp portion pf deltachat, as we ran into the same problem of not having a good library based implementation. And spawning gnupg on a phone was never an option.

Thanks, appreciate the careful check!

This was allowed in the rust-rsa crate directly before, which is why it was introduced in that commit.

I am not sure if this is an actual issue, all auditors that looked at this so far haven’t mentioned this being a problem. But I will have to investigate what the exact state is.

I just finished implementing sha1collision detection, and it will be integrated into rpgp soon https://github.com/rpgp/rpgp/issues/293

This is the same algorithm used by git.

There are higher level implementations that use the dates on signatures to straight out reject sha1 material, but that gives only a limited protection.

it‘s not builtin, but possible to integrate with

@wiktor-k is working on a tool to use rpgp to provide a simple solution to work with smartcards