Comments URL: https://news.ycombinator.com/item?id=48117235

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48037563

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48035788

Points: 1

# Comments: 0

Two related contexts that I've found to be much more friendly for this:

1. Climbing gyms, for reasons mentioned previously

2. The sauna! Actually very ideal for convos with strangers. Max overlap time is ~15 minutes, people are generally relaxed, no phones to distract and if it doesn't go well either party can always leave.

Kudos to Rivian for making this a supported user privacy feature.

We've switched to CDC using Postgres which emits into another (non-replicated) write-optimized table. The replication connection maintains a 'subject' variable to provide audit context for each INSERT/UPDATE/DELETE. So far, CDC has worked very well for us in this manner (Elixir / Postgrex).

I do think soft-deletes have their place in this world, maybe for user-facing "restore deleted" features. I don't think compliance or audit trails are the right place for them however.

If the source code is available for you to fork, modify, and maintain as you see fit, what's the complaining really about?

Comments URL: https://news.ycombinator.com/item?id=42675445

Points: 3

# Comments: 0

libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity.

[1] https://datatracker.ietf.org/doc/html/rfc8445

[2] https://github.com/pion/webrtc

[3] https://github.com/algesten/str0m

[4] https://libp2p.io

Some misbehaving networks drop WireGuard packets either by accident or on purpose. Commonly the latter is done with simple DPI rules that block the handshake initiation [1], but it could be applied to other message types as well.

We thought it would be great if there was tool for folks to use as a quick litmus test to see if this happening for them, without having to configure a client to send data through a random, functional WireGuard tunnel to an untrusted remote host. So we built probe.sh.

How it works:

- The probe.sh web app is an Elixir Phoenix app that spawns a few gen_udp servers across a variety of common UDP ports. - When a user visits the app, Probe starts a LiveView process and generates a unique cryptographic token to use for the test. - When the user runs the script shown, it first sends an HTTP request to start the test, followed by a series of UDP payloads, and finally either a complete or cancel request to end the test. - The UDP payloads are crafted to resemble real world WireGuard packets and sent with widely available tools like netcat (Unix) and System.Net.Sockets.UdpClient (Win) already on your OS. - The gen_udp server receives these payloads, and if they match one of the four WireGuard message types by header, it broadcasts test updates to the LiveView process for that test, and the test is marked as success. - The user is immediately shown the results of the test.

The entire tool is open source at https://github.com/firezone/probe (README contains guide for self-hosting) and you can find a FAQ with more useful info at https://probe.sh/faq. You can also see our tally of global results organized by country: https://probe.sh/stats

We hope you find it useful for testing your network for WireGuard connectivity issues.

Thanks for reading - feedback welcome!

[1] https://x.com/6h4n3m/status/1459462360003919875

Comments URL: https://news.ycombinator.com/item?id=41205141

Points: 43

# Comments: 10

We do have a self-hosted community support channel on Discord if you are feeling adventurous: https://discord.gg/DY8gxpSgep

I would recommend starting here with a local development cluster:

https://github.com/firezone/firezone/blob/main/docs/CONTRIBU...

https://github.com/firezone/firezone/issues/3553

We didn't invent these techniques. Host candidates are part of standard ICE:

https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.1....

It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone

In terms of attributes for allowing access, we currently support time-based, country/region-based, auth method, and IP-based, with more planned: https://www.firezone.dev/kb/deploy/policies#conditional-acce...

Erlang/OTP has so far been an excellent platform to build on for a product like Firezone. We chose it specifically for its reputation for powering soft realtime systems. Phoenix Channels are an added bonus that allow us to push all updates where they need to go, in just a few hundred lines of code.

We couldn't be happier with the stack choice.