/aw/ - AwsumChan Meta

Question part 2-

….. SO, it seems that any chan out there is attempting to include as many files as possible. For what? To set up future bot nets? To gather all kinds of data and spy on anons? I am not a criminal, but I can assure you that the gov has an interesting in identifying all "anonymous" type ppl and a good easy as fuck way to do that is make a honeypot chan site that opens up users to major security flaws.
So tiny ib, in 1.5 mb of files, can do what vichan can. So why the fuck do we bother with vichan? How about if good coders looked at tiny ib, and kept it very small in files yet but just made sure it is fast and can run well on php7.3.3 (which it does, by the way, it is the only chan that did not need to be modified in order to run on php 7.3.3)
SO—- my idea would be to make a fork of tinyib- to make sure it takes full advantage of the speed and security of the latest php versions. Maybe get rid of the .htaccess files in it. The idea would be to keep it small as fuck, to keep bloat out, and to absolutely NOT make it rely on any dependencies.

Another idea to keep it super simple is to make it even SMALLER!!!! That's right. Get rid of the db options, make it run in flatfile by default. A flatfile chan that can deploy on any php host, with NO crazy dependencies. Basically, it IS that already! BUT, make it flatfile only, there will be NO MORE SQL INJECTION concerns without having it rely on MySQL. Fuck that. MAYBE– just maybe, keeping it in flatfile would make it the ONLY secure chan. Less ways to do attacks in flatfile mode. Also, note that flatfile has gotten fast as hell with php 7.3.3, cdn's like cloudflare, and the proven method of using apache in the background, and having a reverse proxy nginx server serve the static files.

Question part 3

The fucking thing is already made. All one would have to do is take out all the MySQL code and make it flatfile only. THEN, make sure the php code takes advantage of php 7.3.3 and then slightly change the css to be more modern and look better. The end result? A chan board capable of running on any php server, a chan that has very few files, a chan that does not rely on database so no more sql injection concerns. Instead of fucking around with something like vichan that has thousands of files, the new chan would be about 1mb of a few files.
What do you think? It could be a revolutionary new imageboard that proves how stupidly not secure the rest of them are. It would be more reliable than any of the others.
I was thinking of offering someone 1K to code it and maintain it for a while. Can you pls tell me what you think of the whole idea?

>>78
There's really no concern for SQL injections in Tinyboard, as long as you use prepared statements.
As for backdoors, there hasn't been any in Tinyboard since savetheinternet removed an update checking feature that was incredibly insecure - I never plan to add something like that again.

>>79
TinyIB has it's own merits but it requires you to set up an instance for each board. Flatfile database is nice for very small imageboards but really slow down when you start getting steady content flow, which is why virtually every imageboard supports a RDBMS of some sort.

Tinyboard has a relatively small codebase if you don't count third-party dependencies such as Twig. The reason why we use these is unlike TinyIB, Tinyboard uses a templating engine to render the HTML files that you see. The code for these templates appears far cleaner than using PHP itself and is easier to work with.

As for appearance and styling, it's definitely something I want to improve over time. I'll be looking into making the appearance friendlier to mobile devices.

As for slimming down, that's something I'm still working on.

>>81
Check out 2 examples of my tinyib mods. https://4usa.org/1 and https://4usa.org/2

flatfile mode examples, a 10 mb animated gif renders instantly. It would be even faster in db mode.

both take gif, jpg, png - if one wanted animated thumbs just install imagemagick. both can do youtube embedding. it can even do webm which I didn't set up yet.

its like 1.5m each instance. easily modifiable. works on php 7.3.3 ( current example is running that)


I know that tinyboard forks look a million times better- but im conflicted in if I should just start a bunch of chans with the tinyib mod.

php7.3.3 , its behind a reverse proxy that serves the static files and apache runs in the background (the fastest way to run php) and its behind cloudflare cdn. I can upload a 10m aninimated gif to it in the blink of an eye.


I just keep wondering if that's all one needs for an imageboard. I guess you really don't think its a good idea to fork tinyib?

>>82
The big reason TinyIB is so small is because it lacks third-party PHP libraries and features like themes, advanced moderation with multiple staff.

What you need in an imageboard is all dependent on what you feel are the needs of your site and its demands.

4chan (formally?) runs a heavily modified version of futaba.php that had a completely garbage looking codebase, but it worked well for the traffic it carried. Forking TinyIB isn't a bad idea if you want to go that route, but I personally have no intentions to do that.

Also, I prefer using NGINX instead of Apache - it's faster when using it with PHP-FPM. Using APC caching and a few other features really helps with performance.

>>83
Yeah, I see your points. I've always been fascinated by tinyib and in the back of my mind always wanted to try to make the css look better and actually run a board with it. Even using it as a textboard is awesome, one can have just the comments section and a send button. That makes for a flatfile textboard, instant deployment to any site. Maybe I will just keep it for a flatfile text board and include it in chans in the textboard pages. I want to start some chans, but can not figure out if to use vichan, openib, lynx, npf, tinyboard, or meguca. Check this shit out…they were working on it yesterday!! https://github.com/bakape/meguca there is something wrong tho, they tried to update the code and every pic is not showing now at https://meguca.org/

Mainstream vichan is about done, obviously- thank god for forks tho.
march 30, lynx is coming out with 2.2 beta. If you read the full page and every thread of the npf link I sent, npf dev seems very serious. meguca.org is serious in dev too.
Its cool that you seem to like getting rid of the nonsense and bloat. Just as an idea for you, to clearly state that awsumchan will never do shit like try to mine bitcoin, awsumchan will keep the bloat out, focus on security, and have a good community of people who will help people with questions, then you can still stand out.

Looking at other ppl's patreon, ppl do all sorts of things on there. It is a blank slate where you have the potential to create anything. Maybe start by an article on there asking others if they have questions?

You want to build a community that goes to ur patreon acct. For your regular sites, mostly kinda just say that if ppl have questions then they should go to your patreon acct and ask. `

And the fucked up truth is that you should also either get into node.js or golang In all honesty just php is not enough nowadays.

>>83

Apache is faster when it comes to cpu intensive ops tho. Nginx can serve static files faster, but apache and modern php can actually be faster at cpu intensive operations, and there are benchmarks posted on the internet to prove that. The best way that people know of so far is to use both. Use nginx as a reverse proxy to handle the static files and non-blocking io of visitors, and then use apache for the cpu intensive ops in the background.

>>85
Actually I have a lot of work done in Node, Python, Ruby, and Go as well. I've been working on a different style of imageboard in Python for a while now that uses tags instead of boards. If you've ever used a booru, it works similar. Originally I tried to do it in Go but the abilities of templating engines in Go were very limited. I don't consider the use of languages other than PHP to be a bad thing.

>>88
I'm not sure I get what you mean by "intensive operations" on the webserver, unless you're talking about regular expression rewrites or the like. I personally don't see a point in trying to do anything particularly intensive on the webserver either.

As for the comment on meguca, lynxchan, and other imageboard engines - I'm not aiming to compete with them. I don't feel that imageboards are necessarily a competitive field of software.

>>89
That's cool that you do node.js and all that too!


By cpu intensive they say like video processing, rendering images and so forth. Most reputable articles on nginx vs apache say that nginx is the king of static files but slower when the site needs to do dynamic stuff like process images online and so forth, like idk maybe a meme maker where it has to generate pics after someone creates a meme? So the articles all claim that the best known method is to have nginx as a reverse proxy and apache do the dynamic, or more cpu intensive stuff in the background.

However, nginx IS cool lol. So would you say ppl should dump apache entirely and only run awsumchan on nginx?

>>90
I think you mean Tinyboard here. (AwsumChan is my website, not a software). As for apache, I'm not dissing it, I'm just stating it's not really something I'd call performance focused for running Tinyboard.

Also please stop making a new thread for every comment man, it's becoming borderline spam on here and I'm very tempted to purge some of it. We have an IRC if you want chat on there.

>>93
Oah, sry I thought one should make one topic per thread. Purge all of it if ya want, no prob at all. Ive just been thinking a lot about making some chan sites so I had a zillion questions lol. Brainstorming out loud. Some sites like lots of activity, I kinda forgot that smaller sites can find that annoying.

>>92
ahh.. I thought awsumchan was the name of the tinyboard fork.

>>96
No. It is still known as Tinyboard. I developed some of the parts of Tinyboard that are still used today, particularly some of the stylesheets and porting the templates to Twig.

I will never assign the AwsumChan name to anything but this website.

>>97
Oops, I thought this was the main dev board lol. Pls feel free to purge everything if ya want. Interesting case study tho, like if there was a board that only had 1 page and 10 or so threads, all the old shit would be purged automatically. It actually gave me an idea to include a board like that on my future chan sites.

>>90
>By cpu intensive they say like video processing, rendering images and so forth.
Doesn't this happen by the client or did you mean uploading

>>107

Apache and NGINX don't do any image or video processing. However, Tinyboard does create thumbnailed images using GD or ImageMagick, and also FFMPEG for WebM thumbnails.

I don't feel performance is a problem that Tinyboard really has right now, unless someone can show me some statistics.

Greetings, anon. I found this thread - and this chan - from a ddg search about imageboards. I share the same views as you I was even building a small imageboard in Go because of that.
But I have mixed feelings about imageboards and I'll express those below:
- Do we need yet another imageboard software? I mean do we have enough people looking to new imageboard software?
- How much is too much? Is 50mb of deps too much? Do we need a new stack? For example I plan to do my software run on containers as you'll only need a simple script to update it as Go binaries are 7mb/15mb.
- Do we need new features? User accounts so you can keep track of replies and watch threads or even a new "UI/UX"?
- Do we follow bigger software standards as response layout (vichan's .json endpoint)?

>>131
You bring up several good questions here. Also, I'd love to check out your Go imageboard software. Can't lie that I've been doing a similar project, hah.

>Do we need yet another imageboard software? I mean do we have enough people looking to new imageboard software?
This is a tough question. I'd say the first part is largely philosophical. There are a lot of options, and there is a lot of variety among them. But imageboards are a fun software to work with and there's always something new that one can attempt to apply to the imageboard dynamic. For the second part, I really don't think the audience is there anymore. I feel imageboards and *chans in general are becoming a niche thing.

>How much is too much? Is 50mb of deps too much? Do we need a new stack? For example I plan to do my software run on containers as you'll only need a simple script to update it as Go binaries are 7mb/15mb.
I think it's all based on what the developer is trying to achieve. Are they looking to emulate a full suite of imageboards like 4chan? Maybe they just want one imageboard? Maybe they want it to be real-time with multi-file video and audio uploads?
Dependencies and programming language stacks I feel are really up to the choice of the developer as well. You don't NEED dependencies in most cases, but they can provide you with tooling and features that would otherwise take a lot of time to create yourself, as well as maintain.

>Do we need new features? User accounts so you can keep track of replies and watch threads or even a new "UI/UX"?
This is a matter of what audience you're trying to cater to. If you make a 4chan clone, you can expect a majority of your audience are the same people who would use 4chan. User accounts are a highly controversial topic in imageboard software, see https://wakaba.c3.cx/shii/ for more on that. A new UI/UX for imageboards is always something I've been interested in, since imageboards generally use a layout that dates to the late 1990s.

>Do we follow bigger software standards as response layout (vichan's .json endpoint)?
Creating a standard for imageboards is always something I've been interested in. I do feel that imageboard JSON APIs should try to follow a general standard in the sake of compatibility. I also feel implementing some sort of reliable and secure REST API would be useful for those looking to automate discussions or create native applications.

>>79
Better yet, move it to the Gopher protocol or the new spin-off "Gemini".

>>132
To be honest I thought your reply would take a lot longer as I didn't expect this to be a populated imageboard.
About my code, it is pretty much experimental as I'm discussing with some people what would we be aiming at the end of the project. Some of my thoughts is that it must be "portable" for a lot of reasons:
- you must be able to provide basic maintenance on the code (this is one of the reasons I'm using Go);
- you must be able to port it to another place without much configuration;
- you must be able to provide a front-end as you wish based on the resftful api (there will always be a fallback to noscript users, of course);
Most of the work is still on paper as we are thinking about the tools we'll be using to build it. For example, do we sacrifice the first point of portability with a RMDB such as postgres or do we stick with "embbeded" technology that we have in Go (ex. Badger, bbolt)? With some tests we see that it can handle a considerably number of people on your imageboard.

>>132
>>134


> I feel imageboards and *chans in general are becoming a niche thing.
Unfortunately this is true. Meanwhule you can see that there are a lot of communities rising. I mean, look at this: http://textboard.org/prog. It's basically a textboard with LISP enthusiastics. I feel that even though imageboards are dying, specific communities are being born in a fast-paced manner.
But as you said, it's becoming a niche thing.

>I think it's all based on what the developer is trying to achieve.
You're 100% right here I have no comments to make.

>User accounts are a highly controversial topic in imageboard software, see https://wakaba.c3.cx/shii/ for more on that.
This is an awesome reading, thank you for sharing this. As accounts I would not identify them to other users. It would have the same aspect as the "(You)". It's debatable or I could make it optional, I don't know to be fair. I would not require an e-mail I guess as it would be a hell of verified tripfags. hah

>I do feel that imageboard JSON APIs should try to follow a general standard in the sake of compatibility.
Hey, this is something we can figure out. I don't think it would take a lot of efforts to build a standard even if we do it just for our toy projects.

https://github.com/bakape/meguca
I found this when doing research about the project. The docker-compose build command failed here and I don't feel like messing with this code as I don't know how Rust works.

I'll try to sketch a schema for the restful apis and post it here.

>>78
Thanks to this post i deployed some TinyIB instances and found out it isn't 1.5mb…
but 600KB!! (after some simple optimizations and deleting unnecesary folders)
so yeah it is light as all fucks and i think with some more optimization (the developer like line breaks and spaces a little too much)
you could get it to 580KB without too much trouble, maybe even less, later im going to try and make an instance as small as possible.

>>256
I just read the part about removing the db code which i agree on and will later make a fork to do so, removing that code could easily make it 550KB or even less, god i want to make an instance 500KB so bad

Anon, I didn't forget about our conversation, but the pandemic just made me start my life from the bottom again. Sorry about that.

>>264
Pandemic