Ingon

4-week battery life, if you don't go outside. Solar charges the watch relatively slow (e.g. it takes 3 hours of just sitting under the sun to charge a day), but if you get out frequently it just pushes the battery day just a little further. Funny experience, when I charged it the first time and got outside in the sun, it showed infinity days battery remaining :D

I also appreciate that most of the data is available right there on the watch (although sometime buried). And I even used the torch a couple of times!

I've been running GrapheneOS for over an year now. Bought a Pixel 6a last year as a cheap way to test waters, but pretty soon I upgraded to discounted Pixel 9. It took a while to set the basics (coming from iPhone), and I'm still have a couple of stuff missing, but at this point don't intend to use anything else (for as long as possible).

The biggest hurdles for me were - should I use separate profiles and how to get apps. Initially, I started with a separate profile for google stuff (like play store/services and apps downloaded from there, like Viber), but eventually I moved everything to the owner profile (and took a bit of a privacy and battery hit in the matter of convenience). Still, being able to control many app permissions, gives me a good state of mind that apps are not doing more then I expect.

Just looked at what android 17 brings to the table and I'm mildly excited - especially improving performance and adding more permissions (like ACCESS_LOCAL_NETWORK)

Amazing, congrats on the release.

I've been drawing a lot of inspiration from Iroh, while working on my own https://github.com/connet-dev/connet. While peers in connet communicate peer to peer, I have a long way to cover peer discovery and transparent connection migration.

"Tailscale at the application layer, instead of the network layer" (as sibling comment describes it) is a great way of thinking about it. In my mind, with the right apps, Iroh (and connet) could really democratize secure self-hosting.

I've been working on a similar tool for a while - connet (https://github.com/connet-dev/connet). It builds upon QUIC (instead of wireguard), but I think from an enduser perspective the results ends up looking pretty similar.

Termux is great - one of the ways I use it is to install the golang toolchain and compile/run connet.

I'll take a look at what twingate does for sure, thanks for pointing that out.

A few things that worth mentioning for connet's current state - you can technically bind to any local IP, not just loopback (or listen to them all). You also have the option of directly running a TLS/HTTPS destination (for mutual TLS directly to the service) or source (e.g. for mutual authentication between your local listener and the outside world). Another option is to build your own client and define how you want to source traffic - maybe its part of your app and there are no sockets or anything - you just connect and start talking.

I've been thinking a lot about this case specifically. And you are right, phones are largely not supported right now - I've been researching how to make that happen. One case I've found that works for me currently is running connet via Termux - and I've made the necessary changes to support that.

Native iOS/Android clients, if possible, will probably be the next things I'll work on. At minimum they should enable you to run a "source" (e.g. a consumer of an exposed service), but ideally it will be the whole deal.

I've been working for a while on https://github.com/connet-dev/connet. It gives a different twist at the same problem - instead of an overlay network at L4 (wireguard, etc) or publicly accessible endpoint at L7 (like ngrok) it "projects" a remote endpoint locally (e.g. as if you are running the service on your computer). Of course "locally" can always be a VPS that has caddy in front to give you ngrok-like experience.

The reason connet exists is that nothing (at the time I started, including netbird, tailscale/headscale, frp, rathole, etc) gave the same easy to understand, FOSS, self-hosted, direct peer-to-peer way of remote access to your resources. I believe it does accomplish this and it is self-hosted. And while a cloud deployment at https://connet.dev exists, it is nothing more then repackaging the FOSS project with user/token management.

connet [1] works in p2p fashion and is pretty quick if it can establish direct connection. Most other solutions do route through a separate node, so if your direct to node latency is low it should be comparable to directly hitting that node. It also has a docker release on ghcr. There is also a saas version [2], if you just wanna try it without running the control plane.

[1] https://github.com/connet-dev/connet

[2] https://connet.dev

Continue to work on my project for remote private access: https://github.com/connet-dev/connet

Just released v0.12.0 which has a lot of package cleanup and some important bugfixes. Next, is making the relay infrastructure much more lighter, requiring less synchronization.

Personally, I'm using the hosted version[0] (which is just a repackage of the open source version with dynamic with tokens) to expose my NAS and syncthing web UIs to manage them while I'm away. Sometimes even through my phone (with termux)

[1] https://connet.dev

Actually, I realized that I've used `/s` incorrectly. I've been thinking about rewriting the clients in Rust, mostly to allow simpler embedding in other languages - java and swift for example (I think it would be great if connet was available on mobile - for android you can Termux to compile/run it, but it is a pain). This will make it harder to embed in golang tho.

Another option is to try to rewrite clients in each of the language, but most fare poorly on QUIC support - in Java for example, I'm not aware of one that is advertised as production ready (looking at kwik with their fork of TLS).

https://github.com/connet-dev/connet

Just finished a major (v0.10) revamp of the API (you can use connet as part of an application, not through the CLI) which also fixed a few issues I've been seeing before.

Now, I'm gearing to update the relay protocols - currently relays are closed off by the control server (e.g. you ask it to provision you a relay resource) which requires the relay to communicate with the control server itself. In the new version, the relays will be operating on their own (there might be a shared secret with the control server, in case you want a closed off relay) and peers will reserve directly with the desired relays. Maybe in future, the relays might form clusters on their own to take advantage of better relay-to-relay network and peers will reserve only at the relay closest to them.

Another stream of work, is giving peers identities. Right now the server will give them an internal identity to better support reconnects, but these are not stable (e.g. they don't survive client restarts). In future, the peer will advertise their identity and then other peers may choose what peers to allow comms with and what to ignore, pushing more decisions into peers themself.

Yet another change I'm thinking about is exposing raw endpoints to enable users of the system to implements other protocols - I'm not quite sure if this is really needed (the destination/source, e.g. server/client) covers a lot of ground by itself, but it would be great if these are not the only options.

Many options how to continue, but if I'm out of ideas, there is always a Rust rewrite to throw in /s

I am excited for having a new version of NixOS. Few days ago I realized that November is almost gone and went looking for when I can expect the new release. And right on schedule it popped out (was checking throughout the day). Big props to the release managers (and of course the maintainers)

I use nix via flakes on my own machines (via NixOS), in my projects (with direnv), on my infrastructure/servers (NixOS deploying with colmena) and at work (nix-darwin and projects). So far the upgrade have gone painlessly, the only change I needed to make is how git is configured in home manager. I continue to be amazed how well NixOS works.

Edit: The only place I still struggle in adopting nix is on my phone. Last time I tried nix-on-droid it didn't even run, but I plan to try that again. Still new to Android (and GrapheneOS)

Tunneling p2p with relay fallback is essentially what connet [1] aspires to be. There are a lot of privacy/security benefits exposing endpoints only to participating peers. You can either run it yourself or use hosted version [2].

[1] https://github.com/connet-dev/connet

[2] https://connet.dev

Been using profiles for some years now and they are great. I usually start with the default profile, then navigate to "about:profiles" to open all I need. Thanks to profiles, when my manjaro install broke, I migrated to NixOS and all my browsing sessions were ready to use the way I left them. Getting a dedicated, more integrated UI for managing profile will be great.

The one thing I'm missing is "incognito" profiles - e.g. spawn a temporary profile (without any identity attached) easily when I'm researching/navigating unusual sites and kill it once I'm done. Having multiple of these would be a great improvement over normal incognito windows (which share identities).

When I adopted mmap in klevdb [1], I saw a dramatic performance improvements. So, even as klevdb completes a write segment, it will reopen, on demand, the segment for reading with mmap (segments are basically part of write only log). With this any random reads are super fast (but of course not as fast as sequential ones).

[1] https://github.com/klev-dev/klevdb

I also started self-hosting more and more. But instead of making services available on the internet/intranet (e.g. VPS reverse proxy/tailscale), I'm binding them to localhost and using connet [1] (cloud or self-host [2]) to cast these locally on my on my PC/phone (when I need them). These include my NAS and Syncthing instance running on my NAS and I'm looking to add more.

[1] https://connet.dev

[2] https://github.com/connet-dev/connet

I used QUIC extensively to implement https://github.com/connet-dev/connet and while I'm super happy with how it turned out, I think QUIC currently suffers from some immaturity - most implementations are still ongoing/not production ready (for example in java) and in many cases it is only viewed as a way to power on HTTP/3, instead of being self-standing protocol/API that ppl can use (for example, trying to use quic in android).

In any case, I'm optimistic that QUIC has a bright future. I don't expect it to replace TCP, but give us another tool we can use when it is called for.

In some ways this reminds me of what I'm trying to do with connet [0] - give users the choice to completely self-host (all is open source), identity host (e.g. control server as cloud solution, host relays themselves) or even full cloud [1].

[0] https://github.com/connet-dev/connet

[1] https://connet.dev

I have to double check, but I believe this is server-side/exit node configuration. In case of mulvad, something similar might be on their servers.

Endpoints visible to the internet is one of the main reasons I created connet [1] - with it you can choose when and where to realize the other end. Another benefit is that endpoints talk to each other directly (under many conditions) without traffic ever hitting the cloud.

[1] https://github.com/connet-dev/connet

Thanks for the correction, I'm still new to iroh and looking to learn more!

Seems that the relays in iroh play the role of STUN and TURN (maybe even implement these)?

I'd have to read more about DNS discovery (and dht), very interesting.

I work on connet [1] and from what I've seen iroh seem pretty cool. A few random thoughts I had while watching the presentations/reading the docs:

* the relays serve both for discovery and relay. In connet these are separate responsibilities, e.g. it has control server for discovery and a relay server for relaying connections.

* it seems that the connections to the relays in iroh are TCP (at least what was said in one of the videos), while connet uses QUIC in all cases. This probably makes iroh more resilient, but multiplexing on top of TCP might suffer from head of line blocking.

* it is pretty cool that iroh can seamlessly upgrade from relay to direct connection, connet doesn't do that on a connection level. It will however use direct in the subsequent virtual connections.

* using ALPNs for protocol selection is pretty cool, connet only offers "virtual connections" protocol, where one of the peers is "server" and the other is a "client".

* since there is a separate discovery server (with auth), in connet the endpoints are named separately with logical names, they don't represent peers necessarily. Because of this, you can have multiple peers with "server" role and "client" roles.

Anyhow, thanks for posting this, iroh looks great and I will draw some inspiration from it for sure.

[1] https://github.com/connet-dev/connet

Looks very cool. Another self-hosted, open source, and private solution in this space is my own https://github.com/connet-dev/connet/

connet itself doesn't have a notion of public share at all - you need clients/peers on both ends (destination and source) to "project" a remote service. connet.dev do enhance this, by running the source clients publicly, but you need to specifically enable this, and it is best used as a break-glass option, since obviously makes things less-private.

In any case, zrok.io is cool, it is certainly more mature and feature rich project.

If I understand correctly the terminology/case, all shares in connet a private. You access a remote resource as it was local, but that doesn't mean the resource is publicly visible. For example, my local network clients, do not need public IP or special firewall rules to communicate with remote clients.

What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers.

Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.

Thanks, it would be great to hear if you tried connet and how it went!

In any case, homegrown solutions are great, they offer the most flexibility, but also require the biggest time investment (and knowledge of course).

Very cool comparison, thank you!

One new feature I haven't highlighted yet, is that you can, in addition, encrypt traffic as it goes through relays (both via tls or noise-inspired protocol, dhxcp). This enhances privacy, even when you are using public (e.g. not owned by you relays), covering a case like https://connet.dev nicely.

Hi All,

This is a hosted version of connet[1]. In addition, it allows users to expose their endpoints directly on the internet (optional and still in progress)

[1] https://github.com/connet-dev/connet

Still working on Connet[1] and the associated Connet.dev[2], which is a p2p reverse proxy with NAT traversal (and hosted version of it). Currently, adding support for defining multiple points of ingress, next will be adding support for PCP port forwarding.

[1] https://github.com/connet-dev/connet

[2] https://connet.dev