>>3451
>I want something to not load, until another thing is clicked, without using js.
The checkbox method mentioned here works + supports older browsers and allows for lazy loading unlike details/summary.
https://sundee.neocities.org/nojs/#imageexpansion

However the css variables used for the background-image:url doesn't work in older browsers, so you need to remove those if you want to support them. The link method doesn't work in old browsers as well and the hover method is wonky in old browsers (might be fixable, but didn't bother trying).

You could perhaps use this technique for nojs post previews, but it would be impractical to do it for posts outside a thread. Personally I'd consider using it for image expansions and video embeds. Doing it for post previews would be too much of an hassle.

>>3465
The checkbox method works for whatever is supported by the css content tag, which is only images and plain text. HTML, such as iframes, can't be used with it. I explained why in this post >>3464
I could use a checkbox to emulate the details tag using display: hidden, but that css property doesn't actually affect loading, so there would be no point.
>I'd consider using it for image expansions
I already do that.
>older browsers
Don't care about supporting those. There's a reason why old image board software, like what Tohno-chan uses, has massive amounts of long-winded js. That's how things had to be done on older browsers. Older browsers also don't support new, less verbose js.

Post edited on 22nd Feb 2023, 7:53am

>>3466
Ah yeah, doesn't work with video tags either. I only tested it with images at first, so excuse me for getting ahead of myself. At least it's usable for image expansions.

I've finished implementing post querying for moderation.

Added a simple log for bans and deleted posts.

>>3450
Over the course of the few months since I've added this feature, I've had to change invidious instance around 5 times, possibly more. Either they become slow as hell, or they stop allowing cross-site embedding. Can't find a better solution though. The next best option is something called "Piped", but that requires js.

Post edited on 27th Mar 2023, 8:53am

>>3478
You could host your own instance or generate the direct video URL serverside via ytdlp.

>>3479
Invidious requires a hefty amount of ram, and I only have my laptop to work with. ytdlp is an interesting suggestion. Figuring out how to make it work with iframes might be tricky though.

I guess I could use a reverse proxy type set-up, assuming youtube's "direct url"s expire. I'm not really sure how it works and information about it isn't readily available. I'd also have to combine the audio and video stream myself since there's two separate direct urls for both.

edit3: "--get_url -f best" gives a merged url. The last thing I'm worried about is whether this matches the privacy of using an invidious instance.

Post edited on 27th Mar 2023, 9:11pm

>>3480
So the direct url, for some god forsaken reason, has the video autoplay, and I can't find a way around that. The sandbox iframe attribute, is supposed to prevent anything inside of it from autoplaying, but in firefox this doesn't work for some fucking reason, so it autoplays no matter want. Just another instance of firefox being a backwards piece of shit under the hood.

https://bugzilla.mozilla.org/show_bug.cgi?id=752551
11 YEARS

Post edited on 27th Mar 2023, 10:41pm

>>3480
>The last thing I'm worried about is whether this matches the privacy of using an invidious instance.
Most instances use the direct URLs by default, but some instances allow you to proxy the the direct URL, although it's usually not the default option.

>>3481
>The sandbox iframe attribute, is supposed to prevent anything inside of it from autoplaying
You could try generating an HTML page with a tag set to not to autoplay, that takes up 100% of the viewport and use that inside the iframe instead.

>>3482
*video tag

>>3482
I see. I did consider using the video tag. At first I thought this wasn't possible because my server's CSP policy was blocking it. After testing it on a html file though, I could see it does work. Now I have to think about preserving the aspect ratio. Thanks for the assistance.

>>3484
Okay after a bunch of iframe finagling, it works decently.

Do you have any antispam features or do you plan to add any?

>>3486
There's rate limiting on how often a person can post, to prevent flooding. I'm thinking about adding a word filter too.

Post edited on 30th Mar 2023, 10:53am

Long time no update. I've implemented various(but not all) administrative features, and finally got around to making the post form look decent.

Pinning and locking has been added.

Been a while. I've added post editing and deletion, as well as bump locking when a thread gets large enough(represented by an anchor).

TC and 4chan at least require javascript to edit/delete posts, mainly due to that being required for selecting which post to act on. I considered adding a text field for post id, but decided it would be cleaner and easier to only go off of a unique password each post would get that's stored in a cookie.

Effectively, this makes it only possible to edit/delete the last post you made, but because that's how I use those features 99% of the time anyway, I decided it's sufficient. I don't know how kusabax decides to change the password user's store, but it's often enough that you can't reliably edit anything besides what you just posted.

That takes care of every "major" feature. What's left is stuff I'm not sure I even want to add, like hidden boards, a "last 50 posts" feature, and allowing mods to move a thread from one board to another. Some input on that would be helpful.

Hidden boards and duplicate image prevention have been added. As of now, I would consider my engine feature complete. Not counting templates, it's about 2700 lines of code.

Perception hashing wasn't as useful as I hoped it would be. It's pretty good at duplicate prevention, as even the thumbnails of images with slight differences produce the same hash. It can't be used to block memes though. E.g. the hash distance between two wojak variants, is not smaller than their distance to pic rel.

Anyway, the software development phase of this project is finished. Maybe I'll add more features later, but for now it's done.

>>3514
Interesting. I've downloaded a copy of the source to use if I ever need to spin up an imageboard. 3k lines of code seems reasonable. It also sort of confirms that 80-20 thing, 1k lines was like 80% of the core features.

Welp, there's finally an instance online. Here's where you can find Sayachan
https://dpaste.org/C6umX/raw

Post edited on 21st Oct 2023, 9:27pm

>>3516
https://sayachan.pl
I have a clearnet address now too.

Lazy loading iframes has finally begun to be implemented in Firefox, though as of today that's only available in nightly.

There's other shitty things about gecko though, like this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1862212
https://bugzilla.mozilla.org/show_bug.cgi?id=241985

I'd actually pay money for something that uses Blink and has Firefox's UI.

Post edited on 31st Oct 2023, 11:53am

Fucking awesome, OP! Really cool. I've long pondered doing the same, but too busy with other things at the moment

I wonder - what is the advantage of this over, say, jschan?

>>3526
Not him but jschan is the definition of bloat: mongodb as the database? Redis for session storage? Websockets? You aren't writing a distributed microservice imageboard, there's no need for any of that. And using nodejs for generating plain html files is the icing on the cake.

All you really need is a simple key-value store (not even a full relational db) and a hypertext preprocessor.

>>3526
Taking a quick look at a live instance, jschan does not have expandable thumbnails or allow deleting posts without javascript. It does not have embedded youtube videos, or themes, or editing posts at all. You can add your own css, but this also requires javascript.

edit: ogai also uses css to limit the size a thumbnail expands based on your screen size, so you don't have to scroll or open the image in a new tab to see all of it. I've never seen another imageboard engine do this.

Post edited on 27th Dec 2023, 5:26pm

>>3526
Never heard of it, but wow, that's actually pretty neat.

Added code block and shift jis support.

I've given up on the SVG idea because the firefox code reviewer assigned to that bug still hasn't approved the fix. Worse though is that links accessed in an SVG are added to your history, so if you maximize an image and then press the back button, it'll minimize the image instead of actually going to last page you were on.

I've instead added a context menu to images using JS. I know it's weird using JS as compensation for not using it, but people who have it disabled altogether wont be affected by this, and those who do have it enabled, are now affected less than before. So it seems like a win-win.

Post edited on 5th May 2024, 6:56pm

In an attempt to stave off spam, I've added a knowledge-based captcha to thread creation.

>touhou knowledge required to post threads
Is it a not so subtle way of putting younger people off?

>>3635
Touhou is still pretty popular with younger people...

>>3635
I'm in my early 20s, so I hope not.

Post edited on 27th Oct 2024, 6:43am

>>3637
So new people really do come here, eh?

>>3639
There were a couple young people in this thread -
>>/so/24553

Post edited on 27th Oct 2024, 8:50am

>>3635
I think it's somewhat part of otaku culture. I have never played the games but I sort of know the characters, and some quick googling would easily resolve it. Anything more detailed than that might be annoying, unless the board was specifically for touhou though. That reminds me of the IQ-based captcha on science-chan (I think that was the name?) which gave you math/physics problems to solve every time to you wanted to post. Clever, but super tedious and annoying.

>>3356
It took awhile, but I've finally added a fts feature. It's not really usable for CJK languages unfortunately.

>>3322
I'd like to make my own image board software as a learning experience too. Do you have any tips or things you wish you'd known earlier?

>>3643
You could skim through this thread and the relevant posts here >>/navi/2643
A lot of the architectural decisions and major things I learned were discussed on tc. Embrace enums, hashsets and maps. Also, when testing, pretend you're someone who is intentionally trying to break things.

Besides that, just pick a language and get going. The main language features you'll be using are http handling, html generation and db controlling.

Post edited on 16th Nov 2024, 10:47am

>>3644
What did you use for your database? I was thinking of using mongodb since it's pretty elastic

>>3645
Relational databases are more than capable of handling an imageboard's needs. Use NoSQL though if that's what interests you. As for what I used, not to be mean, but if you can't do enough looking around to figure that out, you wont be able to develop anything.

Post edited on 16th Nov 2024, 12:28pm

>>3645
>I was thinking of using mongodb since it's pretty elastic
It's certainly very webscale
https://www.youtube.com/watch?v=b2F-DItXtZs

>>3646
>but if can't do enough looking around to figure that out
On the contrary I already made my decision. I just wanted to know your opinion on the matter. I had the opportunity to work with both and nosql is simply more convenient to me. More so for something without a clear final design in mind that might change over time. I could add more fields to a document as the project grows and I implement more features

>>3645
SQL just works. "nosql" databases come and go but SQL stays.

>>3647
I once was helping someone who was running a lynxchan imgboard and, without fail, mongodb kept breaking and breaking and breaking and breaking...

Didn't there used to be a thought (or a joke) about flat files being the best for boards (because all the original japanese scripts used them)?

>>3650
>mongodb
To be fair mongolicdb is terrible even for nosql standards.
>flat files
I remember some guy that used to run an imageboard that used a gigantic CSV file as database. It didn't matter because the board was slow enough to not crash the whole thing.

>>3649
>but SQL stays.
Postgres supports jsonb if you really want to store a loose bag of data inside a column.

>>3651
Schemebbs uses plain files too
>There's no database, messages are stored as Scheme objects in plain files.

Early on, I considered using Redis for certain things, but decided there was nothing I needed which couldn't be handled by an in-memory map, and would justify the additional dependency.

>>3653
A database is just a fancy hash table if you squint your eyes enough.