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.

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

* there will maximum privacy. There will be no cookies or per-user tracking.
If you want to preserve password for thread moderation, turn autocomplete on or use an addon doe saving form data.
If you want a custom style/wordfilter personal, write your own userscript.
I cringe when i see a casually designed site with dozens of libs and frameworks and huge CSS includes running on top of slow PHP scripts(granted for simple IO bound tasks there isn't much to do, but C is way faster in general). Processing of all that to display a text-only site is not only an overkill, its a insult to user experience and server quality.

The post visibility(hidden by OP/mod) will be controlled by a permission file named perm.dat file fetched for an entire thread(threadID/perm.dat),
it will be stored separate from thread content, and not included in the threadlist file.
Its a huge bitfield,0/1 for every post. so e.g. 100k posts is 12500 bytes
1.the person has JS disabled -> he sees all the post no need to unhide anything manually
2.the person has JS enabled ->perm.dat is fetched and ONLY posts which are marked visible are unhidden
3.the person has JS enabled and he sets to ignore OP moderation by blocking perm.dat-> all posts are unhidden


orbis terrarum delenda est

*Actually each page of the thread( configured as 100,1000 or 10K posts) will have its own perm.dat for better caching since larger permission file needs to re-downloaded on changes, increasing bandwidth use.



orbis terrarum delenda est

>2011
>flat files
>no web server
>no js
>no css

10/10, will read again

>>84
I imagine the hosting, its a DSL "server" on his room which is shutdown each night.

>>85
It doesn't have to be like that.

Are you still around OP?

>>1
no bbcode
FUCK _O^FF

>>1'
>* Performance/bandwidth oriented
>* Very spartan text-only design, no CSS/JS or any external files
Typical autist. Doesn't realize that a cached CSS file will increase performance and reduce bandwidth consumption by orders of magnitude.

>>88
Fuck off.

>>40
django
get out of /prog/