Autism BBS

Lately the technical imperfections and design of shiichan started to get on my nerves(not including the constant shitposting) so i decided to create my own BBS. The feature set is not finalized yet, and some improvement in design might be possible(comment?).
Here is the first draft of what is coming:
* Open Source, using only free code
* Performance/bandwidth oriented
* Minimal processing, no BBCODE,only filters html tags and autolinks URLs
* C without any OOP or platform dependent code
* Very spartan text-only design, no CSS/JS or any external files
* Threads are stored as files in directory as ThreadName.Page generated as follows: 16 char random string THREADID and each 1000 posts(numbered from 0 to 999,1000-1999,etc) is a new file. e.g. /ls78saflGKsu9238.0  is first(zeroth)page of thread ls78saflGKsu9238
* replies consist of post number+text only, no name,email or timestamp, First line of first post in the thread is the thread title.
* Replying to a thread reloads the same thread page,like noko.
* no sage or bump feature, instead there is such system:
1.each new post in the thread swaps its(thread list) position with thread one cell higher(if at top, no change). If the post contains the same text as any of previous replies or only a quoted part of previous post, it does not change the order.
2.new threads start at the top of thread list.

* Open Source, using only free codeShiichan is already open sores.
* Performance/bandwidth orientedNot like world4ch is getting much traffic at all. 2ch would be an example of board which is traffic-intensive. Of course, almost everyone can be better than PHP's performance.
* Minimal processing, no BBCODE,only filters html tags and autolinks URLsBoring if you refuse to include BBCODE. You should at least allow Sexpcode and possibly TeX.
* C without any OOP or platform dependent codeEnjoy wasting your time. I'd rather use Lisp for high-level server applications like this. Implementing extensions would also take a while. I see no problem with using C for performance-oriented server daemons, but for a text-board?
* Very spartan text-only design, no CSS/JS or any external filesIf you're going all retro and minimalistic, why not just use mailing lists, Usenet and IRC? It's what most programmers and academics use for discussion, it's standardized and has many clients written for them. If you're writing it for web, at least tag the HTML so users could supply CSS and change the font and layout.
* Threads are stored as files in directory as ThreadName.Page generated as follows: 16 char random string THREADID and each 1000 posts(numbered from 0 to 999,1000-1999,etc) is a new file. e.g. /ls78saflGKsu9238.0  is first(zeroth)page of thread ls78saflGKsu9238Hardly better than Shiichan.
* replies consist of post number+text only, no name,email or timestamp, First line of first post in the thread is the thread title.Timestamp is useful. Name can be partially useful at times if you want to indicate your identity/previous posts (in the absence of ID, which shouldn't be present due to security issues) to prevent confusion.
* Replying to a thread reloads the same thread page,like noko.Okay.
* no sage or bump feature, instead there is such system:
1.each new post in the thread swaps its(thread list) position with thread one cell higher(if at top, no change). If the post contains the same text as any of previous replies or only a quoted part of previous post, it does not change the order.
2.new threads start at the top of thread list.1 is a new idea, slightly interesting, but troublesome to implement in practice without getting defined better. It seems the core of your idea is that threads should be raised by the amount of new information they provide, but finding out how much new information is provided is a HARD problem. My idea on how this could be done is to attempt to compress using a dictionary made from previous posts (that would be considered as "amount of new information"), however this could be bypassed by generating random data, which would not compress at all, and a defense against this idea would be to measure the entropy/randomness using statistical methods, then calculate the final score (by how much to raise) as a combination between those 2 scores, however even that can be gamed, for example using Markov-chain based text generators (and if you defend against that, it will just require more randomization to reach a sweet spot that your algorithm finds scoring high), in which case the next best way to decide how a thread should be raised would be something like a human-based detected (or some AGI), in which case, if you're using humans you basically end up with text-based reddit (with scores).

The conclusion thus becomes, back to /reddit/ or just use Usenet/mailing lists/IRC.