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.

>>38
The idea is neat, GETs are faster, but there will be hard limit on post size for some browsers like IE(only~2kb).
Since the data is completely anonymous text this could be done(also it seems more elegant), but why block external sites? They could post to BBS anytime with blocked/forged referers. Since i don't care about standards much this will be implemented as URL processor routine(in form of readThreadID?writePostText) with simple text form for input at end of every thread.

>but why block external sites?
Enjoy filtering CSRF attacks all day and removing spam from sites which load your BBS links in background.

>>42
I am not filtering content senders, only content itself(with...NFA regexps). Bans and site blocks are just walls which can be jumped over. Its an inadequate solution in the age where dynamic IPs and botnets are rampant enough to overwhelm any ban system.

(div id=hidden) (img src="hxxp://yourboard.com/board?Trollolol spam trallala") x 100 (/div)

CSRF is easier to prevent for POST :)

>>44
But you left a GET.

>>44
Its not significantly harder, just add an AJAX spammer embedded in your webpage.
In severe cases its always possible to add captchas or some sort of one line IQ test to high rate posters(just like what google does for people who query too much data)

>>46
If the spammers want they will work around that too.
 http://it.slashdot.org/story/08/08/30/1219235/Inside-Indias-CAPTCHA-Solving-Economy

>>47
Thats why i put more importance in content filtering >>43 .CAPTCHAs are just a minor annoyance to spammers(i recall some porn sites harvesting user captchas for porn) and they slow down the posting process, sapping server performance(especially for locally generated captchas).
Besides, why bother with captchas if there are moderators who read the board at least several hours per day.

>>46

I prefer this way of preventing CSRF:
"Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions"

Please note that AJAX have a same origin policy, so you can't do that from a different site. You can of course construct a form in a hidden div and then submit that, but it's harder.

Regarding filtering on referral, some people (and some business "internet security systems" proxies (yuck)) does not send referrals at all, so you either have to abandon those users, or treat "no referral" as valid. None of them are good options.

>>49
I think the imageboards block js+no referer.
I wouldn't consider filtering by referer that good of an idea, most of the time I find it annoying myself (when I turn off the option in my browser for privacy reasons).

>>49
If you use RefControl try "Forge - send the root of the site", 4chan and most sites work with this.

>>49
There is always good old Iframe:
<iframe id='iFrame' src='targetsite' style='display:none' onload='FrameReLoad(Fillforms with random data,submit)' ></iframe>

>>1

BTW:
 "Very spartan text-only design, no CSS/JS or any external files"

Stupid idea. Reasons:

*CSS:
 You will almost certainly have *some* styling. If you do that in CSS file you can have user download it *once*, and keep it in cache. Inline styling will have to be sent on every request.

 * Thus, saves bandwidth.

*JS
 You can use JS for creating and formatting parts of the page on the client's side, and thus both send less data over wire (send some as json encoded data, then parse and create the data on client side). You can also do things like partial page refreshes, respond to user stuff without a server roundtrip, add things like edit toolbars for more or less free, and so on.

 * Saves bandwidth, saves server cpu and memory, enables bling

So, well-done CSS and JS will be of great help to both you and users. Of course, shite made JS will make users hate you (*cough*facebook*cough*), but well-made JS will be more or less unnoticable.

Example : BBcode toolbar, created automatic for all .editfield elements : http://pastebin.com/fpxqTx33
If you did that in HTML you'd have to resend it for every field (not to mention have code to create it for every field before sending) - with that it's one download, and cached.

>>40
Scaling
for 20 odd users? autism.

>>53
not adding Ajax or any such web2.0 features, it will be in pure C/HTML:
1.It requires JS on the client to be enabled
2.it lowers client performance(CSS styles,JS/AJAX). HTML does not need any "styles"
3.the bandwidth savings are limited and temporary. after 1000 posts the page becomes static and the average user reads rather than writes. (If the site was made of heavily dynamic content such as chat, this wouldn't apply).
4. complexity of underlying representation: it requires to store posts separate from their representation(database vs flatfile) and their retrieval is more complex than a simple page load.
5. Complexity of user interface:a text field and submit button vs toolbars/format scripts and inline editors.

>>55
1. Which is in some cases a beauty in itself. For example the bbcode bar I linked to earlier.. If user don't have JS enabled, it simply won't pop up at all. It won't even exist.

2. Which is great for the one user that still use a 486, but does not use dialup. Modern hardware and browsers are damn fast, and as long as you don't do stupid shit, users won't even notice the JS running.

3. It's bigger than you think. If you have 10.000 readers and 600 writers, and the writers post on average every 10 minutes, you have on average a new page every 1 second. Can't use client cache effectively for whole page, then.

4. True.

5. Partially true, it will make the actual interface harder to use, since you have to remember this and that instead of just having a button for it.

>>55
You do realize that almost all sites which were made after '96 have at least some styling (usually CSS, or at least inline, but inline isn't proper). CSS isn't for making anything 'fancy', it's for layout and presentation. If you're not using it, you're just refusing to give your page any layout or presentation at all. Even minimalistic BBSes such as this use have plenty of CSS to them. The alternative (what people did before CSS) is to make huge nasty tables and spam 1x1px blank images so as to make a semblance of a layout (unfortunately fixed).

Of course, I have no problem with text-only protocols, but you do have specialized clients for those and clients can display/present the context as they wish, but when you're not having a specialized client which can be customized by the user as they wish and instead are making a normal "web application", you should at least use some CSS to present your content, otherwise it looks crappy and hard to read (try turning off styling for shiichan). For some simple documents, HTML without styling can look okay (as it was what it was meant for originally), but I'd be impressed if you manage to make it look decent for an interactive BBS.

s/context/content//

>>56
1. many people disable JS for security.
2. Autism BBS is faster.
3. I think we can safely assume maximum concurrent user count below 100.
using if-range(thread is a flat file) and gzip(serverside) in headers for bandwidth savings is better option.
4.
5. There is no need for any markup. Just plain text(thread is enclosed in tt tags for better code view)

>>59
Does that mean that a reader will have to resize their browser window in order to have half-readable whose lines don't span kilometers?

LOL Slashdot-variety autism.

>>60
Users which use browsers without word wrapping might be affected when long posts are posted, but they could install a userstyle if needed.

>>59
1. Think you misunderstood. If they have JS disabled, then they can't use fancy JS stuff anyway, so it not even showing up is a win in that case.
2. Ideally, you'd have 100ms or less response time, but network lag will probably fuck that up for you anyway. Under 500ms is a realistic goal. For example, transatlantic that's 150ms round trip, which will effectively cost you 300ms already. If your site renders in 5ms or 50ms is of little notice.
3. Heh. Really? You could code it in BASIC and host it on a C64 then, for all it matters.

>>62
>ou could code it in BASIC and host it on a C64 then, for all it matters.
In fact the BBS should be capable to be ported to small low-performance chips with internet connection without any dependence on platform.

>>63
Because everyone needs to run their own dedicated BBS on random very cheap hardware? (I'm not saying it's a bad thing, just I'd figure there would be better things to waste one's time on than writing web applications (+ a tiny httpd) in C).

so it not even showing up is a win in that case.
I hope you don't mean denying the web page rendering the main content if javascript isn't enabled.

>>65
index.html:
[code]
<script type="text/javascript">
<!--
        <?php
                $file = fopen("__index.html__", "r");
                while (!(feof($file)))
                        printf("document.write(\"%s\");\n", fgets($file));
                fclose($file);
        ?>
-->
</script>
[code]
__index__.html would contain the actual code for the page, which would only be written if Javascript was enabled.

>>66
*

<script type="text/javascript">
<!--
        <?php
                $file = fopen("__index.html__", "r");
                while (!(feof($file)))
                        printf("document.write(\"%s\");\n", fgets($file));
                fclose($file);
        ?>
-->
</script>

>>65
Aho!

That functions requiring javascript does not show if javascript is not enabled is win. That you have a problem understanding even simple things is not.

Let's take the example I was pointing to about bbcode bar.. Bah, why bother? You probably can't even read this many words in just one day :(

>>68
Posts on the text boards are never deleted, so he'd have all time in the world to read them. Thought I should tell you, since you emit the odor of an image board paladin.

>>69
I was just realizing the futility of re-explaining an example I've already explained.

As Einstein once said : "Insanity: doing the same thing over and over again and expecting different results."

>>70
Like throwing a die?

>>71
Hey, don't start mixing Japanese guitarists into this! Focus!

>>71
At quantum level it's not the same dice after a throw.

>>35

it is anonymous (use a proxy), it is archived (I log it), and you can access it through a website like mibbit.com

you must not use IRC very much, if at all.

Update:
* User-based moderation, each new thread will be given a password field, so that thread starter can moderate posts in his thread by clicking (Hide) and viewers can bypass that by clicking (Post hidden by OP|Show hidden post){which will be part of page, with style=display:none}
* Reply form is a floating div which is transparent and follows the lower part of screen
* Reply form will contain a ribbon of JS-buttons editor(for people wanting WYSWIG, rest will just type [b]sometext with tags being one-letter for ease of use) like this
* Structure:
Frontpage|Thread Lists|Intrathread pages [0][1][3]
_______________________________________
Thread text                                                    |
1:: >>2                                                         |
2:: >>1                                                         |
________________                                        |
|(buttons)(submit) |                                        |
|(text)  Floating div|                                        |

>>75
Reply form is a floating div which is transparent and follows the lower part of screen
This is the most annoying ``feature" ever. I hate people who do this.

>>75
What is "thread lists"?

>>75
Suddenly you went from no CSS/no Javascript to CSS+Javascript?
I would say that it should provide a graceful mode (no-JS) where everything is visible, and when JS is enabled, the user can have some defaults (such as a cookie) if they want to allow moderation or not, as well as allowing them to change stuff by themselves.
This way the board is still usable for those which don't want to use JS, and enhanced for those that do:
I can still use /prog/ and /jp/ without greasemonkey scripts for filtering bad posts/hiding threads/retrieving stuff from archive/image thumb search and so on, but  with them on, the experience can be more pleasant.

>>77
Default Order(unique posts move old threads +1 place up, new threads at top)
Note: threads posts do not contain any visible timestamps(anonymizing time), but they are preserved(server-side timestamps in order.dat will contain the date:hour:minute of thread creation, but sorting thread by their creation time rather than their last update time will not be provided)
 
time:
Last updated all time (incl. necroposts)
Last updated this decade(thread created in this decade)
Last updated this year(thread created in this year)
Last updated this month
Last updated this week
Last updated today
Last updated this hour
Last updated threads from time range(x-y)

viewers:(number of unique views/IPs, IPs are not stored just increments counter(if not same IP))
Most popular all time (threads with max viewers from board creation)
Most popular this hour (unique IP per thread, starting this hour for all threads(even oldest))
Most popular today (unique IP per thread)
Most popular this week
Most popular this month
Most popular this year
Most popular this decade
Most popular in time range(x-y)

thread content analysis:(entropy of all text in thread)
Most unique content this hour(entropy check)
Most unique content today(entropy check)
Most unique content this week(entropy check)
Most unique content this month(entropy check)
Most unique content this year(entropy check)
Most unique content this decade(entropy check)
Most unique content in time range(x-y)
Most unique content all time

average post in thread:(content is gzipped_length)
Most content per post in thread this hour
Most content per post this hour
Most content per post today
Most content per post this week
Most content per post this month
Most content per post this year
Most content per post this decade
Most content per post in time range(x-y)
Most content per post all time

thread length:(* thread are infinite max length, stored as 100 posts chunks in files)
Longest threads this hour
Longest threads today
Longest threads this week
Longest threads this month
Longest threads this year
Longest threads this decade
Longest threads in time range(x-y)
Longest threads all time

>>78
>Suddenly you went from no CSS/no Javascript to CSS+Javascript?
It was so tempting to add features. Simplicity doesn't seem good enough today where almost everyone runs javascript engines and graphical browsers.
>I would say that it should provide a graceful mode (no-JS) where everything is visible, and when JS is enabled, the user can have some defaults (such as a cookie) if they want to allow moderation or not, as well as allowing them to change stuff by themselves.
It should be least annoying for people with disabled javascript(see slashdot without js). The problem modern design is tons of JavaScript and much less server side processing. The idea of moving expensive processing stuff to the client is bad(fortunately in BBS this isn't required) for low-power or slow devices(phones, appliances,etc) and just feels like a slowdown in client experience.