/prog/ - I've seen terrible things

Name: Anonymous 2013-08-13 10:43

Like:
* le /g/aylords trying way too fucking hard to fit in (they already learned le e[spoiler]/prog/[spoiler]in memes, /prog/ro!)
* le same e/g/in /g/ros imitating lelcunt unironically and thinking this is the default form of protesting here
* /g/roskis trying to bring their `daily programming threads' here
* e/g/in re/g/g/it e/g/g/wings bitching about the state of the board and not leaving (like a weeaboo who went on a trip to Japan, bitches about their lack of forks and knives and doesn't go the fuck back to his third world country)

So I've set up a reasonable amount of machines to flood once again. I might have to space out the replies at some times, because I'd rather avoid the situation where all my machines get banned from 4chan.

I'm sure most of you won't accept my form of protest, but for me it seems like an efficient way of improving the board's quality. After the first flood wave, the moderators started coming here more often, which is not the optimal solutions but at least it kept the recent threads programming-related. I do have to admit I miss Nikita and some of the original /anus/ shitposting, but my purpose is not bringing more moderators, it's keeping the shitstains out of here.

Yes, this will make them engage e/g/in mode, because I remember reading on a /g/ troll bait thread about how they loved pissing us off, so I advise you to ignore their unoriginal shitposting from now on.

The setup will take me about one week, so expect the flood to start next week. I'm aiming for at least 15 days, but it's very likely to get banned, so the flooding might not be as continuous as I'd like it to.

Name: >>98 2013-08-21 7:03

>>103
* We'd have to see the standard you propose.
Here is a very unofficial and preliminary snapshot of the standard. Your thoughts?

============================================ Post representation Let H160(x) denote the last 160 bits of SHA-256(x). Let sbase64(x) denote base64url(x) (as defined in RFC 4648) with all non-encoding characters stripped (including the "="). Each post is identified by the sbase64 representation of its H160 hash. All strings are UTF8 unless otherwise specified. A post consists of the following concatenated fields: <thread> '\n' <timestamp> '\n' <author> '\n' <email> '\n' <pk-data> '\n' <body> Except for `body', the fields MUST NOT contain the '\n' character. The '\0' character MUST NOT occur anywhere inside a post. If a post is not a thread starter, then the `thread' field references (by its sbase64'd H160 identifier) a thread starter post. If a post is a thread starter, then the thread field consists of the following: <board-name> ' ' <thread-title> where `board-name' MUST NOT contain the ' ' character. Except for `body', the fields MUST NOT contain the '\n' character. The '\0' character MUST NOT occur anywhere inside a post. The length in bytes of a post MUST NOT exceed 131072. All fields above MUST NOT contain any '\0' characters. `timestamp' is a string representing an integer representing Unix time at which the post was created. The timestamp MUST NOT be smaller than the timestamps of the posts it references within. The timestamp MUST NOT be more than 600 seconds in the future. If the `author' field is a zero-length string, a viewer SHOULD display it as "Anonymous". `pk-data' MUST be either a zero-length string OR the following: <pk-version> ":" <ed25519-public-key> ':' <ed25519-signature> where `ed25519-public-key' and `ed25519-signature' are the 32 byte public key used to sign the post and the 64 byte signature respectively, encoded using sbase64. The value of `pk-version' MUST be "0". The signature is taken over the post itself excluding the `pk-data' field and the newline right after it, i.e. <thread> '\n' <timestamp> '\n' <author> '\n' <email> '\n' <body> If the `pk-data' field is nonempty, then the signature contained therein MUST be valid. ============================================ Sync protocol Please note that in this document, we only use "client" and "server" to distinguish between two peering users. The "client" and "server" do not play different roles. Really, the only difference between the client and the server is who gets to do requests first. The initial handshake is as follows: C: "DISTBB V1 SYNC" '\n' S: "SYNC DISTBB V1" '\n' The client may then place some requests (as described below). When it is done doing so, it MUST send the message "YOUR TURN\n" which signals to the server that it can now begin placing requests on the client. When the server is done, it should simply close the connection. A request is either a "LIST" request, or a "GET" request. A "LIST" request is as follows: "LIST " <newer-than> <public-key>* '\n' where `public-key' is " " <pk-version> ":" <ed25519-public-key> and `pk-version' and `ed25519-public-key' are as described in [representation.txt]. `newer-than' is an integer representing the Unix time that the posts which will be returned must be newer than (according to their `timestamp' field). The response to a "LIST" request is a space-separated list of <matches-key> <post-id> followed by a newline. `matches-key' is "!" if the post referred to by `post-id' is signed by one of the keys listed in the "LIST" request, or the empty string otherwise. `post-id' is, as defined in [representation.txt], the sbase64 of the H160 of the post's contents. A "GET" request is as follows: "GET " <post-ids> '\n' where `post-ids' is a space-separated list of post IDs (as described above). The response to a "GET" request is a list of posts, with a '\0' terminating each post. [[TODO: GETALL request to speed up initial sync]] Example session (strings have been shortened for clarity): C: "DISTBB V1 SYNC\n" S: "SYNC V1 DISTBB\n" C: "LIST 1377043210 key-1 key-2 key-3\n" S: "post-1 post-2 !post-3 !post-4 post-5\n" C: "GET post-3 post-4\n" S: gzip_of(post-3-contents... '\0' post-4-contents... '\0') C: "GET post-5\n" S: gzip_of(post-5-contents... '\0') C: "YOUR TURN\n" S: LIST 1377030000 key-4 C: !post-6 post-7 S: GET post-6 C: gzip_of(post-6-contents... '\0') S closes connection. C closes connection.

I've seen terrible things

1 Name: Anonymous 2013-08-13 10:43

140 Name: >>98 2013-08-21 7:03

Name: Anonymous 2013-08-13 10:43

Name: >>98 2013-08-21 7:03