@fuesstest @Hughenknubbel @thomas Wobei es genügend kaputte Android-ROMs gibt, wo auch Push-Notifications die App nicht wecken (sofern sie nicht auf einer ggf. vom Hersteller hart kodierten Whitelist ist).

@f2k1de @raketenlurch Komme aus der XMPP-Ecke und blieb da bisher u.a. deshalb weil ich Riot immer zu Slack-like fand ums Leuten als WhatsApp-Ersatz andrehen zu können. Pattle sieht auf Screenshots passender aus, aber dunno ob das schon benutzbar ist ...

@waweic Bist nur nicht geübt. Neulich einer Bekannten was auf meinem Handy gezeigt, irgendwie drauf gekommen dass bei mir keine Werbung in der App zu sehen ist. Sie so "bei mir auch nicht". Ich so "denke doch". Sie öffnet die App, Ads springen einen an, sie so "huch, mir nie aufgefallen".

In case any Erlang people happen to be interested in straightforward support for systemd's notification/watchdog features:

gist.github.com/weiss/8ee73f83

@technicallypossible Didn't get that far. I was trying to debug a filtering function that checks whether and how a given message is to be logged. So I just burnt CPU.

Note to self: Logging a message from a function that handles log messages is not that much of a great idea.

@mittorn @a1batross So modern clients usually just perform a single STUN request, let the peer try to connect to the returned address, and fall back to TURN if that fails. Therefore, the NAT behavior check was removed from the newer STUN RFC (5349). There's a separate RFC (5780) which brings it back as an add-on, but it doesn't solve the problems (it just acknowledges them), and I don't think it's being used much.

@mittorn @a1batross One problem with this NAT behavior check is that it's not reliable: If the STUN queries return the same external IP address, the client still cannot be sure the same address would also be used for connections from/to the peer's client. Another problem is that there's simply not much point in determining the NAT type beforehand, even if the check was reliable. Either STUN works or it doesn't, in which case you typically want to fall back to TURN.

@mittorn @a1batross Therefore, the "classic" STUN RFC (3489) had the idea of binding the STUN server to two or more addresses in order to let the client figure out to the NAT type: The client perfoms STUN queries against different STUN server addresses and if the responses differ, things look bad.

@mittorn @a1batross Long story: The main purpose of STUN is to let a client that sits behind a NAT figure out its public IP address. Usually with the goal of establishing a p2p connection with another client. This will often work, but not under all circumstances: There are NAT types where the client's public IP address depends on the target IP address. So the external IP address as seen by the STUN server might be different from the external IP address the peer's client could talk to.

@mittorn @a1batross Short story: There's usually not much point in binding STUN servers to multiple IP addresses these days.

@leip4Ier @izaya There's obviously other software that just works, but I can totally sympathize with a special appreciation of OpenSSH. It's one of the most critical pieces of userland software for many of us, and the OpenBSD people really got it right, despite it being absolutely non-trivial to get right.

FWIW, we (pre-)released a new piece of TURN server software today:

eturnal.net

Holger boosted

@0 @stevenroose You sound like I'm an XML/XSD fanboy. I'm just not into bashing it blindly ("so glad it's almost dead") as long as there's no obvious alternatives for the use cases where XML makes some sense.

@0 You just don't get the point. The browser's lock icon is green.

Show more
\m/ Metalhead.club \m/

Metalhead.club is a Mastodon instance hosted in Germany and powered by 100% green energy.