Hey

I'm writing a new textboard that will revolutionize all textboards!

It is being written in the revolutionary programming language called Perl

This is what i have so far:


#!/usr/bin/perl
1;

>>39
I have a way kinda of figured out. It's weird, but i think it will work.
The worse that could happen is that someone posts in a thread just to add a vote.

>>29

to be able to vote up for the thread at the moment of posting an answer.

What are you talking about? Just make it a button for a page like /vote/:threadid/:post_num/(up|down) then you can redirect them back.
It doesn't require javascript at all.

>>41
You could look at the html for seiup.net, they have an upvote button.

>>43
Moecountsystem. Well... is still a regular form button like >>42 suggested... still... i'll try to look at the source if i find it.

>>44

i'll try to look at the source

no don't, it's phpshit spaghetti code

Last screenshot, this corresponds to the catalog.

https://imgur.com/a/CUT8c

Other, but with a slightly different stylesheet

https://imgur.com/a/y6tmV

I had been trying to use a "masonry" layout but i have not been able to get what i want without JS. I have a few ideas though. The problem with the masonry layout (also called, "Pinterest layout" in some places) is that, without JS, the units flow in columns up-down.

[ 1 ] [ 4 ]
[ ]
[ 5 ]
[ 2 ] [ ]

[ 3 ] [ 6 ]
[ ]

So is a bit weird since one expects always that the order flows from left to right. Anyway, small details overall. This week the work starts on the actual posting/replies. I hope to learn a bit more about voting. This + a tag system will make for an interesting way to find good content.

>>46
JS? Just use CSS... https://sub.god.jp/f/nogrhb.png

I went with this, but you can experiment.
.outer {
display: inline-block;
width: 250px;
height: 600px;
overflow-y: scroll;
}

>>47
Thanks Anon, i already have something like this (see the 2nd image in >>46)

This is what i mean by masonty layout:
http://smashinghub.com/25-powerful-examples-of-masonry-jquery-web-design.htm

>>46

frogboard

Man fuck all the way back.

>>49

Is just a name, progboard doesnt sound good.

And i like reptiles in general.


Whats wrong with it?

>>49
I should mention that i'm doing this because of the fond memories i have from the old /prog/ board in 4chan. Progboard... mmm didnt sound too good for me, and i like frogs.

Moar screenshots (animated this time)
https://giphy.com/gifs/DBaXDRJoudsBGo93Zj

>>52
What's up with the ad?

>>53
add my anus

>>53 Just a placeholder to test css stuff. Banners are 320x50 (standard in the "market")

https://giphy.com/gifs/5tf39GgTTBPqKD2nO5

Cute site

Will you expoas a RESTful API for poasting automation?

What value does this add?

I've been meaning to do something like this except written in Go with a react.js frontend with tons of tracking and megabytes of javascript to trigger the hipster retards here who pretend like they're posting from raspberry pis.

>>58
I can spam it more easily

>>59
sounds very cutting edge

>>57

Actually i've been thinking about this. Perl Dancer, the library i'm using, makes this VERY easy. Not to post, but to read from the boards. I will try to feed data from static json files, not from DB. But this is for version 2.0 or 3.0.

>>60
As for spam, i and thinking on a reporting system. Any link will go to an interstitial page with a screenshot taken from that page. That same page will have a report button, so you wont be getting free hits to that website. Maybe a regexp functions to detect certain patterns in URL like referals. Honestly, antispam will be, i think, the most advanced and interesting part to build. Any ideas are welcome ;)

>>59
Do it with ZK. That would be amazing! Is not for Go, but for Java, which is much better! TRUE _¡¡¡¡ENTERPRISE QUALITY^!!!!
https://www.zkoss.org/zkdemo/grid?zkn=1

Just disable links in poasts.

Have an endpoint that will generate single use tokens that are necessary to poast and make them expire in 30secs

>>64
30 sec from page load? So if you reply to a thread after reading down to the middle/bottom of the page, it fails?

>>65
Yes.

I propose the name 'frogrider'. sounds better than 'frogboard'

>>67
Seconded.

Will it support SEXpcode?

>>69
Sexpcode is a meme. BBcode is better

I was thinking about authentication features.

The idea is to use cookies the least possible, and allow real anonimity, no ip tracking or recording or (permanent) sessions. So, we will keep an internal ID, and another table, to join the ID with a special code.

The user will not have an username, but rather, a key. This will be an url of the type

https://mywebsite.cool/key/7613kjksd8237643

You can store this in your favorites.

You will also asked to use a password when you access the url.

This password, with the key, will be processed and generates the special code. This code is related to the user ID.

By using this url-key the user will be able to:
-access the posts
-edit them
-change the unique name to be shown on posting (kinda like a username)
-access the profile (in the dumb case the user wants to add some personal info)
-change the email

You can reset your url-key and password by entering your email.

You will receive a special link to do this. Then you will get the chance to pick a new password and a new url-key.


The site will use cookies, but only for:
-Prefered stylesheet
-The checkbox that indicates if you prefer to post as anon or by using your name
-Catalog preferences

There will be a way to see all the posts a identified user has posted, even if he/she has changed their name.

>>71
?

>>69
still not decided. at the beggining i want to support these at least.
* Quote
* List
* Bold
* Code
https://giphy.com/gifs/ipxHSKsPxTRFbCMgix/fullscreen

>>71
This sounds exactly like tinychan (not this board)

>>71
persistent profiles connected to e-mails aren't a good idea IMHO. identity on textboards should be ephemeral

>>75
E-mails are optional.

What's wrong with tripcodes? Then you can have an extra page listing all poasts for a given tripcode if you need that.

>>71
just use the tripcode concept where some string is hashed and the hash is the username

you can extend it by associating those hashes in the database with stylesheets, preferences, etc.

>>78
That's exactly the same thing, except everyone can see your tripcode.

>>79
the idea in >>71 was to use a token plus a password. I'm saying just use the password (as represented by its hash, the "tripcode") by itself.

whether or not to show the tripcode can be one of the user preferences.