>>3118246 (lb)

Here is some Pseudocode to show how Q could do it with database access on 8 only chan. Easy peasy. This would be one way to do it. Short enough delay that no one would notice that Trump posted first.

wait for (trump post to go live on twitter) {

read timestamp of twitter post

// These would be at the same time

create chan post in database

set timestamp to chan post 17 seconds in the past

make sure display post flag is true

}

another option

create chan post with display set to false

wait for (trump post) {

set timestamp to 17 seconds in the past

set display to true

}

Not saying this is how its done, but its possible to do with only database access on one server. If Q had Twitter access, it would be the same logic just in reverse with time added instead of subtracted.

>>3118399

Can't control network lag, which Q himself said. Therefore if he hit 17 seconds, he swung for the fences and hit a homerun as an anon said last bread or he modified the database. When you post does not guarantee what timestamp you get. Try it yourself, see if you can hit the second you are shooting for on Twitter or the chans. You can't. Best you can do is +/- a couple of seconds.

>>3118492

True, but here is a ping of 8ch.net I just did. Just hitting it over and over, it varies by .14 second with a simple ping (quickest request) during the night shift and not in the middle of a Trump speech with Q being chatty. When Q was posting everyone was complaining on how slow it was so the performance was much worse. The point being, Q is lucky or he has special access. People saying the simple explanation is because they were trolling Dems after the rally hitting send 17 seconds apart is not correct.

64 bytes from 104.20.43.57: icmp_seq=0 ttl=50 time=143.449 ms

64 bytes from 104.20.43.57: icmp_seq=1 ttl=50 time=44.495 ms

64 bytes from 104.20.43.57: icmp_seq=2 ttl=50 time=14.317 ms

64 bytes from 104.20.43.57: icmp_seq=3 ttl=50 time=10.423 ms

64 bytes from 104.20.43.57: icmp_seq=4 ttl=50 time=14.508 ms

64 bytes from 104.20.43.57: icmp_seq=5 ttl=50 time=12.117 ms

64 bytes from 104.20.43.57: icmp_seq=6 ttl=50 time=11.511 ms

64 bytes from 104.20.43.57: icmp_seq=7 ttl=50 time=19.556 ms

64 bytes from 104.20.43.57: icmp_seq=8 ttl=50 time=14.585 ms

64 bytes from 104.20.43.57: icmp_seq=9 ttl=50 time=11.974 ms

64 bytes from 104.20.43.57: icmp_seq=10 ttl=50 time=16.370 ms

64 bytes from 104.20.43.57: icmp_seq=11 ttl=50 time=37.032 ms

64 bytes from 104.20.43.57: icmp_seq=12 ttl=50 time=34.603 ms

64 bytes from 104.20.43.57: icmp_seq=13 ttl=50 time=30.337 ms

64 bytes from 104.20.43.57: icmp_seq=14 ttl=50 time=27.126 ms

64 bytes from 104.20.43.57: icmp_seq=15 ttl=50 time=15.233 ms

64 bytes from 104.20.43.57: icmp_seq=16 ttl=50 time=112.534 ms

64 bytes from 104.20.43.57: icmp_seq=17 ttl=50 time=10.706 ms

64 bytes from 104.20.43.57: icmp_seq=18 ttl=50 time=11.041 ms

64 bytes from 104.20.43.57: icmp_seq=19 ttl=50 time=12.369 ms

>>3118592

Correct, the delay would be even greater doing a post based on the packets being sent and then you have actual server processing going on, that you don't have with a ping and since every post is unique with heavy load there is some blocking going on if posts come in at the same time with the database insert as well.

>>3118645

My guess is what happened after the first posts didn't match up, some computer geek stepped in from the NSA and went "TWF, did you really think sending at the same time to different platforms would generate the same timestamp?, what time delta do you want? I'll handle that."

Seems like that person got Q and Q+ (or whoever handles twitter for Q+) setup to make it happen. If you look at all the Q candidates they wouldn't understand at first why the first delta didn't work down to the second, while it did work for minutes.

>>3118776

The code is open source https://github.com/OpenIB/OpenIB/ CM made custom changes that to my knowledge haven't been added back to the original source and I do not know if that is available for anyone other than CM to view.