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.

That design is shit. Also,

no plattform dependent code

I'll never understand this.

>>2
If its shit, explain why.
>I'll never understand this.
 Something which is faster, but works only on one platform(like DirectX drivers for latest cards).
In general code which contains unportable bithacks,assumptions on variable types and OS-level calls.

>>3
Ok, I thought that you were speaking of portable coed that I usually disregard as faggotry.

Why don't use a webserver? Why put it all on a standalone app?

>>4
Why don't use a webserver?
Too much overhead, it's bloated.

>>5
http://www.cherokee-project.com/

also, httpd is the standard

>Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, uWSGI, SSI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Load Balancing, Apache compatible log files, Data Base Balancing, Reverse HTTP Proxy, Traffic Shaper, Video Streaming and much more.
I don't need such bloatware for handling POST forms and reading files.

javascript HTML5 interface built on a restful API with backbone.js + jQuery for the UI, and Github for the backend.

Vaadin interface communicating with a Scala backend running on Tomcat, employing a H2 database for storage to leverage pure Java technologies, thus ensuring portability.

Very nice, except for your bumping system which is fail.

You should try mixing in assembler and lisp there, too. Just to get a full buzzword bingo..

Code it in whatever, use a good DB, and most importantly.... Make it scale, and .. CACHE EVERYTHING!

You also need to implement an automated dossing of posters using the word 'touhou'.

Oh, and nginx and cherokee is perfect lightweight webserver for this kind of stuff.. And probably better than whatever you'll cook together (and even if you do manage to put a lightning fast, standard compliant, scalable and secure web server together, prepare to spend months just on that).

Seriously, build it modular. Find an effective interface between server and code. No point in rebuilding the wheel, when people have spent years perfecting wheels for just the things you need to do.

write it using a keyboard

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

Provide a cli tool for reading/posting and I'm in.

no BBCode
so it's not useful for programming?

>>17
If you want programmable web content host a webpage and link to it. You could use much more impressive than simple BBCODE(html5, webGL, JS, Plugins).
If you want to post huge code with highlighting - http://pastebin.com/
If you just want to make you post fancy/unique/shiny/sparkling - go back to Gaia.

>>1

http://9ch.in/overscript/

>>16
telnet interface with readind/posting,like pre-internet BBSes? Its not that hard, and anyone already has a telnet client
>>13
>And probably better than whatever you'll cook together (and even if you do manage to put a lightning fast, standard compliant, scalable and secure web server together, prepare to spend months just on that).
Just a webserver which serves flat-file html pages and handles BBS posts from users. Its not meant to be multipurpose or standards compliant. It could be a bit faster since its a dedicated server, without any code bloat.
>>12
a text filter which will reject posts which uses a NFA regexp http://swtch.com/~rsc/regexp/regexp1.html
>>11
>Make it scale, and .. CACHE EVERYTHING!
It will be multithreaded, and file cache will be handled by OS.
>>10
It prevents necro-bumping, attention whoring/spam(repeated posts of same content), does not perturb the thread list significantly and is rewarding active original content threads with higher places in the list.
>>8-9
Scalable enterprise solutions are neither scalable, stable nor fast.

>>20
It prevents necro-bumping, attention whoring/spam(repeated posts of same content), does not perturb the thread list significantly and is rewarding active original content threads with higher places in the list.

Shitpost spams have slight modifications of their content. They are similar, recognizable but if you just match the exact same contents, it's gonna fail.

Still, I like the idea.

>>21
In that case a NFA regexp in the text filter will catch and reject such posts. Shitposts always have some recognizable element which can be blocked, or if its just noise/random words with spam, spammed urls can be blocked(i wonder why 4chan does not block those urls?) noise elements which appear in a post can be checked with entropy checks(if its entropy is close to random, post is rejected).

>if its entropy is close to random, post is rejected).
What about Perl and APL code?

>>23
pastebin the code and link to it. Autism BBS is not for code sharing(pastebin does it better), but for code discussion.

* 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.

Oh, and 2 is vulnerable to spamming, in which case you would have to provide users with multiple lists: by score, by automated rating, by user rating (since I've shown you require something like that to implement it in practice, and even then, it's still exploitable).

My previous conclusion still stands.

>>25
>* Open Source, using only free codeShiichan is already open sores.
Shiichan source is horrible quality, and it is much slower than optimized lean C.

>* 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.
The idea is that fast and scalable code would be better for everyone from hobby users to huge sites.

* 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.
Any markup can implemented as text filter in NFA regexp, but this is not a priority since pastebin exists.

* 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?
You can't imagine the performance savings, but in theory it will be far more efficient than any high level(and especially recursive, garbage collected algos) construct you write, despite its elegance and/or simplicity.


* 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.
It will have a web and telnet interface, no fancy RSS,CSS or any Web 2.0. Mailing lists are far different from real-time discussion and IRC chat is just too identity-oriented and terse medium(such as twitter).

* 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.
Shiichan is a script which is many times slower than raw C code at handling files and server requests.

* 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.
Timestamps lead to time based discrimination or in some cases accusations of one poster replying to himself, old posts disregarded as obsolete or considered authoritative/superior(dependign on the viewer perspective).
Names and tripcodes allow compromising anonymity. In Autism BBS there is absolute anonymity and privacy(no cookies, no logs, no identity). If you really need an identity to contribute,consider signing posts with pgp http://david.tribble.com/text/pgpsign.htm

* Replying to a thread reloads the same thread page,like noko.Okay.
This will be a builtin feature, rather than requiring to input some code to redirect to own thread(which is primitive, time-consuming and unelegant).

* 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,
Yes, this is correct, but there will be a cap on speed of such "raising" process so that really popular threads don't drown out all other discussion(like on reddit) and new information(thread) is valued much more than a bump to an old thread.

>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"),
No, the system is such that your post will be
1. Checked for duplicate strings from previous posts, if none found
2. make the thread swap places with one thread higher
3. if some found, thread position remains stable.

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,
This is discussed in >>22

>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).
In no cases it would be necessary to turn to reddit, a report system with at least one active moderator is sufficient to weed out the more sophisticated spam, and text filters(with NFA regexp, which should be mentioned once more as most efficient system for text processing) will catch the majority of shitposters offguard, rejecting their posts.

The conclusion thus becomes, back to /reddit/ or just use Usenet/mailing lists/IRC.
That is premature conclusion, similar to telling people they should be glad they live as good as they have now and further progress is unnecessary.

>>27
3. if some found, thread position remains stable.There are many common words. For example 'a', 'the', 'is', 'that' and so on. Most posts wouldn't bump the thread using such rules. Even if you filter them, you would imagine that a thread is discussing some particular topic and thus topic-related words would be present in most posts.

>>28
Consider a limit of 50% duplicate strings:
Post 1: A B C strings
Post 2: B C strings will not raise thread not since it is a 100% duplicate( B and C)
Post 3: D C A strings will not raise thread, since more than 50%(66%) is duplicate strings(A C)
Post 4: D R Q strings will raise the thread since duplicates are less than 50%(R and Q are new)
Post 5: Q C N strings will not raise since now Q and C are duplicate.

>>29
Consider my reply in >>25 as being applied to your filter. Half of my post was me quoting your original post. In which case such a rule would make one favor not quoting when posting, even if having context tends to be more useful.
Your rule would probably be useful for the times when someone just quotes some part of a post (to bring it to other's attention) and doesn't say much (for example to indicate how some poster was wrong or to point out something of importance).

* 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

 Threads filled with oneliners would consume entire pages. Why not set a limit of 2mb per thread and present it as a single page, 2mb is peanuts for modern browsers, though it might be bad for bandwidth.
 Also the random names could be a bit shorter, since there isn't much threads at small sites ,probably less than 62^4=14776336, 62 chars(a-z,A-Z,0-9) as 4char ID.

>>30
>Half of my post was me quoting your original post.
That is not original content, if its less than 50% original it does not change thread position.

>>1
OP, please come to #perwl at irc.rizon.net so I may discuss your software with you in semi real-time.

>>31
Why the thread should just stop? because they are limited in file space?
People would just recreate threads(like on shiichan), but its far more convenient to resume the same thread as another page as long as there is interest in replying to it. Short character ID isn't bad(easy to remember and type) but it would be more prone to collision and generation of new ID each time it matches an old thread, and finally when several million threads exist it would be a nuisance growing each day, until the ID pool is consumed. Better plan far ahead.
  "4.76724017e28 threads should be enough for everyone, otherwise add longer IDs".

>>33
Until #perwl is completely anonymous, archived in real-time and is served through a web interface, no.

>>33
How clever, so you can backtrace me, dos my home server, eventually get all sort of embarrassing personal data about things I'm not quite proud of. And then publish them here where they will stay forever... I'm not going to fall for this, Mr Mossad-related-hacker.

>>32
It would be if I didn't quote you. Original content represents the difference between the total post and known content. Something doesn't become un-original just because it is derived or includes something older.
>>36
I'm not >>1, but nothing prevents you from using a vhost and if you don't trust the irc network admins, just use a proxy.

if you want more performance why not use GETs instead of POSTs? GETs are lighter,shorter and auto-escape the text!
Only thing left is to block people with external site referers.

>>37
But there is fine line between sparsely commenting on larger post(quote:comment ratio >50%) and creating original independent posts. Derived content should be possible without quotes(and save on copy-paste, post size, bandwidth).
Quoting+replying is following a thread of existing 1:n discussion(such as a thread-tree on a forum, but on textboards it is seen as multiple quoted posts), reply with new content is a contribution which should raise the thread place and create quotable material(a subthread in a virtual discussion tree).

Hey mate, if you're really serious about this...

Here's two links for you. Both are about scaling web apps.
Both focus on Django, which is my preferred platform, and which is why I know about these links. The problems highlighted (and how they solved them) are largely not django specific (or even language specific)..

http://www.slideshare.net/mmalone/scaling-django-1393282

http://www.youtube.com/watch?v=i6Fr65PFqfk

Have a look at them, and keep them in mind when you start making it. I think you misunderstand where the problem actually lies.