New Chan

Greetings. I'm a janny on another minor imageboard and I'm thinking of writing a new imageboard. I want to make this a serious alternative to lynxchan and the vichan derivatives (incl. lainchan) due to being dissatisfied with their architecture, maintainability and dated UX/UI. I've been soliciting feedback from my fellow jannies and they told me to come here to ask you folks what you think, and I think I would like to include feedback from the greater alt-chan community as well. What does /λ/ think of: Architecture: Monolith vs Microservices Front end: SPA (ex: Angular, React) vs Server Side HTML templating Backend Language: Java, C#, Lisp, Rust, Golang, PHP, etc. Database: SQL vs NoSQL My personal preference would be for something like Spring Boot+JPA although its boring, there are a huge number of people who know java anyway. Plus there are prebuilt solutions for common problems in many java libs. Any suggestions?

definitely go for a monolithic architecture. For imageboard software the ideal is that you just have one config file and run a single executable to start up the server. server side HTML templating best, and if u use rust on the backend there are pretty fast templating engines. for the database: unless you've got a huge user base there's no reason not to just use sqlite.

>>26674 Achitecture: Do you think IBs get enough high-intensity traffic to justify the overhead in programming, configuration and setting up? I would hazard a guess that the things that do get a lot of traffic in an IB can't be comfortably divided into microservices without also implementing a distributed architecture, which would instantly add a lot more complexity to your project for perhaps no real gain. Frontend: SPA is a bad idea, no one sane runs JS on imageboards. Absolutely templating. Backend Language: Pretty much all options you named other than PHP are fine, go with a compromise between language safety and performance (memory and compute-wise). It goes without saying that something crossplatform is essential (are there even any current C# things for other than Windows?). Backend: Continuing to provice an API for alternative clients to be able to display the contents would be nice. Database: Forums and imageboards are pretty much perfect matches for the whole relational model. And I don't know of any lightweight NoSQL that isn't completely insufficient (complex/heavy NoSQL unnecessarily complicates deployment), while sqlite is quite nice and sufficient for most purposes. While Java is indeed a bland choice, it does work and it's safe. Do beware of performance drawbacks regarding it though. You could also get to mess around with ABCL or Kawa, although that works against the "a huge number of people who know java anyway" point you raised.

>>26674 I don't know what any of these mean... I would recommend Rust, Go, or JS as backends because they are built to be web languages. Lisp would be great for the memes but unless you can find a use for homoiconic webpages I'd skip on that. Also what the fuarrrk is a JPA?

>>26677 >Also what the fuarrrk is a JPA? "Java Persistence API" - Java Object-Relational Mapper (interface to database) that translates database entries into classes/objects. You query it using JPQL which is a sort of pseudo-sql language

>>26676 >are there even any current C# things for other than Windows? dotnet core (aka dotnet 5 and above) is cross platform FLOSS afaik but still not common for linux users due to the MS reputation

>>26677 > I would recommend Rust, Go, or JS as backends because they are built to be web languages. I would actually recommend against JS, its ecosystem is a cesspit. I can't talk about Rust or Go as I don't have sufficient experience with them. > Lisp would be great for the memes but unless you can find a use for homoiconic webpages I'd skip on that. I have a hard time parsing this as anything other than a nonsensical joke from a non-programmer. Homoiconicity doesn't even apply as a coherent notion to the setting you're applying it to. Lesser contributor mass is a problem, but even the library ecosystem hasn't remained static and has some promising options these days, as exemplified here: https://github.com/CodyReichert/awesome-cl#html-generators-and-templates > Also what the fuarrrk is a JPA? It's basically the standardized Java ORM framework specification Oracle built into J2EE. https://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html It feels fairly similar to EntityFramework.

>>26679 The libraries and frameworks are more what my concerns were when asking that. The core replaced mono but I don't know if anything else followed.

>>26680 > nonsensical joke from a non-programmer I am a programmer. I'm just unfamiliar with web stuff and have a faint notion of common lisp from the two-or-three lines I wrote 3 years ago.

>>26682 Right, well, homoiconicity doesn't really map onto that kind of output of a language. It's pretty sourcecode centric for reasons a number of free textbooks will explain better than me. The availability of up-to-date sources for getting started on actually producing deployable executables and projects in CL has improved in the past few years. Prior it was pretty much puzzling it out from ASDF's manual, which newbies aren't particularly likely to do if they've even heard of it.

>>26683 honestly this was and continues to be my biggest challenge with learning common lisp. It's so difficult to simply make and distribute a binary in the sense that I can with C or Go. Closest I got was a 'binary' that resembles a Java jar file. I am not very smart

>>26674 Haskell is your best choice. It is fun to write, it is fun to test, it is fun to refactor. There are also lots of fast template engines you can use, which are all extremely Haskell'y. As a database I would choose psql, especially because there is a sexy library[1] which converts disgusting SQL to, you guess it, Haskell! Also there is already an engine[2] written, which you can peruse for fun and profit. [1]: https://rel8.readthedocs.io/en/latest/ [2]: https://github.com/ahushh/monaba

Part of the appeal of imageboards is the oldweb ux/ui. Also do not use js. I'd say go would be the best choice from the ones youve listed. I've not done anything substantial with it but every blog post I read from people using go for web programs all say they are highly satisfied with it.

OP here im doing a survey if you guys don't mind answering it. https://www.strawpoll.me/45482737 its on which language to use I appreciate your feedback thanks

>>26687 Haskell is a lot harder to write though. OCaml would be an easier choice to any unfamiliar contributor.

>>26686 We should probably move this to the actual Lisp thread as we are offtopic. >>>/λ/21193 The jar-like output you obtained has to do with how Lisp systems work in general, which is via an image-based paradigm. Saving your current running environment as an image you can then just load at a later time and get right back to working on. Every implementation has their own implementation-specific way of dumping images and executables. File: /tmp/hello.lisp lisp (defun hello (&optional args) (format *standard-output* "~a~%" "Hello World") (finish-output) (quit)) This is something you could, from within the SBCL repl, (load "/tmp/hello.lisp") then call (save-lisp-and-die "/tmp/hello" :toplevel #'hello :executable t :purify t :compression 9) . You'd get a hello-world binary that bundles the SBCL compiler & interpreter and resumes with the #'hello function. If you were to omit the :toplevel argument, you'd instead end-up with a portable and executable image of your work environment when you saved it, which you could resume a REPL within. But this isn't how you should do it for a number of reasons including some nice bookkeeping that ASDF does for you and the fact it's implementation specific. What you'd normally do is define an ASDF project which lists (you could write the list by hand, like most do for smaller projects) or somehow obtains a listing of the project files, the relevant namespaces and exports being the first defined things. It would also contain a definition for your program :entry-point, such as "hello-world:hello". Assuming some asdf system :hello-world (package namespaces and asdf systems are two different things, you can name them the same if you feel like it) exists then: lisp (require 'asdf) (asdf:load-system :hello-world) (asdf:operate :program-op :hello-world) would portably generate an executable program regardless of which Lisp implementation you're using, so long as ASDF supports it. ASDF has an object-oriented design to allow for "easily" defining new operations or redefining existing ones. CFFI implements a :static-program-op which as it sounds creates a statically-linked program (https://common-lisp.net/project/cffi/manual/html_node/Static-Linking.html). On a project-basis, you could also decide you want to compress your generated image, which you'd do this way: https://old.reddit.com/r/lisp/comments/5jbsle/how_to_build_an_executable_with_sbcl/dbf9sop/

>>26697 Once you get the basics down it is as easy to write Haskell as any other functional language, possibly even easier. So I wouldn't really shy from it. What I will agree however that it might be hard to read other people's code in it, however as it is yours there should not be any problems.

>>26674 use next dont listen to "le old school web" hipsters. preloading etc makes for 10x better ux

>>26689 why only one choice? Realisticially use whichever language you are most comfortable with. I recommend java, go, or rust because they're fast and (relatively) sturdy with good web tooling

>>26674 >Architecture: Monolith vs Microservices I think that compartmentalization is a very useful tool to make programming projects more accessible from outside help and easier to read/understand and maintain. >Architecture: Monolith vs Microservices Front end: SPA (ex: Angular, React) vs Server Side HTML templating ECMAscript is a large privacy and security risk, not to mention it wastes a lot of bandwidth because people don't use it well. You can do a lot with CSS and HTML, CSS is, after all, turing complete. >Backend Language: Java, C#, Lisp, Rust, Golang, PHP, etc. For maximum performance, C would be a great option, although the benefits would be very minimal for what you're planning to create I believe. Rust's memory safety doesn't really suit a project like this in my opinion, so I don't see a point in using it; it has ugly syntax as well in my opinion. Personally, I would write it in either C or Lisp (Scheme, specifically). >Database: SQL vs NoSQL I'm not too familiar with databases, but SQL is pretty old and there are numerous alternatives that people recommend over it; I'm not sure on this one. I wish you luck on your project.

I'm already working on a C# clone. It's like 60% done but I abandoned it. If you wanna collab let me know.

Micro services add a lot of complications that don’t make sense unless the partitions in the system match your organization structure. I’m guessing this is a solo effort, so I just wouldn’t go there. Replacing what could be a method call with a network call is rarely justified. Image boards just don’t have a complex enough UI to justify the weight of an SPA. Good for Google Sheets, bad for what’s basically a document. Also, think of people with soykafty hardware and slow connections. Spring is a great framework that others can understand if you need help. It’s not popular on HN, but 1) HN posters are a laughing stock 2) you should be interested in a working software product, not blogging about your hipster stack. Remember, you’re not putting together a slide deck for VC buxx, so fuarrrking with Clojure or Rust will just make your life harder. Or make blockchainchan in Rust, bro, then post your v0.1 release (just a Readme.md and helloworld) to HN and make the front page.

Actually, here’s something different if you want to try a fresh direction: Store comments as a graph. Each post is a node and replies are the leaves. The UI allows you to traverse posts by sibling, parent, or children. Use a Neo4J backend. This would be different from every other chan, where you are obligated to navigate content in sequence of time it was posted. You could also do fancy things like find highly connected nodes to select the most interesting posts. You can get fancy and make each post ID a hash of its own content and the content it is in response to, sort of like a Merkle tree. This would also mean that anyone else could extend their own branch of the network by using that same methodology. As long as that basic interface was followed, then a client could be agnostic to the server, or use several.

>>26732 Not OP but this idea seems really interesting. NoSQL makes sense for a project like this, at least a document model. At the same time SQL is totally fine and will work very well for this use case also. I don't think the choice is super relevant for this, since you're not executing a large number of JOINs just to make the post. Use sqlite or if you like the document model mongo or something. Though the Neo4j idea if you like it is also very interesting. I recommend doing server side templating, there's no real reason for any JS frameworks for this. I like Go but when writing a huge webapp it would probably just be more annoying than anything. It is more fun for APIs/microservices, and I agree with the other posters that think this makes more sense as a monolithic application. I also liked this comfy video about this topic, but unfortunately it was never followed up on. It could be fun to use Flask or Rails for this. https://www.youtube.com/watch?v=bMUQkhi1V84

>>26732 Those ideas are technically interesting; socially, they strike me as dubious. >traverse posts by sibling, parent, or children >different from every other chan, where you are obligated to navigate content in sequence of time A conversation is not hierarchical, but sequential; such a system would encourage modes of exchange that are not conversation. It could encourage a model based on high-value self-standing posts, linked by topic and with little in the way of direct personal replies. It could also foster a conformity arms race, where contributors compete to write the most popular posts by imitating previous popular posts. >find highly connected nodes to select the most interesting posts Yup, that's a ticket for the Upvote Express, destination Reddit. I'm not trying to single you out and lynch you - the truth is that what kind of community any given place of discussion will foster depends on too many factors, many of which are impossible to influence in a predictable way. The quality of the 'seed' community is probably the most important, and indeed a dedicated community can flourish even on flawed grounds. There was recently a similar discussion over in the 'programming buddies' thread, see >>26445. The point I wish to make is that, when setting up a place of discussion, technical choices have social effects and should therefore be considered from a social perspective, too. Although you can't reliably predict the effects of your choices, you can expect that, in the long term, your community will be shaped by the incentives that your infrastructure hands out. That's mechanism design, use it.

>>26749 Plz no lynchy >>the quality of the “sneed” community FTFY You’re just afraid of my badass graphchan/blockchan. Well, just you wait, Lain. Imma write it in Rust and get a billion GH stars on v0.01. Imma write it in Golang too.

>>26724 >I think that compartmentalization is a very useful tool to make programming projects more accessible from outside help and easier to read/understand and maintain. I find that's a double-edged knife. Too many separated services instead makes the maintenance and administration more complicated. >I'm not too familiar with databases, but SQL is pretty old and there are numerous alternatives that people recommend over it; I'm not sure on this one. Age is not a technical demerit, especially when the design also matches the problem domain perfectly.

what about gRPC? is it a good idea?

>>26760 Not particularly. It's hardly the worst RPC library around, but I think it's fair to assume most of us already assumed any use of microservices wouldn't be relying on a homebrew message-passing layer but on a pre-established one like gRPC, xml-rpc, etc. The issues with microservices have more to do with architectural complexity in general, which you can only reduce by so much when it's inherent to the design's tradeoffs.

I'm also working on an i2p based imageboard as a hobby project. The core idea is having users create their own account id / signature without any formal signup process. Then the user would perform proof-of-work to authenticate the account - with enough PoW you would be allowed to post on the board. This way if a user is derezzed, they can't just create another account, but have to perform all of the PoW again. At the same time, if a user is well behaved, they will have the time to create multiple accounts. By posting under multiple accounts they improve their anonymity. I am building a smart client to automate the account management, PoW and the connection to the i2p network. For the tech stack I've gone with Kotlin + Desktop Compose for the smart client, Kotlin + Ratpack + gRPC for the server monolith. It's still in the early days, so far have i2p set up with bandwidth estimating auto-configuration and some basic UI. I'm hoping to have enough structure down to open source it within the next two weeks.

>>26732 Gun is a good framework for something like this.

>>26778 is it the sqlite of js?

This seems like the right place to ask, I've also made another thread >>>/q/10369 Do you hate raids and dead threads on lainchan? Do you have experience with coding forums or imageboards? Easy thread restoration would probably require fundamental changes how the imageboard works - by making threads persist after they're supposed to be bumped off. Appleman has said he's having difficulties implementing this, so some assistance would likely be necessary. The github page would be great for this, if it wasn't a fuarrrkton of commits entirely behind what's running now. So updating and documenting any new source changes would be necessary as well. https://github.com/lainchan/lainchan I don't understand soykaf or know any of the people running this place, so all I can do is bring attention to them and to potential new contributors on here.

>>26809 >Easy thread restoration would probably require fundamental changes how the imageboard works - by making threads persist after they're supposed to be bumped off. Appleman has said he's having difficulties implementing this, so some assistance would likely be necessary. Just do what leftypol do and have 36 pages. ¯\_(ツ)_/¯

>>26834 I think just having an arbitrary number of possible threads but hiding them past say... 10th page would work just fine.

>>26674 I made my own imageboard last summer. Here’s what I did Backend: Monolith, written in Go, net/http package for the server Front end: HTML templates with html/template. Some CSS and basic JS too of course. Database: flat CSV files lol. I didn’t feel like learning SQL at the time, but I plan on upgrading to SQLite as it seems to be perfectly sufficient. So yeah, basically what everyone else said: monolith, HTML templating, SQL unless you’d like to do something experimental. Use whatever language you want, with usual considerations for existing libraries and language popularity. Go’s standard library stuff is great but there’s also a bunch of nice third party stuff as well. >>26749 You’ve done a nice job articulated why I still prefer classic linear threads over trees (with points) like on reddit and twitter. They’re also just harder to navigate and comprehend sometimes. Though linear threads do have a tendency to go in any direction and on 4chan for example are guaranteed to derail hard. The transient nature of imageboard threads makes this less problematic, but in forums 1000 page threads are really daunting.

>>26795 yes but it's decentralized

>>26809 I see far too many threads that are duplicate question threads of other older threads. If i knew any php I'd add a little bit of code that checks if a thread is similar to another thread in topic or content, and then point the lain who wanted to post the new thread to the old one, recommending them to bump it instead of creating another one.

Working on my own one as well right now, got a couple of basic architecture questions. Would you consider it a good idea to use a templating engine to generate a static site that is then locally saved for every thread until a new reply is added instead of generating a new site on every web request even though it didn't change since the last request? Would this improve efficiency significantly? Where are the main security risks with imageboards? I don't know soykaf about that stuff, but as long as database input is carefully sanitized (which shouldn't be that much of a hassle) and file upload is done without any major fuarrrkups, I should be good, right? Where else can I make serious mistakes that will grant the bad guys control over my IB?

>>26862 >Would you consider it a good idea to use a templating engine to generate a static site that is then locally saved for every thread until a new reply is added instead of generating a new site on every web request even though it didn't change since the last request? Would this improve efficiency significantly? I like this idea from a simplicity standpoint. Imagine you have a program that only accepts POST requests, and modifies the files of a static site hosted on IPFS or Dat. Then people can easily make live mirrors by seeding the site data, and the site could be highly mobile. The *only* issue I could imagine would be that changing the gateway would mean making a whole new file. I'm not sure if either IPFS or Dat has the capability to update a file without re-uploading the entire thing, if they do then this would only be a slight problem (user sends a POST containing their gateway URL and then they can use http://(gateway)/(site)/(gateway)/ to have all the content links use their gateway) In terms of efficiency, you would probably get better performance in terms of round-trip times by storing a copy of recently requested threads in a RAM cache that invalidates entries only when they're either old or changed.

>>26865 You could split the web UI and the back end. For example, if you’re a Python guy or gal, you might have a thin FastAPI wrapper over a Postgres DB that just slings reads/writes and maybe has some middleware to limit malicious activity or filter content. Then you have a Flask front end that requests content from the API and renders the HTML. Anyone else could host their own client of course, or copy content into their own server. Since you wouldn’t want to support users, updoots and other cancer, a very simple interface is possible. That is, one that regular people could write clients for in free time. Example JSON schema: {id: string <hash of content> Parent: string <id> Time: date time Content { Image: string or null <base64 encoded> Comment: string } } I would have nothing else. Clients can apply markup, but I’d favor having none. Posts shouldn’t have to *know* what board they’re on or how they will be rendered or anything other than what content they hold and what they are in response to. A simple client might request all posts made in the last five days and could construct threads by finding posts without a parent and then appending children as they are found. Another might calculate the hash of content (say lain.jpg) and request that post and then recursively get posts where parent is that post until no more arrive. A sophisticated client might dynamically construct boards by classifying post content. Clients that serve curated and moderated content could be implemented without affecting the basic API.

>>26862 Your main security threat is really moderating illegal content, that's definitely the bigger threat aside from DDoS, probably. That's all assuming you are already getting rid of XSS, CSRF, and SQL injection attacks. If you have an admin panel, you're going to want a secure login field. Once you have that set up, try to get some kind of MFA scheme set up, to make sure you always know when a login happens. After that, it's really just protecting from spam.

>>26674 Pick a language that is both popular and easy enough for other people to contribute to your project. I would pick Java, Elixir or Ruby (rails) Out of these I would pick Java because of the JVM and interop with Clojure. Make the IB (and posting) work without JS. Don't use NoSQL if you don't know what you are doing.

>>26915 I'd pick Elixir over Ruby on Rails, it generally is like kicking dead whales down the beach less.

Don't even template. Just append new posts to existing HTML files and serve them statically. Simple as.

Despite on and off programming for most of my life (36 years old) I can't program for soykaf and have never made anything of any consequence.

>>26924 Let this be the first.

>>26924 damn i really empathize with you there. compsci can really feel amorphous

It may be worthwhile to build a federatable board by basing it on fchan code. It's also written in go, which is a pretty solid server lang. https://github.com/FChannel0/FChannel-Server

.>>26917 I hope this post was a joke.

>>26917 Ok, so as an exercise in minimalism, I've started implementing a text board that's a single bash script that does this.

>>26976 For it to result in something valid in html5 parsers you'll either be doing something roughly equivalent to templating or need to implement some form of backtracking. I also think it's a terrible idea but it still might be funny.

>>26982 I'm using sed for most of it, so e.g. new posts can be added by inserting before the closing </body> tag. "Templating" comes down to bash variable interpolation. The biggest pain is decoding the URL encoded input from the web server. Not sure I'll support UTF-8 because of this.

>>26916 Elixir and Phoenix are lovely if you prefer functional programming. If you prefer OOP, it's hard to beat Ruby on Rails.

>reinventing the wheel for the umpteenth time

>>27131 Why not? It's not as if there's any harm in doing so, whether for practice or to correct perceived flaws. > being dissatisfied with their architecture, maintainability and dated UX/UI.

>Architecture Monolithic definitely >Front end Server Side HTML templating. I had good experiences using JSP, considering that an imageboard doesn't have an extremely complicated UI, i think it would be cool. Plus, you'll be helping the wired ecosystem, since more users with old machines that can't withstand the monstrosity that is JS these days, will be able to access your webpage from these machines. people using w3m and lynx will be happy too. >Backend Language: Java 8 EE. Very easy to use for something like this. Stable and an industry standard. I never used Spring Boot but i guess it may help with coding if you already have some experience with it. Just remember that there may be certain optimizations that you'll have to manually implement in your code; considering a server-side rendering, you want to save as much time as possible wiht certain calculations. With what kind of Specs are you working (Hardware of the server)? >Database SQL, you don't need to reinvent the wheel here. Remember to Store passwords as SHA-256 hashes and when processing logins, compare the Password the user wrote on the form, transforming it first with the same algorithm, with the one stored on the database for that username.

>Architecture Monolithic, mostly out of preference. >Front end I don't care either way, but Lainchan will most definitely say the latter. >Backend Language Clojure's my top pick. You get the flexibility of Lisp with the ecosystem of and compatibility with Java. You can also use it in place of Javascript via ClojureScript. >Database SQL

>>27178 > Clojure's my top pick. You get the flexibility of Lisp with the ecosystem of and compatibility with Java. You also get this with ABCL

Honestly? Just go with PHP and MySQL. It behaves just the same as all the others, takes a fraction of the time and money to develop and if it doesn't work out, you lose nothing. The most important aspect of a website is the CSS. Implement any framework you like and do some web design before touching any line of code. This will give you an idea of what to do including the database schema.

>>27193 First, we already have plenty of imageboard packages written in PHP. If the CSS really is the most important aspect of a website, you might as well just cut out the middle man and write a new stylesheet for Vichan. Second, PHP does not behave the same as all the others, nor does it take a fraction of the time or money(?) to develop; it only looks like it does. PHP is a key example of "haste makes waste". It puts all of its stock into having a program up and running as fast as possible, and is terrible at pretty much everything else. The price you pay for greater productivity early on is years if not decades worth of debugging and maintenance. Don't get me wrong: PHP has its place; it's great for rushing out simple scripts for simple tasks that you write in a night or too and never touch again. But as soon as you're making a proper webapp, it's time to switch to a more robust language.

>>27194 Too many generalities against PHP. You need to have specific examples to back these up. >Don't get me wrong: PHP has its place; it's great for rushing out simple scripts for simple tasks that you write in a night or too and never touch again. But as soon as you're making a proper webapp, it's time to switch to a more robust language. There are too many websites, major and smaller, written since the late 90s to this day that are functioning just fine for me to dismiss PHP as some "simple scripting" language to "never touch again." The SPA domain is the only place I'd agree with you, I'd much rather write an API in something leaner like Go than PHP if possible. No I'm not the other guy, his comment about CSS being the important aspect is bizarre. Unless what he really means is a front-end first approach to design and development for a larger project.

>>27201 PHP's problems are a result of a lot of little things adding up, so it's hard to explain exactly why it's flawed with specific examples. If you want the broad strokes though, it's like someone mixed Bash with C++. It's inconsistent, full of footguns, oddly low-level in a lot of places, and loves doing soykaf behind your back. To be clear, PHP isn't unusably bad. It has its qualities, and I'm fine working on things that use it. But there's better alternatives for large scale applications, and we already have enough imageboard software written in it that there's not much point in having another one.

>>27202 >we already have enough imageboard software written in it that there's not much point in having another one. This pretty much defines it all, instead of making yet another php based imageboard, it's better if op uses a better stack

>>26917 I think I'm going to do this just for fun because it's such a terrible idea. SoykafIB.

>>27178 clojurescript is a pain in the a** to set up, compared to vanilla js

If it's not built on lisp, how divinely inspired can it really be? Try to meat them at last half way.

Architecture: Lisp Frontend Spa: Reframe? Maybe. Backend: Common Lisp Database: NoSQL. Joins are just a soykafty way to model a graph database.

>>27228 >This pretty much defines it all, instead of making yet another php based imageboard, it's better if op uses a better stack disagree, the emotion is very important

>>27334 > Database: NoSQL. Joins are just a soykafty way to model a graph database. Which one? Most seem to be proprietary and pretty heavy-weight.

>>27331 What's painful about it? I've seen it advertised as much simpler to set up than standard Javascript build systems.

>>27337 I'm still not sure exactly which is the best, there are kind of a lot of options. SQL is pretty soykaf because it's hard to use, is rigid, and it's actually slower than everything else, the table model is cool in some cases but not really worth it. Neo4j is the most popular graph database and it is pretty good, I think that's what you should try ot use. You have mongodb simple document storage and that also works pretty good for a lot of scenarios. Some people like firebase but that's some datamining. You also have RDF databases, usually triple-store like AllegroGraph. They are simple they work like Subject-Predicate-Value, so you could have John Age 11, datomic is like this except it has two other fields to record the transaction and whether it was added or subtracted, like git, so you can get the full history of your data. If I have to use SQL, I usually try to do this so it's a lot less to think about, but then you can't use types, but it's not that big of a problem for a lot of soykaf, and I suppose you could make a table for each value type in sql. Finally you can store some data in files and so long as it has a path you can fetch it, this is sort of like a document store database, and you can embed links to other resources and files if you want to.

You could use php but lisp is based.

Lookup ActivityPub, I think very important concept for social networking, every social network has something like this, and the idea is important for how fediverse works. it basically looks like the actor model which I believe is what true, smalltalk style oop is and is becoming more popular with stuff like akka and elixir because I think erlang runtime works like this too. With activity streams which this is an evolution of, you have objection-verb-object-target. The different between than this and a triple store is that the verb will be something like 'add' and the target will be the collection such as 'todos'.

>>27350 >objection-verb-object-target. subject-verb-object-target*

>>27341 >SQL is pretty soykaf because it's hard to use wtf, SQL is pretty close to basic english

>>27358 so many things about it are soykaf - strict schema requirements - a table per class of object - extra tables on top of this, new tables and schemas for every relation, for which you will want at minimum three new columns - better hope migrations are automated for you anytime you change anything - joins are slow and it's basically a bad way to model an edge in a graph database - sql is slow as soykaf, especially when it has to join tables and create views and so forth. constantly makes you optimize it. >For the simple friends of friends query, Neo4j is 60% faster than MySQL. For friends of friends of friends, Neo is 180 times faster. - if your language is not based on lisp, you might as well throw it away because it's never going to be able to do all it could or should be able to do, especially when you come up with some retarded soykaf like sql. julia is an example of a language that is not lisp, but is actually still pretty good because it's built on top of lisp. you can use sparql if you like how sql looks, you have languages that look like sql but the ultimate query language I think will probably look something like lisp and datalog

>>27359 if you're trying to use SQL as though it were object-oriented of course it's gonna be soykaf. SQL is highly optimized for table-based storage. If that doesn't match your requirements then use something else. If it does, I sincerely doubt you will manage to find anything faster or easier to use.

>>27358 >>27359 >>27360 fuarrrk that I'm using regular files as a database. All imageboards should follow the many times honored tradition of breaking as soon as they get too big.

>>27358 >close to english making it as easy to use as cobol we only had to invent formal languages because of how monumentally unsuitable natural languages are

>>27359 >- strict schema requirements >- a table per class of object That's called "data consistency" and "structural homogeneity" >joins are slow and it's basically a bad way to model an edge in a graph database it's going to be a database for a Chan, so the data on each table is going to be defined by the domain model of a Chan. You don't need a fuarking friends of friends of friends JOIN when the domain is something as simple as a Chan. Since the fuarking domain is already specified before creating and defining the table's structure, you don't need to improvise on the go by using 27 joins, because a Chan is a use case that's been already implemented a thousand times. It looks like you never used MySQL for a real use case. > if your language is not based on lisp, you might as well throw it away because it's never going to be able to do all it could or should be able to do 1) the fuarking lisp curse. 2) OP doesn't need to code anything extraordinary, so i don't see what the fuark can lisp provide to this use case. You're basically putting a language on a pedestal. OP doesn't need some cutting edge Chan that runs on 80kb of ram. He can use something of a higher level like python or java.

>>27378 >OP doesn't need to code anything extraordinary, so i don't see what the fuark can lisp provide to this use case. You're basically putting a language on a pedestal. OP doesn't need some cutting edge Chan that runs on 80kb of ram. He can use something of a higher level like python or java. You might be confused; Lisp is a high level language, and a rather expressive one at that. Do you know about what you're talking about?

>Java Already off to a bad start As far as UI/UX I've always wanted to see @channel become a reality

OP should just use Scala or Clojure or use java interop. >>27400 >>Java >Already off to a bad start You are probably hating on java because it's fashionable to do so.

>>27400 >As far as UI/UX I've always wanted to see @channel become a reality That's how things used to be before everything became imageboards. @channel was based on 2channel, which was a textboard before imageboards became the next thing that took off. 4chan used to have text boards too. Textboards still exist. Go visit some of them! https://4-ch.net/4ch.html https://dis.heyuri.net/lounge/ https://disco.kolyma.org/apiru/ https://dis.4ct.org/ https://dis.tinychan.net/ I'm quite fond of Channel4. Yes they're slow, but it's a relatively chill community, and a very old one at that. But for the love of god if you're new to textboards, PLEASE LURK. They all have different communities and netiquettes. Sage the soykaf threads, sage if you're going off-topic, sage sage sage.

>>27405 >clojure already been done https://github.com/8b2eef7c901269e8e9a6ec532d57b6b1/supremereality no one contributed because clojure is too obscure

>>27409 Clojure also has yet to fix its licensing compatibility issues for writing Free Software and distributing.

I am currently doing exactly that, but it's nothing I want to put out there as a viable alternative, just an exercise for myself in webdev. However, one of my main issue is database concepting and building. I'm using SQLite, and for now, I still haven't come up with a good way of having different post ids for each board. As 'Boards' is a table in my database, and 'Posts' is another, every post counts up, regardless of which board it is posted on. It is very early though, I guess I'll find a way. For now the stack is extremely simple, Flask for back end, and Jinja2 as the template engine. It works really great for a simple project like this, and someone actually put out a FlaskChan before I even started considering doing one. I haven't tried it out though. Best of luck op!

My only suggestion is to make it AGPLv3+. Vichan has some weird [redacted] license.

>>27548 Just a passing thought, you can use two columns as a pair of primary keys. So each message is unique in that they have a unique Board ID and Message ID pair.

>>27550 >Vichan has some weird [redacted] license. Czaks was probably on drugs or insane when writing it

There are two ways to do it. One the vichan way where you have a template file and generate posts table per board. https://github.com/vichan-devel/vichan/blob/master/templates/posts.sql Or you can do it with triggers: create table boards ( uri text not null unique, title text not null unique, description text default '', last_post_id integer default 0, PRIMARY KEY(uri) ); create table posts ( board text not null, id int default null, thread int default null, content text not null, primary key(board, post), foregin key (board) references boards(uri) on update cascade on delete cascade, foregin key (board, thread) references posts(board, id) on update cascade on delete casscade ); create trigger increment_post_number after insert on posts begin update posts set id=(select last_post_id + 1 from boards where uri=new.board) where rowid=new.rowid; update boards set last_post_id=last_post_i + 1 where uri=new.board; end;

>>27548 forgot to mention >>27556

>>27405 No, I'm hating on java because it's soykaf, especially for the web. Java applets were dropped 5+ years ago. It's not a modern solution. Use the right tool for the job. I agree with moving away from PHP + MySQL but Java is moving backwards. >>27407 I know what a text board is lol. too lazy to scrot but the interface is pretty cool in the show.

>>27553 >>27556 Thank you guys, much appreciated. I'll try to implement one of your solutions.

>>27562 This is the @channel interface I'm referring to

>>27583 wow that reminds me of .hack// very cool.

>>27562 >No, I'm hating on java because it's soykaf, especially for the web. Java applets were dropped 5+ years ago. It's not a modern solution. Use the right tool for the job. I agree with moving away from PHP + MySQL but Java is moving backwards. honestly this is just ignorant anon, no one is advocating using java on the frontend. Java is still a major backend and general purpose language along with C#, PHP, python, golang, etc. In fact the only "outdated" languages are things like cobol, basic, vb6, visual foxpro, and other soykaf from the dark ages of the 1950s->1980s. I mean fuarrrking NETFLIX uses java with spring stack AFAIK. Java is a perfectly acceptable language.

>>27722 you're right anon and i realized this after posting. i officially retract my statements against java.

>>26699 I'm not the one you are replying to, but thank you a lot.

OP HERE! I did it. I made the chan. https://github.com/Barbara-Pitt/cabalchan LMK what you guys think

>>27800 oooh very very fat controllers, lots of if-elses, will immediately suffer in terms of extensibility found this https://priyalwalpita.medium.com/software-architecture-patterns-layered-architecture-a3b89b71a057 the pattern might be usable - presentation layer would be some logic (service in java/spring?) in charge of templates and how they are used by your controllers - interaction layer would be some logic about user actions - persistence layer would be, in this case, a wrapper around filesystem and database logic you have in your repositories/entities - database layer you have as entities/repos so out of this pattern i'd suggest thinning out your controllers in favor of these layers reasonable? no? -- visually it looks like a news feed which is the new age type of approach to anon ibs influenced by fbchans, i'd try and make it look like a combination of phpbb+blogroll kind of thing in order for altchan installations to attract effortposter types -- am i wrong?

>>27800 >open site >thread asking for discord invites What the fuarrrk is this?

>>27800 similar though as >>27804 you make it look like a twitter/microblogging website with is not necessary bad, except for the general outlook

>>27806 that people trolling. >>27804 thanks anon, I will eventually refactor it into smaller controllers as well.

>>27804 OP here with an update, I refactored the controllers into smaller controllers and also added some functionality.

>>28083 Could you fix https://cabalchan.org/latest ?

>>28255 it should be fixed now. the problem was caused by some unescaped inputs allowing anons to input redirects. However they have been escaped now.

What about meguka? It's in the process of bring rewritten in Rust rn (from go), the old version looked pretty good.

>>26976 This script had better be sandboxed somehow or you are going to get rekt.

>>26976 This sounds like an RCE and XSS nightmare, but I think I'm for it.

too tall/long, too much negative space, font style is too hard to read, and with this narrow width it doesn't make sense to allow high character limits this is good as a resume/portfolio thing to show to interviewers or whatever but in practice i wouldn't use this thing. you just can't half-ass the frontend, it's the most important thing on a social site

>>28428 >you just can't half-ass the frontend, it's the most important thing on a social site the front end isn't "half assed" its just in a style you don't like (mobile first). The UI isn't that qualitatively different from facebook/twitter etc.

>>28538 "mobile first" doesn't mean you should neglect how it looks on a laptop. twitter and mastodon look much better than this, they're actually readable. i can't even use the scroll wheel on your site without placing the cursor in the center. worst of all you decided to disable the scroll bar. is your goal to keep laptop/desktop users away from your site?

>>28570 >>28575 Anyways let me know if you have any questions about imageboard design/implementation.

What is the ideal solution to reply indexing? Should the parent thread store a n array with its children's' id? Or should the child store the id of its parent thread? The former requires dynamic allocation of an array and constant modification whenever a thread is replied to while the latter requires the entire database to be searched for replies with the correct parent id. What is the best approach?

>>28713 >Or should the child store the id of its parent thread? This option. Any performance losses from database hits are offset by this option being perfectly concurrency-safe. And any programmer writing a forum server in 2021 without concurrency as a fundamental part of the architecture either doesn't know what they're doing, or they're suffering under a language that doesn't allow for proper concurrency.

i wanted to make a thread about it but i might as well join this one - i think hotwired/htmx/liveview/remix might be a new paradigm shift in how webware is programmed i've add myselft a todo of building a(/n) text(/image)board with it in order to experiment. i'll make a single board and its whole topic would be this software design

>>28717 >hotwired/htmx/liveview/remix This is just javascript with extra steps. With the added insanity of using html as a wire protocol. >webware eyetwitch

>>28763 >and this new hackernews-target-market framework-flavour-of-the-week abandoned-next-year fuarrrkness. >fuarrrk it all. I'll keep doing server-side html rendering with just enough javascript to replace divs with the rendered html fragments. Problem solved. at this point i'm convinced you're either trolling or aren't aware of what the "flavour-of-the-week" thing actually is lol it's supposed to do EXACTLY what you are talking about, server-side html render with just enough js to replace divs with fragments

>>28763 HTML isn't a "wire protocol", almost all the HTML is compressed over the wire and sent over the HTTP protocol.

So thank you all for the advice. Now I'm stuck on a new problem : how do you turn post quotes into anchors towards the post? When a user quotes a post, it comes in without the anchor tag. When do you transform it into an <a> ? I've tried Javascript, using a regex and a replace but I didn't succeed so far. I'm wondering if I should do it in php in my controller?

>>28977 I'm baffled that you'd even consider javascript for that. Leaving aside the fact that you believe running a website gives you the right to run software on other people's computers, and the fact that you wish to hand out useless pieces of plaintext to anyone who can't or won't run javascript - both of which are prerequisites for your having chosen that approach - leaving that aside, I say, what happened to reliability? If you're building a website, surely you know about the hell that is ensuring compatibility with different browsers. Why would you defer a central feature of your site to code that will have to run on a myriad different environments and never be able to send back an error message when it fails? >I'm wondering if I should do it in php in my controller? And I'm wondering that you wonder.

>>28977 I don't think it matters much where you generate the anchors. Doing it server side allows people to browse your site without javascript, assuming you're not using js for other stuff. Doing it client side takes a bit of work off your server, but it's an irrelevant amount so who cares. Just do it where it's easier to implement it

>>28977 Some more thoughts: you have the choice of transforming posts at reception time or at retrieval time. Now, now, of course, the obvious right way is to do it at reception time, because then you only have to do it once, but I think the other option has some benefits. If you store your posts after transformation, then the HTML in them is static. You can't change your site's URL layout in the future, for example, because past links would break, and if you'd like to add a new feature to your links (like an alt text, or a class to apply styles to them) you're out of luck too. Having thought of this, what I'd do is to transform posts not into their final HTML form, but into an intermediate markup language - one that supports just the few features needed (post links, quotes, spoilers) and is faster to process than a full-text regex search (otherwise, I might as well process the raw post at retrieval time). At the expense of a costlier post retrieval, I'm buying the ability to retroactively change my HTML.

>>29010 Western *chans look like they're stuck in the 2000s because they mostly run either vanilla Vichan, or a relatively conservative fork. Vichan inherited its interface from Tinyboard, which was a clone of 4chan's Yotsuba, which itself is a proprietary fork of Futaba.

>>29010 Could you suggest some russian imageboards that are worth looking at?

>>29040 JavaScript features: 1. posting box markup buttons like on every forum since 2004 • Click [Создать тред] and play around https://web.archive.org/web/20121021205357/http://2ch.hk/b • Better presentation of what each button does https://web.archive.org/web/20171121112438/https://chaos.cyberpunk.us/b • Another example https://spirech.org/d/ • Perhaps, modern JavaScript already allows WYSIWYM text editor inside a browser, so users could see styled text inside markup as they type 2. endless on-hover reply chains • https://web.archive.org/web/20160912223933/https://2ch.hk/b/res/136041396.html • Reddit-style trees as seen on Lainchan look pathetic after this space-age technology 3. Floating resizeable movable image/video display, left-right buttons navigate User Experience features not necessarily bound to JavaScript 4. Clear Navigation as I already mentioned: • Board title = [Return], it's that simple, put catalog button nearby • [Create new thread] = open post box for creating thread • [Reply in thread] = open post box for replying in thread 5. Post replies numbers in bottom part of post <div> • see 2ch.hk above • https://web.archive.org/web/20170625222019/http://lolifox.org/rus • Notice the absence of reply chain in vichan JavaScript 6. 102chan.i2p managed to embed reply on-hovers in page html (looks gnarly on unstyled page) • i2p address: http://102chan-memorial.i2p/ • http://t6uwxydnfd7mo2knxklmnrudxafe4mw5ojiqikj7xfrc4ynltz3q.b32.i2p/ • clearnet proxy: https://102chan-memorial.onion.pet/b/ 7. OP-moderated threads aka "diaries" for those who don't need a whole board to reign on • https://web.archive.org/web/20160802144654/https://2ch.hk/dr/ • https://web.archive.org/web/20200113202110/https://tumba.ch/op/ 8. Side panel board list. Don't you dare waste my vertical space. Don't make it an iframe. 9. Arisuchan used to have a [formatting options] link near post box, to ease life for JS-off users embed them into page and hide with css where markup buttons usually are • https://web.archive.org/web/20190721213515/https://arisuchan.jp/formatting.php Center-aligned layout that doesn't look abhorrent on both mobile screens and wide windows 10. discou.rs (too tryhard, tries to mimic VK comments) • https://web.archive.org/web/20180822182012/https://discou.rs/po/ • notice same endless on-hover replies chain 11. uberchan.ru • https://web.archive.org/web/20201110011136/https://uberchan.ru/b/ 12. 2ch.hk archive • https://m2ch.hk/ Something else to consider 13. Non-retarded text wrap when post has more than 1 file attached. I think it's hampered by current browser technology, too small sentences become one word per line, slightly long paragraph leaves a huge empty space on the right. Align text box to center and attach all 4-6 files to the left in a row on wide-to-full screen windows (1920px wide and it's multipliers). 14. Justified and hyphenated paragraphs of text (this basic feature from 90's word processors will still be unsupported on web for another 20 years I assume) 15. Minimize vertical space: truncate empty lines, turn single sentences into bullet points, shdowban redditors, align reply links into one line, turn them into buttons and hide pointy arrow characters, same for quote arrows, make post boxes as compact as possible

>>28977 Avoid simply doing a find and replace because you can end up with garbage links that shouldn't have been linkified and break nested quotes.

>>29061 which is exactly why chans wont be popular with the under 25 crowd, because you discriminate against phonefriends on purpose

>>29074 The two problems with phone posters is that they 1) don't read the thread and 2) don't effort post (it's hard to write longer replies with a cell phone)

>>29375 Board link system is powered using Ajax. I'm not sure what your issue is.

>>29377 A lot of people hate javascript, especially when it complicates things from their point of view. He would have preferred a full browser refresh, with the <a> element for idomatic javascriptless website design I don't think there's anything wrong with your design decisions, it's your site. People harp about semantic html but html is bullshit and so is the whole web so who cares

>>26956 >>28580 >>28650 I like the that the FChannel project is trying to build a system that's resilient against censorship. I believe that's why they have federation. The server side of the project looks fine and seems to work as intended. However, I'm underwhelmed by the user experience. I wish there were an alternative UI to the FChannel ecosystem. I'd like to treat the FChannel boards like an API that a rich and comfy client UI could talk to.

>>29495 FChannel had its first birthday on January 14th. https://fchan.xyz/prog/AF085BFA#FFDKBPYY

hey lains, ive been working on some image board/bulletin board kinda site during the last week, implementing some ideas i really thought were cool. if i were to actually host it in a a week or two, where would i go about ""advertising"" it a bit. itd be really cool to somehow gather like 20 posters or so. posting in this thread cause it seemed to be the most fitting one. sorry op lain, hope im not annoying u

>>26675 >server side HTML templating best, and if u use rust on the backend there are pretty fast templating engines. >templating engines imagine thinking this is a thing

>>29513 I completely agree. >>26675 forgot that sqlite is not written in Rust and isn't blazing fast memory safe! He's only a 5x engineer!

>>29513 I don't know what to make of this post. Are you saying that templating engines don't exist? Because I'm fairly certain that they do. >>29527 People like to dunk on Rust, and I get why, but for stuff like webdev it's genuinely pretty good. It helps to think of it as a fast high-level language rather than a slow low-level one.

>>29504 https://boards.4channel.org/g/dpt Post a little something in the current Daily Programming Thread. That's probably your best chance of getting the attention of people who are familiar with imageboards to take a look.

https://www.gwern.net/Backstop#internet-community-design >Internet community architecture can be seen as a bi-level optimization design too. >There are fast and slow methods of interaction, and ideas or knowledge (or just ‘memes’) are created, varied, and selected on. >These interactions happen inside discrete communities which are themselves created, varied, and grow. >So, they are instances of multilevel selection.

https://gitlab.com/a1360/anchorchan I've been working on a desktop imageboard app that auto-connects to the I2P network for you. It uses hashcash to build a proof-of-work chain for creating accounts. The longer the chain, the more access you get. The goal is a high privacy imageboard which can be effectively moderated. It is very early days and buggy. I2P is slow to connect to, but gets faster the longer you leave it up. Too early to be looking for users, but some early feedback would be welcome.

>>29557 > Cool website though. They say 'protecting people's privacy', but the site's completely broken without buckets of 3rd party JavaScript?

I wrote my own chan too, you can see it at solarchan.club No fancy distributed db or anything, it's designed to be low-tech. It works without JS and renders nicely in lynx. Before I launch, I want to add RSS feeds for the whole site, individual threads and for categories(boards). I'd also like to add a gemini mirror, and an ssh interface like EinChan had.

>>30139 How old does an account have to be before posting is allowed?

>>26674 to any of you python bros, would aiohttp be suitable for this? i feel like the performance would benefit of an async approach. what i am thinking is that aiohttp does not really provide much out of the box like other more mature frameworks and i personally don't like fastapi/starlette nor think that they would be most suitable for an imageboard. should i just go with aiohttp and write come utils from scratch?

I thought of making some sort of 3d interactive chan as an experiment, i can do backend myself just fine but im kinda in a rut as to how to do frontend, software rendering wont do probably. Its just an idea, but one o dem days im gonna do it.

>>30336 Worry about getting traffic to your imageboard before you worry about efficiency.

go with the spring java implementation so i can laugh at you

>>30412 Read it all and was waiting the entire time for the simple question >why? It was vaguely answered with a "genuine market of ideas" toward the end. Sure. Okay, ideas. Great. As if people from imageboards do anything. I cannot see imageboards as anything more than a waste of time. I am ashamed of myself for lurking and browsing here like a neanderthal. You don't get anything other than brainwashing & bitterness. The entire paper emphasizes how important it is to be a part of the hivemind of its culture. What a noble disregard of identity... by forcing a board culture more rigidly! That isn't high at all, it's just a bunch of groupthinking sadnes. Liveboards are cancer incarnate; if "cancer" is the inability to pick up on the things around you, what is more cancerous than to eject from reality and corrode it into constant brewing soykaf and realtime fap threads – this is seriously a thing on these liveboards, where you encourage each other to jerk off – how is this anything but the utmost form of cancer? You have effectively conceded enacting any real change. Give up your brain to the hivemind for some laughs! They think they've somehow made a step forward from identity based networks, but left out the most important part: addictive patterns that serenade you to a silent death in your little room. Liveboards are just creating a more addicting way to waste your life, despite such ethos that embroiders both liveboards and staticboards and all social media nonsense.

>>30415 fully agree brother. the quality of my life has risen exponentially after quitting 4chan a while back. The more internet I cut out, the better my life gets.

>>27162 >Remember to Store passwords as SHA-256 Is this a troll? Hashing with sha256 before the final hash makes little difference. Only wasted time

>>30412 >>30415 Don't think too hard about it anon. The person who wrote this is a retarded pseud pedo twitter user.

>>30838 >pseud I noticed that too. The writing doesn't say a lot but uses many words, and go into much detail how the stats they quote are connected to their imageboard implementation. There's no takeaway other then "oh that's a nice website you ran". No details you can build upon. >>30836 No, it's a sincere post with decent advice. Of course, there are more appropriate hash functions, don't forget the password salt. Java 8 is a bit old, today I would recommend you to use Java 17 as it's an LTS supported by Adoptium/Azul/Microsoft. I would not recommend JSP, there are plenty of mature templating libraries out there. Thymeleaf, Velocity, etc. If using Spring, use Spring Boot. SQL is great.

>>28378 Was also going to suggest meguca (now called shamichan). Been digging through it over the last few days & the code is pretty decent. It's real time though. That is to say that other users in the thread can watch you type as you draft your message. I'm not really sold on that feature, and it would take some effort to make it possible to opt out of. https://github.com/bakape/shamichan

>>30412 Kinda funny. I read it recently too and started writing my own real time board cause I wanted to try an maybe interesting spin on moderation with it. I might post about it later here. >>30415 I thought like that too, and I've been on both real time boards and it's true they are for masturbation addicts. Difference being one is for TikTok ones other for anime ones, but it also made me think maybe the real time aspect could make the conversation more genuine. People in real life can have meaningful discussion or debates and their talk usually lacks the grandeur of something where you have an eternity to write a response. Sure, they'll never have the long quality posts that some image boards have, but they might get quality conversation where ideas bounce faster between each other.

>>30888 Meguca did this, right? The post volume is so high for live updates that it’s unreasonable to actually read threads. You just jump to the end and live in the moment. And that’s so much like IRC that it should just be IRC

I dunno what I was thinking then. I already pretty much trashed proof of work since I can’t think of a good way to implement it, right now anyway I still want to attempt the idea however, and I have a half-working engine right now, so I’ll continue hacking on it.

>>26674 Honestly, complicate things just for the sake of it even though complexity is non-existent for building images boards. Go have fun, the world's your oyster.

>>26674 Not OP, but I set out on writing my own chan style site recently. Though I want to add logins + some sort of basic reputation system to stop cp posters. If anyone is interested in the tech side of it I would be happy to explain and maybe receive some feedback.

>>32600 >Why the fuarrrk would you need proof of work for an imageboard, Actually, using something like mkproof would be a good way to combat spam. It works even on Tor. >>33100 Pls post ITT. >Though I want to add logins + some sort of basic reputation system to stop cp posters So, you are making a traditional forum instead. Don't add votes because upvotes/downvotes punish posters who post different ideas than what the majority likes (even if their post is well written and the arguments are good). On Reddit, the posts are sorted by votes by default which makes it hard to follow the actual discussion (which is why Reddit is only ok for sharing links). This link explains why registration is bad: https://wakaba.c3.cx/shii/shiichan

>>33102 I absolutely would not add up and down votes, and I would hash users emails etc, sort of like how signal originally handled user data. Cp spammers are a genuine issue on most image boards + I think the community aspect could be expemplified with username.

>>26674 >>34252 Does op or anybody know how customizable the mod panel is (on tiny board or some other) php board? Are any compatible with ai? I want to tool around with moderation features / make them self learning in some way. Thanks to all the comments itt covering security measures btw. I've never messed around with one but I want to build an IB as a hobby. Just learn backend databases and ai. There are probably better ways but this is relevant to me.

Recently "finished" with an imageboard that have been working on pieces of for some time in different languages and libraries. This implementation is written in ~850 lines of Python as a Flask app and is distinguished by its nice UI, (mandatory) session based user logins, user history pages, and lack of javascript. It has standard vichan-style text formatting, and backlinks. Beyond the obvious features of the UI which can be seen from the pictures or are ordinary is automatic dark mode, respnosive front-end (hamberger menu for boards), click to scroll catalog tiles, and granular (per-action) permissions. Source code hopefully to be uploaded soon.

>>40294 Do we really need another leftypol tech? Are the breadchuds infighting again?

>>40318 >Do we really need another leftypol tech? Hadn't decided on the theme, or whether to host it or not. The name is presently "cyberia" but this is subject to change.

>>40317 To play devil's advocate, login walls are useful if you want to prevent spam and driveby brewing soykaf. Not every poster is going to have something of value to contribute, and on an imageboard in particular, it's very easy for the garbage to overwhelm quality stuff. And, in my experience, casual posters contribute very little to an imageboard's early growth. Successful imageboards pretty much always start with some kind of preexisting core audience coming from somewhere else. This goes all the way back to 4chan itself, which started as a pseudo bunker for ADTRW users. >>40318 >breadchuds I've never heard this term before in my life. If you're conflating leftypol with "breadtube" libs, you don't know leftypol very well.

>>40320 Explain how leftypol is any different from the horse fuarrrker "anarcho-syndicalist" Vaush trash.

>>40322 Leftypol makes fun of vaush and friends pretty regularly. The general consensus of the site is much more authleft than it is libleft.

I just want a 420chan that isn't run by an FBI narc CUNTBOY, or maybe a Barbelith that isn't run by the Science Council of Krypton.

>>40294 Am not going to make the mistake of bumping this thread again but would like to post the source code for this project here: https://codeberg.org/jung/arsvia/src/branch/main/arsvia There were some UX changes since all the screenshots uploaded previously, but the main noticeable one was the switch to UUIDs. The idea here being that this could be used to make the application federated more easily, although it does not seem like this feature will be implemented any time soon. The project is also missing documentation.