How did IRC ping timeouts end up in a lawsuit? • Hacker News Board

Re: How did IRC ping timeouts end up in a lawsuit?

#31

Post by CocaKoala » Fri, Dec 19, 2025, 6:30 PM UTC

noname120 wrote: post #25

rwmj wrote: post #11

Earlier quoted context omitted.

After "being warned of the consequences on multiple occasions the Schestowitzes never provided any witness statements" , so that's hardly Matthew's fault.

Yeah but that means that the “court said I’m right ” rhetoric is invalid. It’s as if you said that a no bill or dismissal proved your innocence: it doesn’t. Now although I have only superficial understanding of the case at stake I believe the author nonetheless (but with a weak certainty until I hear the other side).

I think it is imprecise to say that the facts were not argued - they were! As the judge writes in paragraph 58,

> The authorship or control of these accounts has consistently been strenuously denied by Dr Garrett. I have no evidence from the Defendants to support it. Instead, they necessarily rely on an inferential case built on a limited number of pleaded facts, some of which are undisputed. I consider them in turn.

There were not _witness statements_ presented by the defense in support of myriad facts, but it's not like the case for the defense wasn't made at all.

Re: How did IRC ping timeouts end up in a lawsuit?

#32

Post by nullc » Sat, Dec 20, 2025, 4:59 AM UTC

CocaKoala wrote: post #31

noname120 wrote: post #25

Earlier quoted context omitted.

Yeah but that means that the “court said I’m right ” rhetoric is invalid. It’s as if you said that a no bill or dismissal proved your innocence: it doesn’t. Now although I have only superficial understanding of the case at stake I believe the author nonetheless (but with a weak certainty until I hear the other side).

I think it is imprecise to say that the facts were not argued - they were! As the judge writes in paragraph 58, > The authorship or control of these accounts has consistently been strenuously denied by Dr Garrett. I have no evidence from the Defendants to support it. Instead, they necessarily rely on an inferential case built on a limited number of pleaded facts, some of which are undisputed. I consider them in turn.…

> There were not _witness statements_ presented by the defense in support of myriad facts, but it's not like the case for the defense wasn't made at all.

It kind of wasn't. In UK civil cases your witness statement takes the place of your testimony on the stand (only cross exam is done on the stand). Outside of your witness statement(s) the other material in your case (e.g. random pleadings and inter-parties correspondence) aren't made under the same penalties for perjury.

So if you're going to tell a bunch of lies in your case (ill advised, for sure) then you're best off to do it via all other means and avoid ever producing a witness statement.

But as a result it's also important for the judge to generally discard such positions when not supported by material attested to in a way with serious consequences.

Re: How did IRC ping timeouts end up in a lawsuit?

#33

Post by oooyay » Sat, Dec 20, 2025, 11:10 AM UTC

KK7NIL wrote: post #14

oooyay wrote: post #12

Earlier quoted context omitted.

Ergo isn't a federated server, it's meant to scale vertically

The internet is a "federated" network though, so their point still applies.

No, Ergo doesn't have netsplits because there isn't anything to split with. The point does not apply.

Re: How did IRC ping timeouts end up in a lawsuit?

#34

Post by chrisfosterelli » Mon, Dec 22, 2025, 8:11 PM UTC

oooyay wrote: post #33

KK7NIL wrote: post #14

Earlier quoted context omitted.

The internet is a "federated" network though, so their point still applies.

No, Ergo doesn't have netsplits because there isn't anything to split with. The point does not apply.

There are events that may affect more than one machine which are not netsplits.

e.g. an ISP with common users experiences an outage, an IRC client with common users has a bug, common users within the same time zone have automated system updates run at the same time, the IRC server experiences an upstream network disruption affecting only some routes, a regional power outage occurs, a hosted bouncer service with common users has an outage, etc, etc, etc...