/overchan.random/



Anonymous No. 882d85babd86d6a3292b >>c7346e5d2a7fc1ad3df1
Message-ID: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Date: Sun, 11 Aug 2019 23:41:11 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail

File: Jeffrey_Epstein(...).pdf (4.457 MiB)

gul3ldmm2ogml2pft5tlqygi5b5grdrk6kmjeoxa2w5nq-b2b.pdf
Epstein's mostly unredacted phonebook was linked to on 4chan.
The thread got quickly locked.
Anonymous No. 636de923e85d3b222416
Message-ID: <8000002ta2jtu.lnijv3qmf6csos06@2hu-ch.org>
Date: Sun, 11 Aug 2019 23:42:23 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
also make sure to look at the metadata
it was created on the 27th of July
Anonymous No. e181ed679d2e9277806f
Message-ID: <8000002ta2k0m.p3un41i4tms72eos@2hu-ch.org>
Date: Sun, 11 Aug 2019 23:43:07 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
but fam what about the privacy of the dead? (lol)
Anonymous No. b455eac3f5407c920c89
Message-ID: <8000002ta2ke0.1bbbgvhe0aokpk89@2hu-ch.org>
Date: Sun, 11 Aug 2019 23:46:40 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
the Trumps are in it but the Clintons aren't so some people were kinda dissapointed
Anonymous No. 8ed0fa510a1673dab113
Message-ID: <8000002ta2ko6.pgv9r7ednt92a1i5@2hu-ch.org>
Date: Sun, 11 Aug 2019 23:49:23 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
looks fake and gay
Anonymous No. eea50236c2b32d6d3721
Message-ID: <8000002ta2nla.cc0qu2r4pr21dk6q@2hu-ch.org>
Date: Mon, 12 Aug 2019 00:14:13 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Anything fun in the pdf?
Anonymous No. d16c0fff3cfaa6bc6b35 >>f0670fccf2dab3335782
Message-ID: <3ebf442ee235572@nntp.glowball>
Date: Mon, 12 Aug 2019 01:00:00 +0000
From: Anonymous <poster@nntp.glowball>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nntp.meme!nntp.nsa!
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Encrypted-IP: 127.0.0.1
X-Sage: 9999999

File: ogQfag.jpg (996x1054, 658.034 KiB)

xlyqhhbzegu3nqmtuphfyyq3cq7n3xkls4azyihjo4rwg-b2b.jpg
>>83ee1e31cedb1012f2
>unadulterated
what ever could you be implying goyim
Anonymous No. 83ee1e31cedb1012f217 >>d16c0fff3cfaa6bc6b35
Message-ID: <1314b1565578710@web.oniichan.onion>
Date: Mon, 12 Aug 2019 02:58:30 +0000
From: Anonymous <poster@web.oniichan.onion>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: 726c9cdf39adcca3a22f45d5cc78c80999684744a3680e22778fdecc110a7e11ebb8240cad8e1b08b7cf130bb8643c2029b96cb3437464ba1938c870d7c3560a
>4chan
yep, totally real, comes straight from Q, only 100% unadulterated truth.
Anonymous No. 039ff2b25a4167b6ea1d
Message-ID: <8000002ta3p1k.feva545hagee0evp@2hu-ch.org>
Date: Mon, 12 Aug 2019 04:59:06 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
It counts as dox. 4chan banned me for posting the dox on Nick Sandman for a month. Maybe they're afraid of being sued by Epstein's estate or one of his contacts.
Anonymous No. f0670fccf2dab3335782 >>8333f252e4f98bdc9123 >>20a4aa9d1394a9d2106e >>bd2e9f8107d296042546
Message-ID: <8000002ta460i.uneptpa2bet9t7tb@2hu-ch.org>
Date: Mon, 12 Aug 2019 06:49:45 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <3ebf442ee235572@nntp.glowball>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: 915532.jpg (500x375, 23.859 KiB)

v2agamjzbnfe46zqniuyjyvssbiustj647n5cls7bhzrc-b2b.jpg
>>d16c0fff3cfaa6bc6b35
NSA node is back! And changing time headers bug again!
Anonymous No. 8333f252e4f98bdc9123 >>0c56a029e8ab5c0dc06d
Message-ID: <8000002ta4ipa.menvsvh4gh3o0ape@nekochan>
Date: Mon, 12 Aug 2019 08:38:45 +0000
From: <poster@nekochan>
In-Reply-To: <8000002ta460i.uneptpa2bet9t7tb@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>f0670fccf2dab3335782
not bug, but consequence of delay tolerant networking
https://en.wikipedia.org/wiki/Delay-tolerant_networking
Anonymous No. 20a4aa9d1394a9d2106e
Message-ID: <8000002ta5154.jsdofr9v91lcd2ij@2hu-ch.org>
Date: Mon, 12 Aug 2019 10:41:22 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002ta460i.uneptpa2bet9t7tb@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>f0670fccf2dab3335782
glowies keeping nntpchan safe from the terrorisms
Anonymous No. 0c56a029e8ab5c0dc06d
Message-ID: <8000002ta62ho.ql7mot25k61gh172@2hu-ch.org>
Date: Mon, 12 Aug 2019 15:26:20 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002ta4ipa.menvsvh4gh3o0ape@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>8333f252e4f98bdc9123
<Be peer
<Craft article for Date: 1969-12-31T23:59:59
<Push
<???
<PROFIT
Anonymous No. 64d34a213601a3aaca01 >>94a35e68536f013315ad
Message-ID: <66e061565632923@web.oniichan.onion>
Date: Mon, 12 Aug 2019 18:02:03 +0000
From: Anonymous <poster@web.oniichan.onion>
In-Reply-To: <34bf4d2ee233512@nntp.glowball>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: 155c80f2d5ce13dd4ad503b8a24d4e580f4400ac6deb4236984b0c98a4270580550d610764816859d4bf02fa599694603446c24c6afda9a0542fe90158919c0e
>>bd2e9f8107d2960425
tbph fam, I was the person that said: "never order threads by date, in fact, never allow or respect the Date header, it's useless."
We only need reply references.

nice /tarpit/ redirect though.
Anonymous No. 94a35e68536f013315ad >>2a5f5c888d956b605b08
Message-ID: <8000002ta6v2e.s4dsl0gtk50vj304@2hu-ch.org>
Date: Mon, 12 Aug 2019 19:29:43 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <66e061565632923@web.oniichan.onion>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>64d34a213601a3aaca01
never looking into date hdr is bad idea, won't allow threads to converge on different nodes.
I actually had it implemented that way initially but it looked too broken so I sort by date hdr now.
also post you're replying to doesn't appear on nksrv.
Anonymous No. 2a5f5c888d956b605b08 >>2c92827819a66afa7e6d
Message-ID: <078021565647774@web.oniichan.onion>
Date: Mon, 12 Aug 2019 22:09:34 +0000
From: Anonymous <poster@web.oniichan.onion>
In-Reply-To: <8000002ta6v2e.s4dsl0gtk50vj304@2hu-ch.org>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: c8a65a32b624a353a76fd7df06d09cdfd92e67773b5410715be1cdd8dd8df79fcd1c284056f0827973475f0c26d73c1235bcfeeedd35bb670f271ff9d288cd0c
>>94a35e68536f013315
If you didn't get <34bf4d2ee233512@nntp.glowball>, it's not my problem;^)
SRNdv2 should be only required to observe "References:" and "In-Reply-To:"
But yeah, nksrv needs auto peer refetch.
I don't think NSA node is peered with nekochan.
Anonymous No. 2c92827819a66afa7e6d
Message-ID: <8000002ta7t3u.a22uk1aps9sao4f1@2hu-ch.org>
Date: Mon, 12 Aug 2019 23:46:07 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <078021565647774@web.oniichan.onion>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>2a5f5c888d956b605b08
I just don't allow reply date < OP date.
That post was probably pushed but it didn't propagate in nksrv srvs because got rejected.

>SRNdv2 should be only required to observe "References:" and "In-Reply-To:"
nksrv isn't srndv2.
also disagree, shit with broken or missing date headers is invalid. we wouldn't know where to position it.
also shit like reply date < op date can never happen naturally so it makes no sense to support it (I rely on opdate<=repldate in some places).
Anonymous No. 56ed0df7434a50211481 >>282600d5104c651b1f80
Message-ID: <8000002ta84ma.ea814hob58fd6gn5@2hu-ch.org>
Date: Tue, 13 Aug 2019 00:50:45 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>That post was probably pushed but it didn't propagate in nksrv srvs because got rejected.
That's a flaw.
>we wouldn't know where to position it.
In order of Received.
You've never dealt with race conditions?
>rely on opdate<=repldate
F-L-A-W
You're expecting honest peers and honest clients. DON'T.
A system based in Date is a flawed system, and open all sorts of vulnerabilities:
You never thought about same date reply of instantaneous duplicate articles?
You need to create idempotency, throughout the entire push of an article. Salting articles like we have should be our goal.
Anonymous No. 282600d5104c651b1f80
Message-ID: <8000002ta961a.mj9nk546p86u21ah@nekochan>
Date: Tue, 13 Aug 2019 05:35:17 +0000
From: <poster@nekochan>
In-Reply-To: <8000002ta84ma.ea814hob58fd6gn5@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>56ed0df7434a50211481
>That's a flaw.
no it's not.
message like that could never happen naturally.
>In order of Received.
Doesn't converge.
You can't know proper order "received" if you only sync'd from another node a minute ago.
Especially if you sync from multiple servers simultaneously.
It just doesn't work in practice.
>You're expecting honest peers and honest clients. DON'T.
Which is why I reject that case.
>You never thought about same date reply of instantaneous duplicate articles?
I did. It falls back to order received in that case. Though it maybe should be deterministic and depend on something else, like msgid. Not sure if worth it tho.
¬personal No. e10575e7f7f1f32b7c7d >>585c9f601774578f7c1a >>bbc6ea53e24e9c527ea4
Message-ID: <8000002ta9auq.663pg13bs2nv4mi9@2hu-ch.org>
Date: Tue, 13 Aug 2019 06:17:17 +0000
From: =?UTF-8?q?=C2=ACpersonal?= <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>Especially if you sync from multiple servers simultaneously.
>It just doesn't work in practice.
So you are admitting you've never worked with concurrency before, and order of execution.
Tell me, which should have higher priority: local articles, peers, or third party articles?
Time of posting in either of these can and will be concurrent: how would you order these?
>should be deterministic and depend on something else, like msgid. Not sure if worth it tho.
THIS SHOULD BE THE WEIGHT VALUE.
Articles' worth is the resulting salt of the msgid. This should be what you use to idempotent articles from local, peer, and third.
>Which is why I reject that case.
… which means you prefer the article was never made in the first place, because you'll refuse it because of a malformed "Date:"….
Did you ever stop to consider corruption during transmission resulting in malformed headers?
Anonymous No. 585c9f601774578f7c1a >>bbc6ea53e24e9c527ea4 >>e098a551647a5f485e0a
Message-ID: <8000002ta9dga.k9fkbtg4gjrtk6l6@nekochan>
Date: Tue, 13 Aug 2019 06:39:01 +0000
From: <poster@nekochan>
In-Reply-To: <8000002ta9auq.663pg13bs2nv4mi9@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>e10575e7f7f1f32b7c7d
>So you are admitting you've never worked with concurrency before, and order of execution.
So you're admitting you have no experience running these services and seeing how out of order articles can get.
>Tell me, which should have higher priority: local articles, peers, or third party articles?
All the same order. We want boards to look the same on different nodes.
>Time of posting in either of these can and will be concurrent: how would you order these?
According to Date: header. Because we can't trust articles to come in consistent order across nodes, because of latency between nodes (esp if peered over shitty connections).
Delay tolerance basically.
>THIS SHOULD BE THE WEIGHT VALUE.
nah.
>… which means you prefer the article was never made in the first place, because you'll refuse it because of a malformed "Date:"….
>Did you ever stop to consider corruption during transmission resulting in malformed headers?
yep, if article is corrupt all bets are off.
It may also have corrupt Newsgroups header.
Or corrupt Message-ID header.
I have cryptographic hashing scheme in mind which should help detect corruption.
Anonymous No. bbc6ea53e24e9c527ea4
Message-ID: <8000002ta9ebo.m1gv2g2cup1gveqs@nekochan>
Date: Tue, 13 Aug 2019 06:46:20 +0000
From: <poster@nekochan>
In-Reply-To: <8000002ta9auq.663pg13bs2nv4mi9@2hu-ch.org> <8000002ta9dga.k9fkbtg4gjrtk6l6@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>e10575e7f7f1f32b7c7d
>>585c9f601774578f7c1a
and incase these actually are concurrent, we can't help but order by date received.
but that's only secondary sort key.
Anonymous No. 40f6a8f96f57c6aac6c0 >>44b9499ae2284053dd59 >>c8704d6116768db41aef >>db73eddbc201763ca3a8
Message-ID: <007d51565740608@web.oniichan.onion>
Date: Tue, 13 Aug 2019 23:56:48 +0000
From: Anonymous <poster@web.oniichan.onion>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: fd01c13a3211b2f8e30456b0ecfaee01591b8441efa8882381a57f2afe1fe01de22a926b2a08151b65b55ecb85823c4eea2d6d01b53e11063c7bbfbd51eeb90e

File: space the only (...).jpg (2000x2000, 258.836 KiB)

dkc3raitkz4vzxshvwtsj5d7hdxe62hasr5lpxlw6b7zy-b2b.jpg
>no experience running these services and seeing how out of order articles can get.
It is precisely because I ran one I'm telling you not to base order by "Date:"
>All the same order. We want boards to look the same on different nodes.
I would utterly laugh at you, but we are past that point.
A -> B -> C
A: B(t) < C(t)
B: B(t) < A(t+1)
C: C(t) > B(t)
Solve the ordering of articles with time (t) conflicts if A is your local instance, B a direct peer, and C an external peer of B not related to A.
I already solved the conflict because all I need is the salt of the msgid for all nodes.
>Delay tolerance basically [for wrongful time]
And presently your model is to refuse articles not matching your local time, and time received. I'm no longer talking about following following NNTP which has flawed settlements for innapropiate times, but how should front ends deal with: corrupt date, time of message, time of arrival, time of authentication, local time, time update, etc….
>yep, if article is corrupt all bets are off.
HA! So "no article was ever made, Peer C never sent a message to begin with, decentralization FTW!"
There's a correction you're not seeing, because "Date" IS RELATIVE.
>corrupt Newsgroups header.
But not msgid & salt: something you can trust.
>cryptographic hashing scheme in mind which should help detect corruption.
So not a malformed date(.﹒︣︿﹒︣.)?
>we can't help but order by date received.
SO YOU DO UNDERSTAND WHY "DATE:" IS UNIMPORTANT?
>that's only secondary sort key.
If you comprehend local time is complete different that all external nodes, why, in any shape or form, would you respect _their_ representation and relative value of time?

I need someone else to see this thread.
If this was mission critical software, we would have never communicated via satellite or made it to the moon.
Colonizing Mars will never happen exactly because of these disputes.
proving another point No. 41f4075df2f65659cad5 >>44b9499ae2284053dd59 >>c8704d6116768db41aef >>db73eddbc201763ca3a8
Message-ID: <8000002tad74g.76182ak8umlmdiv5@nekochan>
Date: Tue, 13 Aug 2019 23:56:56 +0000
From: proving another point <poster@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: space the only (...).jpg (2000x2000, 258.836 KiB)

dkc3raitkz4vzxshvwtsj5d7hdxe62hasr5lpxlw6b7zy-b2b.jpg
>no experience running these services and seeing how out of order articles can get.
It is precisely because I ran one I'm telling you not to base order by "Date:"
>All the same order. We want boards to look the same on different nodes.
I would utterly laugh at you, but we are past that point.
A -> B -> C
A: B(t) < C(t)
B: B(t) < A(t+1)
C: C(t) > B(t)
Solve the ordering of articles with time (t) conflicts if A is your local instance, B a direct peer, and C an external peer of B not related to A.
I already solved the conflict because all I need is the salt of the msgid for all nodes.
>Delay tolerance basically [for wrongful time]
And presently your model is to refuse articles not matching your local time, and time received. I'm no longer talking about following following NNTP which has flawed settlements for innapropiate times, but how should front ends deal with: corrupt date, time of message, time of arrival, time of authentication, local time, time update, etc….
>yep, if article is corrupt all bets are off.
HA! So "no article was ever made, Peer C never sent a message to begin with, decentralization FTW!"
There's a correction you're not seeing, because "Date" IS RELATIVE.
>corrupt Newsgroups header.
But not msgid & salt: something you can trust.
>cryptographic hashing scheme in mind which should help detect corruption.
So not a malformed date(.﹒︣︿﹒︣.)?
>we can't help but order by date received.
SO YOU DO UNDERSTAND WHY "DATE:" IS UNIMPORTANT?
>that's only secondary sort key.
If you comprehend local time is complete different that all external nodes, why, in any shape or form, would you respect _their_ representation and relative value of time?

I need someone else to see this thread.
If this was mission critical software, we would have never communicated via satellite or made it to the moon.
Colonizing Mars will never happen exactly because of these disputes.
Anonymous No. bd2e9f8107d296042546 >>64d34a213601a3aaca01 >>2a5f5c888d956b605b08
Message-ID: <34bf4d2ee233512@nntp.glowball>
Date: Wed, 14 Aug 2019 00:00:00 +0000
From: Anonymous <poster@nntp.glowball>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!nekotest!nntp.meme!nntp.nsa!
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Encrypted-IP: 127.0.0.1
X-Sage: 9999999

File: migu.jpg (468x314, 25.569 KiB)

idne4izpzmr74jcmowttmxcifknz653ymj5uwf24bkz26-b2b.jpg
>>f0670fccf2dab33357
you think this is a motherfucking bug its a feature
(^: WONTFIX AND EMBEDDED INTO BOOTES :^)
Anonymous No. c21f4e73a29226a5c0a5 >>44b9499ae2284053dd59
Message-ID: <8000002tad7gk.ne7381rngmao47ud@2hu-ch.org>
Date: Wed, 14 Aug 2019 00:00:10 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: space the only (...).jpg (2000x2000, 258.836 KiB)

dkc3raitkz4vzxshvwtsj5d7hdxe62hasr5lpxlw6b7zy-b2b.jpg
>no experience running these services and seeing how out of order articles can get.
It is precisely because I ran one I'm telling you not to base order by "Date:"
>All the same order. We want boards to look the same on different nodes.
I would utterly laugh at you, but we are past that point.
A -> B -> C
A: B(t) < C(t)
B: B(t) < A(t+1)
C: C(t) > B(t)
Solve the ordering of articles with time (t) conflicts if A is your local instance, B a direct peer, and C an external peer of B not related to A.
I already solved the conflict because all I need is the salt of the msgid for all nodes.
>Delay tolerance basically [for wrongful time]
And presently your model is to refuse articles not matching your local time, and time received. I'm no longer talking about following following NNTP which has flawed settlements for innapropiate times, but how should front ends deal with: corrupt date, time of message, time of arrival, time of authentication, local time, time update, etc….
>yep, if article is corrupt all bets are off.
HA! So "no article was ever made, Peer C never sent a message to begin with, decentralization FTW!"
There's a correction you're not seeing, because "Date" IS RELATIVE.
>corrupt Newsgroups header.
But not msgid & salt: something you can trust.
>cryptographic hashing scheme in mind which should help detect corruption.
So not a malformed date(.﹒︣︿﹒︣.)?
>we can't help but order by date received.
SO YOU DO UNDERSTAND WHY "DATE:" IS UNIMPORTANT?
>that's only secondary sort key.
If you comprehend local time is complete different that all external nodes, why, in any shape or form, would you respect _their_ representation and relative value of time?

I need someone else to see this thread.
If this was mission critical software, we would have never communicated via satellite or made it to the moon.
Colonizing Mars will never happen exactly because of these disputes.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. 44b9499ae2284053dd59 >>7be66bc989803e5b258b
Message-ID: <8000002tafd8i.3lksh2jv5gvdt2iv@nekochan>
Date: Wed, 14 Aug 2019 09:55:21 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <007d51565740608@web.oniichan.onion> <8000002tad74g.76182ak8umlmdiv5@nekochan> <8000002tad7gk.ne7381rngmao47ud@2hu-ch.org> <61b4e32ae795145@nntp.glowball>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: b9ee6343195c27c71504f78ee5391508473ed291cc9226bb024a253d27da01f648cf7859d837c68c6f064f2f72cdadb02bcf041d1d0402a60869be93b6436207
>>40f6a8f96f57c6aac6c0
>>41f4075df2f65659cad5
>>c21f4e73a29226a5c0a5
not sure why you made 3 of them.

>It is precisely because I ran one I'm telling you not to base order by "Date:"
You ran one which didn't ignore Date header, right?
What I'm telling you is that I ran both kinds (one which ignored Date header for ordering, one which didn't).
I liked the one which didn't.
I literally had the same idea that I shouldn't trust Date header initially. I changed my mind after comparing results.
"someone spoofing Date header" doesn't seem like too big issue to me. you can always delete these just like you can delete spam msgs.

>I would utterly laugh at you, but we are past that point.
Can you use actual arguments I can understand and not "hurr durr you're stupid look you're basically admitting it" kind of shit?
Because shit like this makes me even less interested listening to you.
And that's probably not the outcome you want.
Even if you prefix with how non-personal it is, it's still non-argument for me.

>A -> B -> C
>A: B(t) < C(t)
>B: B(t) < A(t+1)
>C: C(t) > B(t)
>Solve the ordering of articles with time (t) conflicts if A is your local instance, B a direct peer, and C an external peer of B not related to A.
>I already solved the conflict because all I need is the salt of the msgid for all nodes.
I don't really understand the issue, explain like im 5.

>And presently your model is to refuse articles not matching your local time, and time received. I'm no longer talking about following following NNTP which has flawed settlements for innapropiate times
I'm assuming that nodes have properly synchronized time. I think inn2 would also rely on that to check that articles don't come from the future.
I used to not check for that. Either way sorta works, but not checking that can lead to pre-bumping of threads which is a bad thing basically.
>but how should front ends deal with: corrupt date
If Date header is fucked, we reject message.
>time of message
it's also in Date header so same as above.
>time of arrival
this can't be corrupt as it's not part of message.
>time of authentication
huh?
>local time
it uses and trusts UTC of machine it runs on.
>time update, etc….
just change of how we're accepting shit, also change what Date: hdrs we generate.
we expect time of nodes to be synchronized.

>HA! So "no article was ever made, Peer C never sent a message to begin with, decentralization FTW!"
yep. corrupt message is bad message. if corrupt message is accepted, that means that non-corrupt version of it won't be accepted anymore.
>There's a correction you're not seeing, because "Date" IS RELATIVE.
it's relative to machine node runs on.
but like I said above we assume that machines have synchronized times.

>But not msgid & salt: something you can trust.
You've never precisely described what is that "salt" thing you're talking about.
And no, you totally can't trust msgid. header itself can get corrupted. it can also be spoofed. msgid doesn't tell you what content holds.

>So not a malformed date(.﹒︣︿﹒︣.)?
If that thing actually gets done then we can tell whether any part of message got corrupted only from its msgid.
Then we can ignore corrupt versions, and only accept non-corrupt ones.

>SO YOU DO UNDERSTAND WHY "DATE:" IS UNIMPORTANT?
Oh, I do understand that it can be fucked with, that it depends on host what made the message, and that it can collide.
But no, I still want to use it as primary sort key, because it works better in practice despite its faults.

>If you comprehend local time is complete different that all external nodes, why, in any shape or form, would you respect _their_ representation and relative value of time?
Are you conflating UTC and Local time? Because I use UTC. We never care about time in local timezones servers run on. We're always sending messages with timezone +0000. We always account for non-0 timezones in Date headers we receive and convert them to UTC.
But yes, as mentioned above, we assume that nodes have sufficiently well synchronized time.
And it works well enough in practice.

>I need someone else to see this thread.
same.


Now, there's question for you.
Lets assume there's nodes: nA, nB, nC.
nA is connected to nB via direct internet connection.
nA is connected to nC via shitty dialup tier i2p connection.
There is discussion going in one thread (thrX).
poster on nC makes message nCmA at 1:01.
poster on nB then makes message nBmB at 1:05.
However, because of bad connection speed, nC->nA pipe have huge backlog (someone posted some huge files in unrelated thread, i2p tunnel chokes), and latency from nC to nA is 10 minutes.
Because of this, nBmB from nB will reach nA sooner than nCmA from nC.
Now, however, nA will see that nBmB still was received earlier.
How it should sort these?
(my solution: just look at Date header)
(note that this is kind of stuff exactly happening in practice and isn't just theoretical edge case which won't be happening often. stuff like this happens all the time)

As extension to this problem, lets say that thread thrX was at 10th page and was about to get pruned (it was last thread on page).
On-time delivery of nCmA would have saved thrX. But nBmB would've been too late (new thread thrY was made at 1:03).
Now, since nC had nCmA on time, it's still got thread alive.
However, nA and nB weren't so lucky. They didn't see nCmA at the right time.
Now, if we have no way to deal with this, essentially node desynchronization happens: there is active thread in one node nC, but that thread gets killed at nA and nB.
That's something I personally don't want to happen.
I'm sorta trying to think of a ways to deal this.
https://github.com/cathugger/nksrv/blob/master/pruning.txt is current not-too-readable draft. (I wrote it before going to bed to not forget)


btw >>babf129a5b14133beecc is cool thread
Anonymous No. 3e5bb2c86ec5db703aac >>205cdb7f15794cf4533b >>3312eb83ca0d32aa63e2
Message-ID: <6420c1565782108@web.oniichan.onion>
Date: Wed, 14 Aug 2019 11:28:28 +0000
From: Anonymous <poster@web.oniichan.onion>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: c73568db763ece295dbb7edfb31a36396591777dc69ace5b13883016982c48e88c397eb931e6a88474d075247832e3c8f1d96e2ae7b4b2e069bd4f53ccb8830e
clock skew is a YOU problem it's not the server's job to work around your system's clock being way off
Anonymous No. e098a551647a5f485e0a >>7be66bc989803e5b258b >>205cdb7f15794cf4533b >>3312eb83ca0d32aa63e2
Message-ID: <8000002tafqo6.g1agcf4ojn18ga12@2hu-ch.org>
Date: Wed, 14 Aug 2019 11:50:27 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002ta9dga.k9fkbtg4gjrtk6l6@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: mpv-shot3253.jpg (1280x720, 170.878 KiB)

mcvyw2dbgdn6pwpoi7hqc4ez76t5mddgn7fktyuy62qwi-b2b.jpg
expired captcha key, well, fuck you too.

>>585c9f601774578f7c1a
You should make msgid be a cryptographic hash. That way when taking into account "References:" and "In-Reply-To:" you form a Merkle DAG, and you can use that for the order of the posts.
Anyway, I wonder, have you considered the case where a malicious server sends different dates to different servers? You will end up with different order between servers then. Plus you do not seem to be handling the case where postdate > opdate but postdate < post-it-is-replying-to-date
Anonymous No. 7be66bc989803e5b258b >>d96d661a8f4250483aad >>b19b97739dbf6e38ad25 >>3312eb83ca0d32aa63e2
Message-ID: <8000002tafs4e.5gjj15k35cllqqo7@2hu-ch.org>
Date: Wed, 14 Aug 2019 12:02:15 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002tafqo6.g1agcf4ojn18ga12@2hu-ch.org> <8000002tafd8i.3lksh2jv5gvdt2iv@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: mpv-shot3260.jpg (1280x720, 126.261 KiB)

xfccoxar7gtudij5cj2ygjzr5rwtu22ncbnla4tumuvw4-b2b.jpg
>>e098a551647a5f485e0a (cont)
Date should just be removed from the protocol and the servers should just optionally log and display the date received instead.

>>44b9499ae2284053dd59
> What I'm telling you is that I ran both kinds (one which ignored Date header for ordering, one which didn't).
> I liked the one which didn't.
I guess you didn't have a lot of malicious servers/servers with their date being off, huh? As the federation grows this will get worse and worse.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. 205cdb7f15794cf4533b >>3312eb83ca0d32aa63e2
Message-ID: <8000002tafumo.g5uss8gmair7tc28@nekochan>
Date: Wed, 14 Aug 2019 12:24:12 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <6420c1565782108@web.oniichan.onion> <8000002tafqo6.g1agcf4ojn18ga12@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: ca8572a2846f993a5b10ce4a02aba9316cb3b2b4956ae1ccec69c21f1b39e09395c18671bd5bd33f6b1547e7d7e7f796e2e97ae0de7930203d6f7c29cc45a40c
>>3e5bb2c86ec5db703aac
yeh basically what I've been thinking.
clients clocks being off doesn't affect what server shows unless such clients post thru nntp and include wrong Date header.
if some node has clock very off and makes weird-dated posts well then fuck that node don't peer with it or just delet that bad posts.
nodes are more or less internet-connected either way they should at least fukin sync their clocks while at it.
>>e098a551647a5f485e0a
>expired captcha key
yeh that shit's annoying.
I think I should bump it to 1 hour.
I actually will.
>You should make msgid be a cryptographic hash.
yep, that'll be exactly this.
https://github.com/cathugger/nksrv/blob/master/src/nksrv/lib/cntp0/checksum.go current unfinished(?) code
I haven't touched it in months https://github.com/cathugger/nksrv/commits/6d61ff7479124652fe3cbb0fdeee8d9442acaf02/src/centpd/lib/cntp0/checksum.go
it'll be hash of important headers and body.
>That way when taking into account "References:" and "In-Reply-To:" you form a Merkle DAG, and you can use that for the order of the posts.
References only includes OP you're replying to.
In-Reply-To won't be set if you don't refer using >>. Totally not every post include right >> references.
Also, without cryptographic hashing you can make infinite loop (you can easily make non-crypto message ID, add that to In-Reply-To, post, then make new message with that ID which includes ID of previous msg in its In-Reply-To, bam essentially loop).
Thing is, unless you enforce it, such hashing is not guaranteed therefore you'll have to accept non-cryptographic message-ids therefore loops are possible.
Meanwhile, just reading Date header and sorting using that is much much easier.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. d96d661a8f4250483aad >>f5333088527dd95857ea >>b19b97739dbf6e38ad25
Message-ID: <8000002tag62a.c9rv38njdq4qffe7@nekochan>
Date: Wed, 14 Aug 2019 13:27:01 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tafs4e.5gjj15k35cllqqo7@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 95c164bf1e39d03af61293f21696b3ef6fdb44356644fc15c965c912587884c18a4f41ab4fbdcd7c2884c7eb8861da6733c59c4fe61d66ec06057e87efaa880b
>>7be66bc989803e5b258b
>Date should just be removed from the protocol and the servers should just optionally log and display the date received instead.
Nah.
>I guess you didn't have a lot of malicious servers/servers with their date being off, huh? As the federation grows this will get worse and worse.
Servers with their time being off aren't very likely.
If that actually happens and causes issues you can just delet bad posts, tell people to not use these nodes, tell admins to fix their shit, etc.
We actually tolerate times being a bit off: https://github.com/cathugger/nksrv/blob/master/src/nksrv/lib/psqlib/nntpprocessing.go#L199-L204
Now, if we have malicious servers, that's much bigger problem on itself.
Malicious servers can do volumetric spam (which would slide off threads).
What ya gonna do if such malicious server do automated posts and attach CP to every post it ever makes?
Dates being wrong is really non-issue at that point..
Anonymous No. f5333088527dd95857ea >>bc461f3bbc46a9ab8ae6 >>3312eb83ca0d32aa63e2
Message-ID: <8000002tag9ne.d31cc38167kq6es6@2hu-ch.org>
Date: Wed, 14 Aug 2019 13:58:15 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002tag62a.c9rv38njdq4qffe7@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>d96d661a8f4250483aad

I was thinking about something for simple moderation on such kinds of platforms.
For the volumetric spamming, ain't there a simple script that blocks similar texts or pics? There are somes well developed and efficient today.
For contents that peoples often don't want to see, a simple button could be added to hide the Pic of a post.
Like three button (CP, gore, porn), when a user click that it gets hidden like a spoiler thumbnail and other users can vote (up or down) this choice of moderation.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. b19b97739dbf6e38ad25 >>3312eb83ca0d32aa63e2
Message-ID: <8000002tagc7g.223mupke7ai4e625@nekochan>
Date: Wed, 14 Aug 2019 14:19:36 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tafs4e.5gjj15k35cllqqo7@2hu-ch.org> <8000002tag62a.c9rv38njdq4qffe7@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 513188185f6372a30f4537fe2769a2253c0f638b97424838ceb9532fe8d83fc9bae0b09669e4091f90273c3bf331408a52d3bbcebaa6fa7e51c20d0eba059a03
>>7be66bc989803e5b258b
>>d96d661a8f4250483aad
I should probably elaborate that "Nah.".
Displaying only date received would be totally fragile and would go more and more wrong as messages travel thru the net.
Not to mention that sometimes message synchronization between nodes break.
Underlying transport breaks (both i2p and tor have bad habit of randomly not working sometimes).
Accidental errors changing config, like firewall.
Inbetween nodes temporarily shutting down for maintenance.
All of these normally occuring things, they would cause messages not propagating, and end up with all of dates being the same or almost the same (remember, multiple messages can be inserted at the same second, so you'd have to include milliseconds if you wanted to show difference).
Imagine, one hour passes, connection between nodes is restored, and then 20 messages with the same date/time appearing at the end of thread.
Or, you're setting up new node. You gotta pull articles from somewhere. Remember, no Date hdrs. So ya get all of them and then you have all of imageboard with absolutely fucking bogus datetimes.
I'm totally not seeing that as anything but "bad idea".
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. bc461f3bbc46a9ab8ae6 >>137d7a78c422d66aa829
Message-ID: <8000002tagels.cj1ubqnifjitndcu@nekochan>
Date: Wed, 14 Aug 2019 14:40:30 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tag9ne.d31cc38167kq6es6@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 373cf137d16d1eabf0374a57666993fa75b345607cfa17ba1ed963d04bc61938bb5301e81a55c5a5e7b0fe32eff65e914a7ee72e42afc0112b03b21b71bf6a01
>>f5333088527dd95857ea
>For the volumetric spamming, ain't there a simple script that blocks similar texts or pics? There are somes well developed and efficient today.
lolno it's never simple.
what if they randomly generate messages based on news articles. or markov chains. or irc post archives. or basically anything human-looking but still being random, unique at every message and easily doable at high speed.
>For contents that peoples often don't want to see, a simple button could be added to hide the Pic of a post.
only works for human-made posts and if there's no high volume of them. people will get tired of hiding otherwise.
>Like three button (CP, gore, porn), when a user click that it gets hidden like a spoiler thumbnail and other users can vote (up or down) this choice of moderation.
How you do votes?
You just gonna allow unauthenticated moderation? Bot swarm will fuck up everything..
You gonna make people have accounts? Remember, this is anonymous imageboard..
You gonna let users have pubkeys and then they send sort-of-mod-posts? how you whitelist which users can do voting.. remember, blacklists don't work with bots they can just keep making new keys...
all of these are fucking hell.
only way I can see this could work would be freenet's FMS level of identity trust bullshit.
it's sorta manual and revolves around others trusting your identity and then you have more power to moderate from that.
which is totally unlike imageboards culture.

only way at that point is to whitelist nodes with keys.
which reminds me, jeff already got sort-of even working solution for that: X-Frontend-PubKey and X-Frontend-Signature headers.
even if their names sort of suck, I just gonna implement that.
Anonymous No. 137d7a78c422d66aa829 >>dfa46b6ddfd5e15152dc >>3312eb83ca0d32aa63e2
Message-ID: <8000002tagiti.nb7emal7r574a3hp@2hu-ch.org>
Date: Wed, 14 Aug 2019 15:16:41 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002tagels.cj1ubqnifjitndcu@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>bc461f3bbc46a9ab8ae6
Can you just force a captcha on every nodes? No captcha resolved, no post?
I don't really see how to do that though.

>You gonna make people have accounts?
No just adding a tiny moderation tool.
Exemple : I see CP, click to [M], it opens an other page, I click to "CP",fill a captcha, then the thumbnail change to "NSFW" like a spoiler.
But it's not deleted, other users can see the Pic by clicking on it.
If it wasn't cp, an other user can remove the spoiler by downvoting the moderation choice and image come back (by filling an other captcha).

I was just thinking about a way to moderate a decentralized imageboard without the ability to delete a post and I found this, but maybe it wouldn't work well in practice.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. dfa46b6ddfd5e15152dc
Message-ID: <8000002tahlsu.eso795mrjafv417f@nekochan>
Date: Wed, 14 Aug 2019 20:15:11 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tagiti.nb7emal7r574a3hp@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 4ce5f32bd4d32dfe68dffe7aaf89e5fc69c7d0ec5f04b324493133340c2b2366c3340c9b88825ec026e9d3ec38727d902c559b849feffdc6d87b4bd1a1cae808
>>137d7a78c422d66aa829
>Can you just force a captcha on every nodes? No captcha resolved, no post?
>I don't really see how to do that though.
same. but that doesn't protect from malicious servers.

>No just adding a tiny moderation tool.
>Exemple : I see CP, click to [M], it opens an other page, I click to "CP",fill a captcha, then the thumbnail change to "NSFW" like a spoiler.
>But it's not deleted, other users can see the Pic by clicking on it.
>If it wasn't cp, an other user can remove the spoiler by downvoting the moderation choice and image come back (by filling an other captcha).
sounds sorta like flagging/unflagging.
can be abused, but harm wouldn't be too big.
also users will just get tired of doing that if there's too much of them to hide (again, hypothetical malicious server scenario).
but if userbase isn't too shitty and we don't actually get malicious servers this could work pretty well.
Anonymous No. 10455b5355c016bf9e73 >>10cd5229967306038a77
Message-ID: <8000002tai8jc.k13fvon403baic7p@nekochan>
Date: Wed, 14 Aug 2019 22:54:46 +0000
From: <poster@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Might be a better idea to write up a proof of work standard based on either (or both) a CPU heavy or a RAM heavy algorithm, implement it in javashit for the plebeians and in C (and BSD licensed) for both UNIX and Windows for the anti-javashit masterrace to run locally. The node provides a nonce which expires and a minimum difficulty level based on a posting volume moving average. The nonce should expire in some multiple of the expected time it takes to create a work proof for the lower of either average or median system. The nonce exists to prevent pre-generated proofs. If the proof is sufficient then the node it is posted to signs the message and proof and all other peered nodes will only replicate node-signed posts. I would expect it take a few minutes minimum, ten minutes maximum, to compute a proof, and that nonce expiry should be anywhere from a half hour to three hours.
Anonymous No. 10cd5229967306038a77 >>c2303a9a23fb41ed369f
Message-ID: <8000002taicua.h9lh5odki7njia6b@2hu-ch.org>
Date: Wed, 14 Aug 2019 23:31:49 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002tai8jc.k13fvon403baic7p@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>10455b5355c016bf9e73
Like a blockchain?
Make an image board that makes me aern money lmao.
1 (you) = 1 token
100 tokens = fancy shits
1000 tokens = advertising space

Advertisers can buy tokens for real money (that's the trick)

Accounts can just be generated with a key like on idex.io, no javasceipts or anything needed.

You can even have fun and add a casino.

Adding the ability to earn money by shitposting would the funniest (and most addictive) thing ever.
Anonymous No. c2303a9a23fb41ed369f >>727e36e3268a1f11bb15
Message-ID: <8000002taikr0.0qcqab93javorbdh@nekochan>
Date: Thu, 15 Aug 2019 00:39:12 +0000
From: <poster@nekochan>
In-Reply-To: <8000002taicua.h9lh5odki7njia6b@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>10cd5229967306038a77
Not really. An example of that exists and it's called Steem. I'm refering to something like hashcash like with e-mails.
Anonymous No. 727e36e3268a1f11bb15
Message-ID: <8000002taio6g.9d84nobhih8n0oj3@2hu-ch.org>
Date: Thu, 15 Aug 2019 01:07:52 +0000
From: <poster@2hu-ch.org>
In-Reply-To: <8000002taikr0.0qcqab93javorbdh@nekochan>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>c2303a9a23fb41ed369f
But steem is shit
part1 of an original series No. c8704d6116768db41aef >>db73eddbc201763ca3a8
Message-ID: <8000002tajah8.bg0mqh2uq5fjeghk@nekochan>
Date: Thu, 15 Aug 2019 03:44:20 +0000
From: part1 of an original series <poster@nekochan>
In-Reply-To: <007d51565740608@web.oniichan.onion> <8000002tad74g.76182ak8umlmdiv5@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>not sure why you made 3 of them.
`proving another point` was first, but your instance took time to accept it, and timestamped 23:56:56, because you are on wi-fi. <007d51565740608@web.oniichan.onion> came into your node minutes later, and was ordered above <8000002tad74g.76182ak8umlmdiv5@nekochan>.
Noting now self explanatory posts don't work with you.
>you can always delete these just like you can delete spam msgs.
Yeah, you lost the point of decentralized networks.
>non-argument for me.
That's precisely what psi has been saying: this is non argument, when articles are lost.
>explain like im 5.
>Now, there's question for you.
So like my academic prose doesn't work, noting.
>assuming that nodes have properly synchronized time.
Bad assumption: travel, delay in network, CPU differences, locality, chaotic timezone (e.g. Arizona), reset, network reshape, man in the middle, etc....
Why I had to list just a few, feels like speaking redundant, but you are 5.
>inn2 would also rely on that to check that articles don't come from the future.
It has several exception cases, one being different timezones.
>not checking that can lead to pre-bumping of threads
How does this relate to time? Isn't this a frontend configuration domain?
>If Date header is fucked, we reject message.
No message back: "please resend message, date was fucked."
>>time of authentication
>huh?
"This message is OK to send, relaying to peers now."
>we expect time of nodes to be synchronized.
Flawed design choice.
>if corrupt message is accepted, that means that non-corrupt version of it won't be accepted anymore.
That means you won't accept exception and case different. For get conflicts, nekoserver refuses messages because it does not how to handle itself.
>"salt"
So if cryptographic one way functions don't work, checksuming content never works, thus the server I trust to formulate articles with can never be trusted: salting.
>it can collide.
How, do, you, deal, with, collissions? The entire thesis of this debate rest on this answer.
>primary sort key, because it works better in practice despite its faults.
A relative value to an observer will be used, faults and all, as the primary sorting key to delegate how a network should delegate itself. Yeah, flawed.
>same.
You are welcome. Thank god they have fresh eyes.
>How it should sort these?
Because dates should never exist:
nA will resolve messages in order they are received (FIFO), regardless the postage date.
Thus, nA will acquire nBmB then nCmA and post them in thrX in FIFO.
nB & nC will comprehend nA's order is different than theirs, because threads are relative to In-Reply-To.
We can use Alice and Bob if greater than 5 year old language is hard. While Charlie is always slow, Alice can only know what she knows as fast as she gets messages from both.
Bob and Charlie should comprehend messages came at relative times, since everyone understand even Bob can fail to deliver at times. Sometimes Bob's driver gets extremely late.
The important part, is that Alice, Bob, and Charlie can trust that messages that come from each other are theirs and nothing was corrupted in between. If they were, they can all tell each other to say it again, correctly.
Capiché?
Anonymous No. 3312eb83ca0d32aa63e2 >>91a7299da5675f0447f4
Message-ID: <8000002tajcmq.fulsc3hgvebimlom@nekochan>
Date: Thu, 15 Aug 2019 04:02:53 +0000
From: <poster@nekochan>
In-Reply-To: <6420c1565782108@web.oniichan.onion> <8000002tafqo6.g1agcf4ojn18ga12@2hu-ch.org> <8000002tafs4e.5gjj15k35cllqqo7@2hu-ch.org> <8000002tafumo.g5uss8gmair7tc28@nekochan> <8000002tag9ne.d31cc38167kq6es6@2hu-ch.org> <8000002tagc7g.223mupke7ai4e625@nekochan> <8000002tagiti.nb7emal7r574a3hp@2hu-ch.org>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
>>3e5bb2c86ec5db703a
It's ok not to be redundant.
>>e098a551647a5f485e
We have discussed and consider all this, but cathugger has poor memory, so he needs refreshing. Merkle DAG is the properest way to go.
>>7be66bc989803e5b258b
>servers should just optionally log and display the date received instead
One abbreviation: FIFO
>a lot of malicious servers/servers with their date being off, huh? As the federation grows this will get worse and worse.
We've had, lost peers because of them. Right now we are at very vulnerable point, because the entire network has MANY flaws.
>>205cdb7f15794cf4533b
>weird-dated posts well then fuck that node don't peer with it or just delet that bad posts.
That's a terrible predecent, worse than `date:` issues.
>nodes are more or less internet-connected either way
Horrible assumption, esp. with on the go devices.
>such hashing is not guaranteed therefore you'll have to accept non-cryptographic message-ids therefore loops are possible.
But timestamping is guaranteed....
Wasn't there an academically proven loop in *nix timing,, something that should be happeing close to 2038?
>Servers with their time being off aren't very likely.
But a month old network repair isn't....
>tell people to not use these nodes, tell admins to fix their shit, etc.
How do you do this independently without any tools?
I know overchan never solved the forward compatability problem, which is why SRNd left, but should SRNdv2 suffer the same fate?
>>f5333088527dd95857ea
I made an entire thread about installing a whole system with programming that will need to be implemented as soon as NNTPChan & nksrv are feature complete.
Both are Alphas.
>>b19b97739dbf6e38ad25
So if you know all these things happen all the time, why, in gods name, would you hope dates will ever be "in synch"?
>>137d7a78c422d66aa829
The one thing I agree with every one, is that peering should be conservative progess. You can't just trust everything. However, I'm a proponent of semi-automation, like i2p already does. Things like find peers and having the daemon delegate rules between each other before the admin says YES|NO. Recursive lookup and peer metadata aggregation, that sort of things: what kind of groups, how many moderators, how many articles, etc..
Anonymous No. ef126a3ddeb7acb433a5
Message-ID: <8000002tajdk8.kveohe0h6osoti56@nekochan>
Date: Thu, 15 Aug 2019 04:10:44 +0000
From: <poster@nekochan>
In-Reply-To: <8000002t8uapk.8l8blj8uvfm8g7uq@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
And the other discussion. Proof of work is shit, and expensive.
All we really need is trust, which can easily be broken.

Everyone agrees this is a client-{frontend-nntp}servers model, right?
For p2p, bittorrent will surpass the rest. It already does in some clients.

Time to move the discussion back to >>945c36732196487d81
?
oniichan doesn't seem to pull up that news:overchan.overchan thread. Maybe you have it.
Anonymous No. b8aad764bddd8695a6d3
Message-ID: <8dfc11565842356@web.oniichan.onion>
Date: Thu, 15 Aug 2019 04:12:36 +0000
From: Anonymous <poster@web.oniichan.onion>
In-Reply-To: <90b071503573465@chan>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: 81efd291bcaf6e566d38fcf82f3b8190a700ed15909891fae5aa809834c562d50f504a4ade9fac07faa35b1b81721477342a500e7dfd4b4e7cd48752da5ef200
Found it thanks to cathugger:
>>719ee78e26c519231bfb
Time to prune shit, you have 63 pages on overchan, half spam.
Anonymous No. 46d076f43eca0438f8b1
Message-ID: <8000002taje7q.41ndgjaglsojl7ud@nekochan>
Date: Thu, 15 Aug 2019 04:15:57 +0000
From: <poster@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Thu Aug 15 04:12:36 2019 vs 2019-08-15 (Thu) 04:10:44
FIFO is def. best.
Anonymous No. 778f5a85979a8eb34c55
Message-ID: <762931565880366@web.oniichan.onion>
Date: Thu, 15 Aug 2019 14:46:06 +0000
From: Anonymous <poster@web.oniichan.onion>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
Subject: None
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: 9d1405ea7c39fa19124c4fcc1fefa01dd55254b9841ed691ed178159fe361d473e887514de5d86eec32fd8244d1640d46d7c6308dbcc4fa231fd6814e7a71900
4chan and 8ch /pol conspiracy theories are near antivaxx, reptilians live in the core of the earth and the ww2 never happened at all conspiracy theories

if pol they said something about epstein they probe made it up
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. db73eddbc201763ca3a8 >>4f788568eeeacabe9f6d
Message-ID: <8000002tamqcg.upvu24p348dk6jgu@nekochan>
Date: Thu, 15 Aug 2019 19:38:48 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tajah8.bg0mqh2uq5fjeghk@nekochan> <007d51565740608@web.oniichan.onion> <8000002tad74g.76182ak8umlmdiv5@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 802a911b69268c888f21334beb020ba16cd1cee04a4ce644976a6abcdd642eace9a6a5190cf1b676f82ea36d0de388617e292d949eb0b17433717eefcee96403
>>c8704d6116768db41aef

can you fucking quote complete lines and not just words, shit like that makes it hard to follow your points.

>`proving another point` was first, but your instance took time to accept it, and timestamped 23:56:56, because you are on wi-fi. <007d51565740608@web.oniichan.onion> came into your node minutes later, and was ordered above <8000002tad74g.76182ak8umlmdiv5@nekochan>.
>Noting now self explanatory posts don't work with you.
measuring using absolute time, it came in precisely how it should have been.
it's exactly my point. both nekochan and 2hu instances order them the same. just how it should be.
them ordering shit differently would be flaw.
consistency across nodes is achieved.
>Yeah, you lost the point of decentralized networks.
I didn't. As admin you can delete whatever you want from your node. As mod you can delet whatever posts you want in nodes trusting your key. This shit isn't append-only.
>That's precisely what psi has been saying: this is non argument, when articles are lost.
I was picking your fucking way of writing.
If I wanted to be honest I'd shit on you being fucking out of touch with reality on every post I make.
I probably should, as politeness with you only makes you shit on me more.
>So like my academic prose doesn't work, noting.
It's your issue that you couldn't formulate problem in a way I can understand without needing to guess details.
>Bad assumption: travel
what will happen from travel? we don't care about local timezone nodes run on. we only care about UTC. linux and other unixes have their RTC clock configured to use UTC in most cases. local timezone isn't part of equation.
also servers don't travel that much tbh. and they usually use UTC too, not local timezone in place they run on.
this isn't absolute, but I just need high enough probability that it works as I described.
and I think this probability is high enough.
>delay in network
that's problem for NTP. I think the way they measure latency and talk with multiple servers works pretty well for having pretty precise awareness of universal time.
like I mentioned before, few seconds here and there is non-issue for my software.
>CPU differences
running daemon which talks NTP would fix fucked up skew.
>locality, chaotic timezone (e.g. Arizona)
timezones are irrelevant.
>reset
will most likely fuck much more of shit than datetimes
>network reshape, man in the middle, etc....
what this has to do with anything?
>Why I had to list just a few, feels like speaking redundant, but you are 5.
and you're fucking idiot. great argument, isn't it?
>It has several exception cases, one being different timezones.
no, different timezones aren't exception case are you so retarded that you can't read that we're converting everything to UTC for processing either way, every Date header includes timezone field precisely for that reason
>How does this relate to time? Isn't this a frontend configuration domain?
No, backend is aware of shit what runs on top of it.
It has to be, to be able to be efficient.
But since you haven't actually written any code and just throwing absolutely stupid impractical ideas at me all the fucking time, I'm not surprised.
Some of shit you write makes me think in the right direction (which is why I still keep engaging with you) but that happens pretty rarely.
>No message back: "please resend message, date was fucked."
We actually can have no idea if ANY part of message isn't fucked right now. We can't detect if it's corrupt but still valid.
I really really wanna just make message-id be hash of msg body.. and then every server would check their incoming articles, and reject incorrect ones.
I honestly believe that corrupt message is worse than no message. You can fix "no message" easier than "corrupt message".
Once corrupt version propagated everywhere, it's much harder to replace it.
>Flawed design choice.
Yes I know.
Can we just accept the fact that it's flawed, and focus on making this work better despite it being flawed? In practice, I mean.
I think I made myself clear that I'm not removing Date headers anytime soon.
If you want them not exist, write your own thing. Btw, I reject articles without Date header, so you gotta include them either way, but you can ignore them if you want.
>That means you won't accept exception and case different. For get conflicts, nekoserver refuses messages because it does not how to handle itself.
That's because of how NNTP protocol works. You've read RFCs right? IHAVE command. also CHECK/TAKETHIS ones. it's protocol's flaw, not unique to my software. Once article with one Message-ID is accepted, no other article can exist with same Message-ID. Which is why I want Message-IDs to be cryptographic hashes. It's essentially key->value store, where Message-ID is key.
>So if cryptographic one way functions don't work, checksuming content never works, thus the server I trust to formulate articles with can never be trusted: salting.
Sorry I can't parse this sentence or extract any meaning of it.
>How, do, you, deal, with, collissions? The entire thesis of this debate rest on this answer.
LEFT JOIN LATERAL
(
SELECT
*
FROM
ib0.bposts zbp
WHERE
xt.b_id = zbp.b_id AND xt.t_id = zbp.t_id
ORDER BY
zbp.pdate ASC,zbp.b_p_id ASC
) AS xbp
does this answer your question? b_p_id is per-board counter which is increased on every post so effectively it's order of received articles. it's secondary sort key.
>A relative value to an observer will be used, faults and all, as the primary sorting key to delegate how a network should delegate itself. Yeah, flawed.
Date header isn't relative to observer. Are you fucking retarded?
It's absolute universal time.
Convertible to clean absolute integer value.
What is very relative, though, is order of articles received.

>nB & nC will comprehend nA's order is different than theirs, because threads are relative to In-Reply-To.
flawed assumption right there. In-Reply-To only happens if you refer to post. if you don't, it won't happen.
or, it can get corrupt. or bogus one can be added.
(these aren't actually going to happen much but you used these as arguments against Date so I can too)
your "solution" will result in nA and nB having different sorting of messages than nC.
if messages didn't include In-Reply-To, that is. But I didn't say that these separate messages quoted each other, or had In-Reply-To.
In fact, they couldn't, because nB didn't see nCmA, and nC didn't see nBmB when each of them posted. so they couldn't have referred.
>The important part, is that Alice, Bob, and Charlie can trust that messages that come from each other are theirs and nothing was corrupted in between. If they were, they can all tell each other to say it again, correctly.
where is that magic coming from? if one message contained character A instead of B, how could other node tell? message-id being cryptographic hash is not done nor deployed yet. if you were using that then yes you could check. otherwise no.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. 91a7299da5675f0447f4
Message-ID: <8000002tamvge.4s6cd3l3u3u029qm@nekochan>
Date: Thu, 15 Aug 2019 20:22:31 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002tajcmq.fulsc3hgvebimlom@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 176eee14ef8b3990daf993e310f680c99d1ec0435b1ccfd65497f29e75eeb9201fbfdc7b7d3f70a15822cd81bfc270b66669c7fce5db8b9105e587114f3d6407
>>3312eb83ca0d32aa63e2
>Right now we are at very vulnerable point, because the entire network has MANY flaws.
well I'm trying to make it less flawed, but removing Date header will make it only more flawed, I believe.
>>weird-dated posts well then fuck that node don't peer with it or just delet that bad posts.
>That's a terrible predecent, worse than `date:` issues.
More likely I'd just start nagging admin of fucked up node to fix their shit tbh. I've had messages just not propagating because of nntpchan's shittyness and that felt real bad.
>>nodes are more or less internet-connected either way
>Horrible assumption, esp. with on the go devices.
one the go devices aren't nodes, are they?
by nodes I mean nntp servers.
>>such hashing is not guaranteed therefore you'll have to accept non-cryptographic message-ids therefore loops are possible.
>But timestamping is guaranteed....
>Wasn't there an academically proven loop in *nix timing,, something that should be happeing close to 2038?
>academically proven
wew
it's still on operator to fix that. I aint going to twist my design in fucked up ways to work around thing which is rare.
regarding shit not being guaranteed, I don't actually consider order of posts to be important enough, and harm done by spoofing them is pretty minimal.
if no one spoofs, and things which are very rare to happen don't happen too often, it gonna look and work superior sorting by Date first, instead of ignoring it.
>>Servers with their time being off aren't very likely.
>But a month old network repair isn't....
huh? connectivity problems between nodes is very really more likely than times being off.
>>tell people to not use these nodes, tell admins to fix their shit, etc.
>How do you do this independently without any tools?
>I know overchan never solved the forward compatability problem
it's hard one to solve. especially because SRNdv2 had backward compatibility with SRNd problems too.
>which is why SRNd left
I wasn't really around back then. You sure he left because of that? I'd like to hear more.
>but should SRNdv2 suffer the same fate?
I think jeff made it kinda clear that he intends to full switch to nksrv once it gets all the features of srndv2.
He even switched 2hu node way before that..
tbh nntpchan/srndv2's codebase is pretty fucked, it does lots of things in wrong ways.
I'm not saying all parts of it are bad, and performance wise it certainly performs better than old srnd (so it achieved one of its objectives already), but its not really well structured, is hard to maintain and is full of behavior some people might consider to be outright buggy.

>So if you know all these things happen all the time, why, in gods name, would you hope dates will ever be "in synch"?
We don't need them to be perfectly in sync.
What I was talking about was "received date", so not "Date" header but the date article was delivered to server.
These things will fuck up "received date"s. They won't fuck up Date headers. Date headers are made once at post time, and never modified.
Once connectivity is restored, articles would just propagate again, and threads would gracefully merge, that is if they are sorted by "Date" header.

>However, I'm a proponent of semi-automation, like i2p already does. Things like find peers and having the daemon delegate rules between each other before the admin says YES|NO. Recursive lookup and peer metadata aggregation, that sort of things: what kind of groups, how many moderators, how many articles, etc..
Oh yeah it would be nice to have something like that.
Would make it easier for new admins to join network.
The more nodes the stronger network.
again, don't take anything personal, just ridiculing the idea. Maybe start fresh on overchan.overchanAnonymous No. e3a3b3c15e07e6379311 >>c7346e5d2a7fc1ad3df1 >>e128febdf7e53feb58ca
Message-ID: <2f7b21565927643@web.oniichan.onion>
Date: Fri, 16 Aug 2019 03:54:03 +0000
From: Anonymous <poster@web.oniichan.onion>
Newsgroups: overchan.random
Path: nekochan!nntp.oniichan.onion!web.oniichan.onion
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-Frontend-PubKey: b1dcaa6ba60c1381a5823c3c61c995afeaead79896f95f9748da5fe1cf6ea43f
X-Frontend-Signature: 4604dc0dd51b297a030900deb9e399af11a223cc4206b5476e289e09b5319cefb511646b178b3342e8cdcfc857070a96369c2187707d4ea40627c0df8ac3d303
X-I2P-DestHash: 6wXmk2RGDykwqKe~LY1NwYk177sqfaaPha~9on8Z758=
>can you fucking quote complete lines and not just words, shit like that makes it hard to follow your points.
Don't blame me for your inability to reference excerpts. Unless you want me to use diff notation.
>consistency across nodes is achieved.
Why is this, desired? Wouldn't OP node decide how "consistency" should be across all articles in a thread, and not delegated via an arbitary value?
>>the point of decentralized networks.
>As admin you can delete
And what the hell does administration have anything to do with a ensuring articles get passthrough the entire network? I demonstrated, and NSA node, that your refusal to ignore date headers is causing articles to be lost. Is that how you achieve decentralization dropping articles because it doesn't reflect _a_ peer's "time"?
>I was picking your fucking way of writing.
So you prefer Kindergarden criticism?
Hey cathugger, it's bad to ignore messages from Charlie because they were "too slow" to deliver.
Cause, I can choose that if you want.
>It's your issue that you couldn't formulate problem in a way I can understand without needing to guess details.
I'm sorry you were dropped as a child, have memory problems, and can't observe an article in exemplus gratus scriptus. I'll just remind myself in the future to converse with you in child speak.
Mommy showed you metaphors work, right?
>also servers don't travel
You've never heard of submarine datacenters, figures. Forget satellites, this boy forgets the entire world has expontencially 4 times more cellphones than your average static colocated piece of x86 virtual farms.
>awareness of universal time.
You know NTP is extremely flawed, because we don't have 17 satellites across our solar system to prove universal obsevation of our ever expanding universe for a relavistic observations of time, right? The delay I'm referencing is just raw TCP, sometimes routes hang. Sometimes, traffic needs to be reshaped, sometimes the postage date a message was made is so old it doesn't need to be order by timestamp, but FIFO, like all things are.
NTP is a joke, nobody serious about real time uses it, they use actual uranium clocks, and trigger them manually, sometimes with combustion relays.
Did you know before we observed time by looking at the sun we used precise volumes of oil and wax to meassure time? Later hourglasses became the next hot thing.
But who cares, "everyone" values messages based on a timed packet bomb we call NTP, a federated vulnerable system.
>and you're fucking idiot. great argument, isn't it?
Well, I don't want to say it to your face, since you already said you had memory issues, but I'm sure we agree that you can't understand _why_ time is relative and flawed, in any network requiring redundancy and "consistency".
If you wanted "consistency" across a front end, maybe you should have chosen a nested model of representation. Even week old replies look consistent nested anyways. Not that the human observers ever notices how old articles are in reference to the entire thread.
But what do I know, "I'm the idiot that has to reword everything for a 5 year old."
>we're converting everything to UTC for processing either way
You wish. Convert Yidish calendars to UTC, Tel Avi requires it send a nuke your way.
>not checking that can lead to pre-bumping of threads
>>How does this relate to time? Isn't this a frontend configuration domain?
Seriously, you never answered how prebumping has anything to correlate to already created threads. If the article came today, but written before UNIX Epoch, why and should it "prebump"?
Just because I refuse to write in Go, doesn't mean I'll ever support your implementation of what you envision your frontend to be. Aren't you confusing your juniority because my critique against how you order threads makes you feel incompetent?
>We actually can have no idea if ANY part of message isn't fucked right now.
I cited way above, and reitate to newcomers all the time, we are working under alpha software, there's no need to patronize yourself. Programming and design are a slow process, it takes years to master, years to finalize. And most times, it never gets "done."
>I really really wanna just make message-id be hash of msg body.. and then every server would check their incoming articles, and reject incorrect ones.
Now this an honest proposal.
>corrupt message is worse than no message.
But corrupt messages are important: they tell you something is wrong, needs to be checked, and corrected. A resilent system which we don't have now, tells the peer to resend it, because something was corrupt. It's important to say where and how, and what can be done to correct it in the future.
We are so alpha, _I_ have to tell you this, not ideal nekoserver.
>Can we just accept the fact that it's flawed, and focus on making this work better despite it being flawed?
No, because if you feel this strongly that corrupt messages _are bad_, evaluating a flaw in design IS WORSE. Do you really want lost articles in time and space forever from this network?
>I think I made myself clear that I'm not removing Date headers anytime soon.
Oh crystal, and like my invitee said:
>a lot of malicious servers/servers with their date being off, huh? As the federation grows this will get worse and worse.
Your design choice, not mines.
>xt.b_id = zbp.b_id AND xt.t_id = zbp.t_id
Are you writting this with aliens in mind, or in a language for five year olds to install and peer with?
Now, what happens when zbp.t_id == zbp.b_p_id? My e.g. use every post came at the same time, except one.
>It's absolute universal time.
Unless you have an uranium clock on your laptop, you are obviously shitting yourself.
>Convertible to clean absolute integer value.
Well, there goes my nanoseconds. Time to refreshes my cycle again.
>flawed assumption right there. In-Reply-To only happens if you refer to post. if you don't, it won't happen.
No, that's your design flaw, because the raw In-Reply-To always should yield the `Reference` if no reply to was made.
>your "solution" will result in nA and nB having different sorting of messages than nC.
Duh, you are the one that wants arbitary consistency across some reference of time that's only relative to _yours_.
nCharlie can only observe what he got, according to when he received it.
Are you forgetting nCharlie's network is slow, and will always have articles come in differently than nAlice and nBob's? What are you, negative spacetime?
>In fact, they couldn't, because nB didn't see nCmA, and nC didn't see nBmB when each of them posted. so they couldn't have referred.
So `Reference:` never existed, and the "date:" fixes that?
You are the one that wants to tackle in a timestamp to when an article was sent.
nA nB nC know messages are always relative to each other, and their times are always different. The only consistency they have is "this a article comes from nX".
No checksums, no handles.
>message-id being cryptographic hash is not done nor deployed yet. if you were using that then yes you could check. otherwise no.
I'm sorry SNRD & v2 never implemented article Atomicity, Consistency, Isolation, Durability? I didn't design them, so don't ask for any Consistency UTC was never going to give you? In fact you don't have Uranium on your house, so HOW REALLY DO YOU KNOW IT'S 2019-8-16 04:54:00?
Anonymous No. c7346e5d2a7fc1ad3df1 >>4f788568eeeacabe9f6d
Message-ID: <8000002taos86.ep4vatfobi18mc0e@nekochan>
Date: Fri, 16 Aug 2019 05:00:51 +0000
From: <poster@nekochan>
In-Reply-To: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org> <2f7b21565927643@web.oniichan.onion>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>

File: sticker@2x.png (370x320, 36.839 KiB)

t7tn23tx5k3xdjsva5jmegj3om4vyqsynxjxmtrdjegqi-b2b.png

File: StarFox Snes -(...).webm (102.155 KiB)

dgevs6haxij6kh3d274rqg2koib5ug3m4ikk7g25g4au4-b2b.webm
>well I'm trying to make it less flawed, but removing Date header will make it only more flawed, I believe.
You, just, proved, to, _youself_ a flaw flaws a flawed network.
I don't need to be here to tell you dates define your current implementation flawed.
I'm saying, like my invitee, and you just considered, checksuming the article _should_ be the message ID.
In fact, I'll complement your idea, since you want some "consistency" across peers:
Before an article gets made, the LAST ARTICLE THAT WAS IN THE SERVER FOR THAT THREAD WILL BE THE `In-Reply-To` OF THAT ARTICLE, REGARDLESS WHO THEY QUOTED. THE `Reference` WILL ALWAYS BE OBSERVED, IF NOT, A NEW THREAD IS GENERATED.
e.g. for my beloved cute cathuggger:
The Reference of this thread is: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
the In-Reply-To SHOULD be: <2f7b21565927643@web.oniichan.onion>
AND IN THE EVENT `Reference` IS MISSING, MY ARTICLE GETS MADE ACROSS ALL PEERS AS IT'S OWN THREAD, AND A NEW `Reference` IS MADE TITLED <$checksum@nekochan>
This is a cute idea, no?
That way, even if Charlie and Bob got Alice's message at different "times", some order is restored since there's a chain of `In-Reply-To`s no matter what.
@ or more In-Reply-To MUST BE ordered FIFO, as too keep collisions from occuring.
>More likely I'd just start nagging admin of fucked up node to fix their shit tbh.
HOW? We are trying to make this network contained, how other way will you "nag" when your articles aren't reaching them?
>I've had messages just not propagating because of nntpchan's shittyness and that felt real bad.
Me three, and SRNd didn't fix these either.. We are here to correct them forever, no?
>one the go devices aren't nodes, are they?
They are, because our planet is always moving. Even the Poles are shifting.
In fact, our target models should be Nokia 3310 because it's the single most polar computer in the entire planet, and not the universe.
Imagine sending an article with whatever computer Uranus species designed, yeesh.
>I aint going to twist my design in fucked up ways to work around thing which is rare.
I'm siging all my "Dates" to 2038 days forever then....
>connectivity problems between nodes is very really more likely than times being off.
And you want to rely on NTP.... I'm sorry what?
>it's hard one to solve. especially because SRNdv2 had backward compatibility with SRNd problems too.
Thanks! Let's look forward on what we can do _today_!
>I wasn't really around back then. You sure he left because of that? I'd like to hear more.
The only real stuff I do recall, since many of us were really really decentralized is what Jeff recalls, and someone I'm not at liberty to discuss.
Jeff did mention he left because it was inelegant and found something else to work on. We haven't heard of him since, only that he lived in Canada at one point of his life.
_I_ too consider NNTP as a datastore completely inelegant, and am concentrating on a post quantuum bittorent model. The way forward HAS to be peer to peer, because we can no longer trust on ISP, governments, or next door neighboors.
The global trust issues are obsolete, we need to look even forward and beyond in our post-quantuum hellspace.
>I think jeff made it kinda clear that he intends to full switch to nksrv once it gets all the features of srndv2.
Why I'm being anal about everything....
>tbh nntpchan/srndv2's codebase is pretty fucked, it does lots of things in wrong ways.
Completed agreed.
>full of behavior some people might consider to be outright buggy.
Why either SRNdv2 needs a fix, which Anoncheng foresaw, or SRNdv3 needs to come fast, and there's only 3 of us really here "left".
>Oh yeah it would be nice to have something like that.
Thanks. Bittorrent already has all that in specs, I'm adding more post quantuum, and sharing tons of ideas on how ActivityPub therefore pubsubhubbub did things.
Ideally we won't even need RSS clients to bittorrent clients anymore for this semiautomated behavior and DHT sharing. Will be be using a trick already all clients have to update parts to update new information.
But yeah, this is a 6 month plus project, and only original bittorrent and libtorrent are working on it. SO MANY THINGS TO FIX, SO LITTLE HELP!
If I'm ever paid for this, I could finish it faster, and hire people too. Sucks to work in libre software.
Later my cutie. Don't take things personally. It just frustrates me when I see people not confronting their logic through the end. If you know something, you have to play all the wrongs and rights before you do something.
This stupid debate started _because_ I could foresee the current idea for nekoserver will effectively break off articles and fracture the entire network. Something as stupid as date refusal.
Whatever you do, do not read ActivityPub or pubsubhubbub. Zot protocol was built to last.
Our zoomers in USENET did not forsee this far, and easilly got most ISP to drop support. I do not want to replicate the same history with SRNdvX.
Good luck!
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. e128febdf7e53feb58ca
Message-ID: <8000002tapt3k.ql015452btiekg1p@nekochan>
Date: Fri, 16 Aug 2019 09:41:14 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <2f7b21565927643@web.oniichan.onion>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 85b66581bd8f85579fe3bc58d9e8811cd2b40d393ccb5f00f791d829e814244d9ccd82299c03580d63c4f8b9ed3fae8f0e753ff28d9b5d355562b086bafc200e
>>e3a3b3c15e07e6379311
>Why is this, desired? Wouldn't OP node decide how "consistency" should be across all articles in a thread, and not delegated via an arbitary value?
yuh, option "please sort msgs in non-deterministic order across nodes". people will definitely check it.
>And what the hell does administration have anything to do with a ensuring articles get passthrough the entire network?
Not the point I was making.
>I demonstrated, and NSA node, that your refusal to ignore date headers is causing articles to be lost. Is that how you achieve decentralization dropping articles because it doesn't reflect _a_ peer's "time"?
Well, once time specified in such article's Date header is reached, it can actually propagate. We didn't do anything stupid like banning its Message-ID.
>So you prefer Kindergarden criticism?
>Hey cathugger, it's bad to ignore messages from Charlie because they were "too slow" to deliver.
>Cause, I can choose that if you want.
k.
>>It's your issue that you couldn't formulate problem in a way I can understand without needing to guess details.
>I'm sorry you were dropped as a child, have memory problems, and can't observe an article in exemplus gratus scriptus. I'll just remind myself in the future to converse with you in child speak.
>Mommy showed you metaphors work, right?
and you still haven't properly formulated the problem. your loss, I'm not digging into it.
>You've never heard of submarine datacenters, figures. Forget satellites, this boy forgets the entire world has expontencially 4 times more cellphones than your average static colocated piece of x86 virtual farms.
Absolutely irrelevant.
Phones changing location won't fuck up their awareness of universal time.
And people probably won't host NNTP servers on their phones (why would one do this??).
Please live in a real world.
>You know NTP is extremely flawed, because we don't have 17 satellites across our solar system to prove universal obsevation of our ever expanding universe for a relavistic observations of time, right?
We can tolerate less than ideal conditions. NTP (and even SNTP) are good enough for what we do.
But once again, you literally can't handle something being non-perfect it seems, even though these imperfections won't bite us.
>The delay I'm referencing is just raw TCP, sometimes routes hang. Sometimes, traffic needs to be reshaped, sometimes the postage date a message was made is so old it doesn't need to be order by timestamp, but FIFO, like all things are.
"sometimes THINGS happen"
in any case with TCP or any other kind of transport delays, it looks better with sorting by Date header.
it seems that you just want messages new to local node to appear at the end, and not be inserted in the middle.
well, I sorta can relate, but it breaks badly on initial sync, on cut connections, on shit transport routes.
>NTP is a joke, nobody serious about real time uses it, they use actual uranium clocks, and trigger them manually, sometimes with combustion relays.
As long as we're within few seconds of real time, it's fine. It really is fine.
We don't care about nanosecond or higher precision. We don't even care about microsecond precision. We can tolerate time being off in the future direction up to even 5 minutes.
But once again, you just proved that you can't imagine using non-absolutely-perfect tools for their intended jobs, even if their imperfections don't actually hinder their intended jobs.
We don't care about actual real time. Some imprecision is fine.
But because your brain cannot accept that, you seem to be unable to relate to anything I say.
>Did you know before we observed time by looking at the sun we used precise volumes of oil and wax to meassure time? Later hourglasses became the next hot thing.
Not really relevant.
>But who cares, "everyone" values messages based on a timed packet bomb we call NTP, a federated vulnerable system.
I wouldn't use it for where I would need actual true real time. But I don't need that.
>Well, I don't want to say it to your face, since you already said you had memory issues, but I'm sure we agree that you can't understand _why_ time is relative and flawed, in any network requiring redundancy and "consistency".
I do understand, but I'm pretending that I don't.
I'm ignoring my own understanding, because alternative will work worse.
Didn't I say that I used to sort by received sequence? Yes, I predicted that relying on Date will be incorrect.
But in the end I chose to do it this way anyway. We're building on top of broken system, rejecting parts of it because we don't like it won't do us much good.
You gotta weight consequences of your actions. Right now you only follow your intuition.
>If you wanted "consistency" across a front end, maybe you should have chosen a nested model of representation. Even week old replies look consistent nested anyways. Not that the human observers ever notices how old articles are in reference to the entire thread.
Well, that's more of UI question. I don't wanna reddit I wanna imageboard.
>But what do I know, "I'm the idiot that has to reword everything for a 5 year old."
k.
>You wish. Convert Yidish calendars to UTC, Tel Avi requires it send a nuke your way.
Absolutely fucking irrelevant, Date header is fixed format. And yes, we will reject if we don't understand format of it.
It's specified in internet message format RFC.
>Seriously, you never answered how prebumping has anything to correlate to already created threads. If the article came today, but written before UNIX Epoch, why and should it "prebump"?
It obviously wouldn't bump. It'd be the last one in board. Like it is now.
By prebump I meant future-dated articles, coming into existing thread, and thus bumping it.
>Just because I refuse to write in Go, doesn't mean I'll ever support your implementation of what you envision your frontend to be.
You can write it in whatever. Just be compatible in format of articles you make.
>Aren't you confusing your juniority because my critique against how you order threads makes you feel incompetent?
Not really.
>But corrupt messages are important: they tell you something is wrong, needs to be checked, and corrected. A resilent system which we don't have now, tells the peer to resend it, because something was corrupt. It's important to say where and how, and what can be done to correct it in the future.
Err, first it needs to detect corruption.
Which is why we need hashes.
Otherwise it'll just propagate broken message across the net and there will be no way to fix this broken copy everywhere.
When admins notice it'll be already too late. Harm will be hard to undo.
And yes, resilient system will tell that it's wrong and should be resent. But it has to detect corruption before it can tell that.
>We are so alpha, _I_ have to tell you this, not ideal nekoserver.
k.
>No, because if you feel this strongly that corrupt messages _are bad_, evaluating a flaw in design IS WORSE. Do you really want lost articles in time and space forever from this network?
Lost articles because they have header too far in the future aren't lost. They can propagate once that date they specify is reached.
>>xt.b_id = zbp.b_id AND xt.t_id = zbp.t_id
>Are you writting this with aliens in mind, or in a language for five year olds to install and peer with?
>Now, what happens when zbp.t_id == zbp.b_p_id? My e.g. use every post came at the same time, except one.
Wow haha that's not actually relevant part, you really don't know SQL.
>Unless you have an uranium clock on your laptop, you are obviously shitting yourself.
Egh I don't actually need more than second precision.
Didn't I say that already?
Why would such system need that..
>Well, there goes my nanoseconds. Time to refreshes my cycle again.
Yep, it's integer value in seconds. It won't include milliseconds, microseconds, nanoseconds..
>No, that's your design flaw, because the raw In-Reply-To always should yield the `Reference` if no reply to was made.
yeh but it's irrelevant.
Either way you know what thread you are replying to.
But you can't restore correct order.
>Duh, you are the one that wants arbitary consistency across some reference of time that's only relative to _yours_.
Well, time doesn't flow at different speed for you, right?
>So `Reference:` never existed, and the "date:" fixes that?
Errr you're mixing stuff up.
Reference always point to OP.
but you won't get it either way.. so I'll stop trying to explain to you.
Anonymous No. 035421ea49a68d27ae90
Message-ID: <8000002taq9fg.7blh374vs6qa5ss7@2hu-ch.org>
Date: Fri, 16 Aug 2019 11:26:48 +0000
From: <poster@2hu-ch.org>
Newsgroups: overchan.random
Path: 2hu-ch.org!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
big pedantic arguement thread? on MY overchan.random? it's more likely than you think.
cathugger☽︎☟︎☻︎☾︎♰︎►︎◯︎♺︎☖︎⚇︎☱︎►︎ No. 4f788568eeeacabe9f6d
Message-ID: <8000002tascde.6k7f3ja2civsjm7m@nekochan>
Date: Fri, 16 Aug 2019 20:57:59 +0000
From: cathugger <poster@nekochan>
In-Reply-To: <8000002taos86.ep4vatfobi18mc0e@nekochan> <8000002tamqcg.upvu24p348dk6jgu@nekochan>
Newsgroups: overchan.random
Path: nntp.2hu-ch.org!nekotest!nekochan!.POSTED!not-for-mail
References: <8000002ta2jpe.2orfi44mcj9lavqi@2hu-ch.org>
X-PubKey-Ed25519: ad8fabaee02abdb56979855c4f370fd0c754538a1c006d0431515fea86f7a12a
X-Signature-Ed25519-SHA512: 88888228cdd82407a93a86f64a2848f5272fa16f0f2ac58fdda75010db474e073dd8f687c4f9424a0b2607c430a0852e12dedaef0c36a7ea18beb8ce41c1650d
>>c7346e5d2a7fc1ad3df1
>You, just, proved, to, _youself_ a flaw flaws a flawed network.
>I don't need to be here to tell you dates define your current implementation flawed.
Yeh. I'm not denying that it's flawed. But alternatives are even worse.
>I'm saying, like my invitee, and you just considered, checksuming the article _should_ be the message ID.
that's more of bitrot/data corruption bugs protection tbh, but yeh it could be utilized for doing chains too.
>In fact, I'll complement your idea, since you want some "consistency" across peers:
>Before an article gets made, the LAST ARTICLE THAT WAS IN THE SERVER FOR THAT THREAD WILL BE THE `In-Reply-To` OF THAT ARTICLE, REGARDLESS WHO THEY QUOTED. THE `Reference` WILL ALWAYS BE OBSERVED, IF NOT, A NEW THREAD IS GENERATED.
I identified flaw with this in >>db73eddbc201763ca3a8 (end of it)
This would work if there would be no delay between nodes, but it wouldn't if nodes are arbitrarily disconnected temporarily.
It wouldn't work for fast (like lots of people posting at once) posting from multiple nodes either, if time between posts in different nodes is less than time nodes travel.
Basically histories would diverge.
This sort of solution basically needs single events chain, synchronized across nodes. Single history, so to speak.
It wouldn't allow one to temporarily disconnect from such chain and still keep posting like that's possible now.
One such solution could be trusted timestamping. But it's sorta centralized, we would need to have list of keys we would trust to timestamp...
Another is auxiliary (not NNTP based) hash chain synchronized using some protocol which is actually fast and could do global consensus (think bitcoin / certificate transparency kind of stuff).
Without these it's flawed.
With these, it'd stop being pure NNTP anymore (either connectivity to timestamping server requirement, or connectivity to consensus thingie requirement).
All of this sucks.
Now lets look into just using date.
It's essentially just single integer. And we just sort by that integer mostly.
It works right now. Yes there are few failure cases but it is able to make any different nodes in network look the same. Because all of them see the same Date headers.
Even if their time sources are fucked, they will still see stuff sorted the same. It's just that they may be at wrong places in that case. But these will be in wrong places consistently in all nodes.
It's simple, it's predictable, it doesn't need anything other than NNTP connectivity, it tolerates slow links and converges despite temporary disconnects.
>AND IN THE EVENT `Reference` IS MISSING, MY ARTICLE GETS MADE ACROSS ALL PEERS AS IT'S OWN THREAD, AND A NEW `Reference` IS MADE TITLED <$checksum@nekochan>
Egh, we currently treat missing reference as its own thread's OP. That's simple and predictable.
Thing you're describing, it doesn't need to happen for this to work.
>@ or more In-Reply-To MUST BE ordered FIFO, as too keep collisions from occuring.
Yes, even you can understand that it must be single chain. But that's not simple to achieve when there's lag across nodes.
>HOW? We are trying to make this network contained, how other way will you "nag" when your articles aren't reaching them?
Sorta true. But hey it's not always that bad, I can successfully talk to some of admins in irc.
>>I've had messages just not propagating because of nntpchan's shittyness and that felt real bad.
>Me three, and SRNd didn't fix these either.. We are here to correct them forever, no?
tbh I wish I had good solution for that but I don't. I don't wanna make feature scope too big, that'd only make development harder for me.
>They are, because our planet is always moving. Even the Poles are shifting.
>In fact, our target models should be Nokia 3310 because it's the single most polar computer in the entire planet, and not the universe.
>Imagine sending an article with whatever computer Uranus species designed, yeesh.
Sounds fucking cool goal tbh, but this aint very achievable. These nokias didn't have a lot of RAM.
>And you want to rely on NTP.... I'm sorry what?
if NTP fails, RTC will keep shit running more or less with correct time still. You're thinking only in absolutes too?
>Thanks! Let's look forward on what we can do _today_!
Well, suggestion of ditching dates wouldn't be backwards compatible with srndv2, because it uses dates too.
>_I_ too consider NNTP as a datastore completely inelegant, and am concentrating on a post quantuum bittorent model. The way forward HAS to be peer to peer, because we can no longer trust on ISP, governments, or next door neighboors.
I'm not sure what post-quantum has to do there with anything. Is it just buzz-word now?
>The global trust issues are obsolete, we need to look even forward and beyond in our post-quantuum hellspace.
Yep it's buzzword.
By the way, quantum computers won't affect core torrent protocol. Maybe only signing-related BEPs.
>Why either SRNdv2 needs a fix, which Anoncheng foresaw,
It'd be probably jeff's job. I actually wish he still maintained his stuff... software monoculture aint always good, but on the other hand I had to fix srndv2 because it relied on shit being wrong way to work in some cases.. so I'd also feel not too bad if I didn't have to deal with broken software.
>or SRNdv3 needs to come fast,
aint nksrv sorta srndv3? tbh I didn't actually look into insides of either one much, and I tried to do my own thing, thats also sorta why I didn't name it as srnd*.
>and there's only 3 of us really here "left".
we really need to make webui look pretty. I think that's more important now, to have feature parity and good interface to browse, post, moderate and administer.

thanks for cool discussion, even though it was huge waste of time for all of us probably, it's still kind of fun.


New reply

Captcha captcha image