TheFlyingFish

Threading in group IM's seems to be one of the more polarizing UX discussions that I've come across. A while back I was reading some of the discussions the Matrix people were having about implementing a threading model, where it became clear that there were three very distinct ideas of "good threading" floating around:

1. Infinitely-nestable threading, a la Reddit and HN (and probably other sites first, but those are the ones I've used it the most)

2. Single-level nested threading, a la Slack (and maybe Facebook? I forget how much nesting they allow)

3. Discord/IRC-style replies (like you mentioned) where the responding message just quotes the original, possibly with a slight UI indication to make it easier to parse.

I guess you could argue that Zulip-style threading is a fourth option, but IMO that's closer to a bulletin board than a group IM, because you can't have a message that isn't in a thread, so almost no discussion happens at the top level of a given channel.

What's interesting to me is that the split between who prefers which style of threading is pretty close to even.

I suspect, although I'm not sure, that it comes down to two things: the size of the groups in which you normally participate, and how closely-knit they are. A small, closely-knit group would likely prefer Discord/IRC-style threading, because sub-discussions are more likely to be of interest to those not participating, and the added noise isn't too big of a deal if the group is small.

A larger, but still closely-knit group would probably prefer Slack-style threading, because even though sub-discussions might still be interesting to more than the immediate participants, but a single message space starts to become unusable with more than a couple of sub-discussions going on.

A large and loosely-knit group is is likely to prefer Reddit/HN style discussions (and in fact those are two examples of large and loosely-knit communities) because a sub-discussion is less likely to be of interest to a significant portion of the main discussion's participants.

Maybe, at least. It would be interesting to do a poll and see how those factors correlate.

> Actively processing voice on someone else's tempo over a crappy mic often leads to mistakes

On the flipside, text-only conversation often simply doesn't include that nuance at all. I can't count the number of times I've completely misunderstood someone's tone over text when it would have been blindingly obvious over voice. Key and Peele even did a skit about it: https://www.youtube.com/watch?v=naleynXS7yo

Voice and text have different strengths and weaknesses as communications media. Both are appropriate in different situations. I will admit, however, to being somewhat "allergic" (as another commenter put it) to voice, probably to an unreasonable extent, because I selfishly value my ability to focus on what I'm doing right now instead of giving it to someone else for a couple of minutes.

But at the same time, I've often found that someone older who didn't grow up with easy text-based communication will use a phone call when a text would have been more than sufficient, and this can be quite irritating at times. I suspect it's in reaction to this that younger people tend to avoid voice communication even when it would probably be a better choice.

I feel like I'm missing something here. It seems like ECH is still vulnerable to a MITM attack, allowing the attacker to see what SNI destination the user is attempting to connect to. I'm imagining something like this:

Client sends ClientHelloOuter, with encrypted ClientHelloInner.

Malicious MITM replaces ClientHelloInner with malformed data so that decryption will fail.

Server sees that decryption fails and proceeds with the ClientHelloOuter handshake, sending back the correct public key.

Since this message is (from what I can tell) in the clear, the MITM can replace the public key with its own public key.

Client then retries with a new ClientHello, containing a ClientHelloInner encrypted with the attacker's public key.

Attacker decrypts ClientHelloInner, re-encrypts with the server's real public key, and forwards. The attacker is now able to listen in on SNI, ALPN, etc, although the HTTPS traffic itself is still protected as the attacker can't forge the certificate.

This seems like a fairly trivial attack, which is why I think I must be missing something. How does ECH prevent an attacker from swapping out the server's public key with their own, in the event that the first ClientHelloInner fails?

I think the previous comment was taking issue with your use of the word "violently."

I think it does do that, actually. Definitely better in that it can be used without internet access, but I will admit that I have been guilty of thinking "if I'm going to be opening a browser anyway, might as well just google the question and get more targeted help."

That's awesome, glad to hear it! Sounds like a really positive development for long-term viability.

Just out of curiosity: the press releases I've seen about these big government players switching to Matrix generally mention that they're using a customized client of some sort. That's understandable, but what I want to know is: Have they also customized the underlying protocol by which their homeservers communicate?

The reason I ask is that it seems to me (as an entirely uneducated outsider) that if they're using the Matrix protocol as-is, then they have incentive to support and assist with the further development of the Matrix protocol, which is great. But if they've already started customizing it, then I would worry that they eventually will decide they don't need Element or the main Matrix protocol and will just go off and do their own thing.

I'm not as sure about that, given the extent of the chaos that ensues every time S3 goes down for half a day.

The announcement briefly mentioned that they are working on a "super resolution" feature, but specifically what that is has so far been left as an exercise for the viewer. It sounds like it might be a competitor for DLSS, but only time will tell.

FF defaults to DNS-over-HTTPS now, so I would imagine it does, although I can't find solid confirmation.

I've tried both. I ended up going with Tailscale because:

- Better throughput overall.

- better NAT holepunching. E.g. ZeroTier gives up entirely with "symmetric NAT" where each outbound connection gets a random source port, but Tailscale has a few extra tricks that it can try (including opening a whole bunch of outbound connections, trying ports at random, and hoping the birthday paradox will kick in, which I think is pretty cool.)

- But most of all, Tailscale didn't suffer from weird intermittent throughput/latency issues between different cloud providers the way that ZeroTier did. Sometimes my machines could talk to each other pretty fast, other times it was clamped down to ~10 MB/s for no apparent reason. Sometimes it only showed up in one direction, sometimes both. I gave up on trying to troubleshoot it when I discovered Tailscale.

That said, I still like ZeroTier a lot and think it's a great project. It also provides a whole LAN layer, with stuff like actual broadcast traffic, for which Tailscale has no equivalent.

The GPL, in particular, goes further than just refusing to exercise your copyright over a piece of software. The GPL restricts the usage of your software, most notably by forbidding its use as part of any proprietary software. Without copyright no one would have to respect that restriction.

The situation you are describing is closer to a project with an "unlicense," e.g. SQLite, which explicitly makes the project public-domain and places no restrictions whatsoever on its use.

I think it's that JS has no standard library, so dependency graphs are an endless fan-out instead of fanning back in after a while. That's how you end up with 900 dependencies after importing a single Node module, because every author of every upstream lib chose a different way of doing the same thing.

To add to this the Node ecosystem seems somehow to encourage outsourcing extremely simple pieces of functionality (leftpad anyone?) so you end up including a bunch of crap that you don't really need, all because someone didn't feel like using 10 lines to reimplement something simple.

Personally, I'm more comfortable with a service that has entire teams whose entire job is finding and fixing holes in the service than I am with something I toss on a server somewhere and forget about for months at a time.

Realistically, which is more likely? 1) That 1Password gets breached and loses their customer information, or 2) that I install Bitwarden on my server, somebody discovers a hole in it, I don't hear about it for a while (or do but don't have time to update), and get all my passwords stolen?

For me, the second seems more likely, so I'm happy to stick with 1Password.

A little different from posters, but if you're looking for something a little more durable I've had success with CanvasChamp for canvas wraps: https://www.canvaschamp.com/

In comparison to other sites I've used their framing is much more sturdy. Never had any issues with flexing or anything. Good quality printing, and very

Are you on IPv6 by any chance? I got the same thing, despite being in SoCal. I saw that the site was showing my IPv6 address, so I checked a couple of location databases and I'm getting results that are way off. A couple say New Jersey, one says "North America" and leaves it at that. I think that might match whatever Cloudflare is using since the dot is just in the middle of the US, i.e. Kansas.

Regardless, it's showing me as connecting to the LA server, which is almost undoubtedly the clostest PoP, so I'm not too concerned.

I think the unit is just one of those weird dimensional equivalences that pop up from time to time. E.g. fuel efficiency in cars is measured as distance / volume (of fuel consumed), so it's dimensionally equivalent to area^-2. But we don't use this because "1 mile per gallon" makes a lot more sense than "42.5 cm^-2".

Just anecdotally, I wouldn't be surprised if a Camry really were "more valuable" (as measured by some sort of ideal fixed value-marker not subject to inflation) than in 1990. I seem to recall when I was growing up that the average expected lifetime of a car if well-maintained was about 100k miles; now it seems to be about 200k.

Housing may be a more debatable case, though.

The Windows port of OpenSSH does this too, now. It backs its version of ssh-agent with the windows credential store so that you don't have to type any more passwords after you login.

There are at least a couple of major upgrades to US testing capacity in progress from Roche[0] and Thermo Fisher[1].

[0] https://www.npr.org/2020/03/13/815522836/u-s-coronavirus-tes...

[1] https://www.statnews.com/2020/03/14/thermo-fisher-to-produce...

>It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants.

Reminds me of the fairly prescient "In Praise of Evolvable Systems" essay from 1996: https://web.archive.org/web/20190409041249/http://www.shirky...

An interesting takeaway from the comparisons shown is that AVIF seems to be much better about getting rid of detail without creating artifacts. It's particularly evident in the second example photo, where the original has a lot of detail in the texture of the paint on the door. AVIF drops most of that detail and gives it a smooth, almost airbrushed look. It's obviously missing a lot when you compare it to the original side-by-side, but on its own it doesn't look immediately repulsive.

To me, this absolutely screams "mobile," as on a small screen you probably wouldn't be able to see much of that detail even if it were technically present. I wonder if in the future we'll see some sort of mechanism for progressive image loading that allow the client device to choose its own level of compression, possibly based on server-provided hinting or something.

It actually improves performance. Or at least, it comes along with a set of performance improvements that give you ordering for free. Raymond Hettinger has a great talk on it: https://www.youtube.com/watch?v=npw4s1QTmPg&t=1s

That's what I want to know. I would assume the article is talking about monitoring which IP's request which domains, but the overwhelming majority of requests that a registry sees have to be from downstream resolvers, right? In which case they don't know who's using the site, they only know that "somebody who uses this resolver" is using the site.

In most cases there are probably multiple levels of resolvers, so it might even be as coarse as "somebody on the west coast of the US is using this site," which isn't terribly useful.

On at least one memorable occasion [0], he expressed surprise that the developer(s) responsible for some piece of code had survived to adulthood, considering they "were likely too stupid to find a tit to suck on" as a baby. I'm not super aware of the context here, but at first glance it doesn't appear to be a high-profile coder with lots of kernel experience that he's talking about.

[0] https://lkml.org/lkml/2012/7/6/495

I really only have two questions about this case:

1) The US legal code explicitly excludes "methods of operation" from being copyrightable. Does an API count as "methods of operation"? And if so, what ground does Oracle have left to stand on?

2) If this case goes Oracle's way, does this set the precedent that ANY re-implementations of an existing API are in violation of copyright? I don't know who now owns the original rights to Unix, but if they decide to come after Linux where does that leave us?