Man, I wish I could code stuff. I certainly have the free time for it.

>>162519
Programming's a fun experience once you've learned the fundamentals. Most of my experience beyond learning the basics was entirely out of free time.

>>162520

I have actually taken a couple classes on it, it's not like I don't know anything at all, but I'm not sure I really have the experience or knowledge to do anything for the chan. I guess I could try working it out, though, if it went open source.

>>162521
I see. But yes, no matter how much experience anyone here has, there's nothing we can do to help because since the site's closed source, we don't even have anywhere to start.

Last edited at Fri, Nov 21st, 2014 22:55

Well our coders have already burned out, it looks like. And since they're the only ones who can bring on more coders, we're kind of screwed. I mean, I'm admin, and "adding new coders to the staff" isn't anywhere in my job description and isn't something I possess the capacity to do even if I wanted to.

And not only do I have no idea what making the site open source exactly entails but I've got like... a bit of vodka in me.

It sounds like a great idea at the present moment, though. I'll just ask without any sarcasm what's the worst that could happen first off. Like, there's a lot of stuff that users trust us with (primarily IP addresses) that we try to not abuse. If it's open source, would it be possible that that sort of thing would become borked?

>>162525
Typically with open source projects, you have a bunch of users that are able to commit to the repo, but nothing gets implemented until a coder makes the update directly, which allows opportunity to review the code first. If there's something fishy about the change made, a revert can be done where that change has been made. I feel that we can trust Zeke, or whomever it may be, that no backdoors are made in the project. They'd be pretty easy to notice. Github highlights changes exactly where they were done.

>>162526
I'm like 90% sure we have something like that already. I could be totally wrong though.

The views and opinions expressed herein are those of Drunk!Yang and do not necessarily
reflect the views of Sober!Yang, Ponychan, its affiliates, its staff or its users.

>>162527
We do, but the only things that are public are scripts and front-end stuff that is already accessible otherwise, so it's pretty much useless to us.

>Kusaba X
this was my problem with coming to ponychan in the first place. The coding is so bad, damn Keilbasa Sausage. It is more than is a disgrace to modern image boards and should be utterly replaced. I think making the site open source would be a wonderful solution and should be Heavily Considered by the site staff if they want their site to continue in the future. It would give myself and other coders out there ability to work on helping this chan that a lot of us care about, but i don't feel there are many of us out there who are keen on letting this place die.

Yeah, coding seems somewhat ded. I'd fully support this, assuming we don't have tons of security holes that will be exploited and never fixed in the source code.

If we actually have people commiting and patching and updating, then I think this is worth it.

Last edited at Sat, Nov 22nd, 2014 06:28

Your efforts shouldn't go unappreciated, Shutterbox.
If we'd merged you would have been likely asked to be a much more official developer.
Thanks for the work and level-head you always show.
Anyways, I doubt anyone else wants to start digging their hands into kusaba spaghetti, or that the tangled mess will end up any more improved from even more hands and methods trying to make it even more ad-hoc.

>>162533
Seconding appreciation. He's top bro for not just this but everything else.

anyways,
>tangled mess will end up any more improved from even more hands and methods trying to make it even more ad-hoc.

I'm not sure it would be really like that. I think the open source part is that he was addressing that people lose interest and just stop developing or lose their time. He said that even he doesn't have much time.

If it was open source yet maintained and approved by a few people it wouldn't really have to get messy. You just deny that code or fork (with crediting) a more sane version of that code. It wouldn't have as big of a problem with burn-out.

>>162528
So you're saying that our Github is inadequate, and we should set up a bigger, better Github somehow? In what way is our current setup insufficient?

>>162534
>>162533
Thanks for the kind words guys. I only go through with this because I care about this place, much like all of us do.

Also I should mention that from my understanding, it’s typically the trend for open source projects to organize themselves first before much is even changed. More hands means more people want to have the deepest understanding as fast as they can before many new features are added. And if it’s really that much of an issue, perhaps we can ask Zeke if he could make Gochan public to push it out faster without him singlehandedly doing all the work from start to finish.

>>162536
Well basically yes. Main reasons are that it doesn’t really provide anything that isn’t already accessible from the web inspector. It’s just all front-ends, which are always public regardless. That’s probably why no one ever used it. Second reason incidentally being that it’s 2 ½ years out of date, so you can’t use it anyways.

>>162537
What about our bitbucket?

>>162538
It's exactly the same circumstances.

>>162539
Really? I thought that was more recent.

>>162540
https://bitbucket.org/ponychan/ponychan-kusaba/src

It looks like Orange at one point changed some CSS, but everything is still outdated. Notice how kusaba.js's last update is from May 2012 despite post-editing alongside a whole other features have been made for this site since. Not to mention, the repo is just as incomplete as the one on github.

>>162540
I don't believe that the PHP which comprises most of the site's code has ever been released publicly, no.

There would need to be some things redacted (mostly in config.php), and someone would need to be active as a maintainer who could review submissions and actually push changes to the site (otherwise that would become the new bottleneck). Ideally that would be assisted by some sort of release management tool...

There's usually lots of wailing and gnashing of teeth about the use of Kusaba X, but the reality of it is that Tinyboard didn't really exist when this site started, and it would require a major effort to move the site to a different codebase without losing features. Of course, that's not to say it couldn't be done, but so far there hasn't been a compelling reason to put limited resources into doing something like that.

>>162542
I think you'd be presented with the repo as if you were just opening Ponychan out of the box, wouldn't you? That way you can test your changes in a local workspace first.

I understand that Tinyboard wasn't an option at the time Ponychan was made. But considering the amount of work and cleanup the site's application currently needs to clear the way for devs that don't already have much of a deep understanding of it for future development as well as the need for better means of organization to make updates in the future quick and less prone to subtle bugs, I feel that the amount of effort to just overhaul the site wouldn't be much different. Though I think Zeke was already planning something like that with Gochan, which sounds like a promising idea because not only is it more organized but he'd be more familiar with it than kusaba or tinyboard anyways.

>I’ve been trying to be optimistic about this site’s future, but the one and only reason why I’ve had little motivation to keep working on site projects (such as updates for Ponychan X and a more recent project I’ve been starting) around here is because I’m not even certain that anyone will ever implement it.
Likewise for why i havent done a thing with /art/fic/collab/ since i made threads talking about the issue.
My bastardized tags wont cut it, and asking codeponies to do it properly just feels pointless considering the last time i did that went hilariously stupid.

>>162534
>>162533
Thirding appreciation boner.

-------

Argument against open source:

"basically if people can see how the proxy detection and spamfilter and stuff like that works, it's easier to get around it"

How valid is this, I'm assuming 'not very' considering the number of other sites that are open source while simultaneously not being open doors to Spam and such.

>>162546
You know what must be done. The prophecy must be fulfilled. Take up the sword that was broken. It can be remade. Put aside the Ranger.

>>162546
>How valid is this
Its valid. Closed source projects are harder to see what security holes exist easily. Sure you can find some, but with open source code you can just take a look or run it through a security check on your side or many other things.

>>162532
>assuming we don't have tons of security holes that will be exploited and never fixed in the source code.
I don't know how bad kusaba is as i've never looked at it nor am really that good of a coder at this point to just see harder-to-find holes, but I can read the /meta/ threads that have to do with coding and can just take from there. From what it sounds its completely vulnerable at its core, and the only way to fix that is to make it into a complete monstrosity (which half has been done from what's I've read as well) that is hard to maintain...or just hide those holes from the public. Which to me is the biggest problem with open sourcing.

I think a good fix would be open sourcing everything except what interfaces with a database which would contain things like encryption things which while not perfect creates a bit of a buffer as they'd have to find out what that encryption would be.

Last edited at Sat, Nov 22nd, 2014 20:19

>>162546
Thanks for your understanding.

But first I should mention that anything of which is still kusaba-based is already open source in the first place because kusaba X itself is an open souce project in the first place.

The spam filter mechanism, correct me if I'm wrong, functions the same way it always has - with a blacklist, which is kusaba anyways. I don't think I've ever gotten a "flood detection, post discarded" message on ponychan. I've gotten it on tinyboard-based sites though, but they're already open source anyways so that point is probably moot regardless.

As for the proxy detection (I assume the thing with the 'previousip' cookie that only pops up during raids) all I can tell you is that I think I already have a clue of how it works despite not having the source at hand. But as you pointed out, almost all imageboards out there use the open source features for this stuff at hand and don't get attacked by spammers.

>>162549
This, I think also is a valid point, but I also feel that it's overshadowed by what you get in return, not to mention that if security holes are pointed out, they can be patched as quickly as they come to light. I don't really know much about cryptography but encryption algorithms probably don't need to be hidden because it's still kusaba's default, which is once again, open source, albeit patched from where Macil pointed out where it was flawed (without needing the site's source code to point out that it was flawed nonetheless).

>>162541
I may be wrong, but I thought that this was actually brought up a year or two ago, and Orange's response was that he had already done so many rewrites to the code of this site that an update would break the chan. I remember him seeming confident his patching was better than the Kusaba update.

I could be wrong though. Many drinks were had during that time period.

>>162552
The Saba software was written by hooligans, rewritten by juveniles and forked by heretics to form Kusaba X. The only good thing that would have come of it was Kusaba X update 2.0 (or something like that), but that was too time-consuming for the author so it was scrapped. :(

Last edited at Sun, Nov 23rd, 2014 07:41

>>162550
Mind contacting me on Skype?

>>162552
>>162550
Asking orange to explain things in-thread, since i'm not sure on how much of what i know is something i should be blabbing about.
Star is correct though.

>>162555
>>162554
Okay, well what I got out of the skype conversation clarifying this post >>162550 I made last night was that
1) The 'previousip' cookie might not have to do with proxy detection. Proxy detection is its own entity separate from the temporary anti-raid measure. Both of which have their reasons to be partitioned away from source code, which is how major open source sites handle anti-spam and ban evasion anyways.
2) The spam filter is similar to what I said. It's a blacklist with some changes to it, but admittedly not so effective.

>>162552
Oh yeah, I'm sure of it. But to be clear, I wasn't referring to updates from kusaba x to ponychan. I was talking about updates from ponychan to the repo.

I guess I should be the main one talking here, being the main coder.

Ponychan's code is not open source, as far as I know. If it were up to me, I would keep it that way. Partially because it is such a patch job, and an admittedly messy one at that, but as ugly as vanilla kusaba is, it can't be helped too much.
While it does have its security faults, organizing the code in a way that could safely be put out without exposing more problems would be a waste of effort that could be put into doing more productive work.


That being said, there are plans to eventually start making the move to my own imageboard software, Gochan, which is open source.

>>162537
>And if it’s really that much of an issue, perhaps we can ask Zeke if he could make Gochan public
http://gochan.lunachan.net/
http://bitbucket.org/eggbertx/gochan

>>162559
Have you folks considered finding some other volunteering coders to take on as officials?

Because if you get swamped in schoolwork and Orange's atytention is called elsewhere, and ponychan suffers a crash, this site would be down for a while again.

>>162559
There is a certain trap that I can foresee: because there are plans to move to another codebase some time in the future, development on the current one seems like wasted effort, so is low priority, but if the new codebase is also a way off, nothing visible could get done for a long time (possibly indefinitely). Even with that long term goal, having some devs around to do maintenance like adding the existing tagging system to /oat/would make sense, particularly if you're busy.

>>162555
There's not much more to say that hasn't already been said, but I'll chime in as requested.

Long story short, I'm in favor of open sourcing the current codebase, but to do that responsibly would take a lot of effort that nobody seems to have the time for. The original plan with the github repo was to audit the source bit by bit, separating out the sensitive stuff, and adding files until we were done, but that never ended up happening. Back when I first discussed open sourcing with Mithent, there were a number of concerns that we shared about just plopping down the whole thing all at once without reviewing it, and I've passed those along to the current staff as well to take into consideration.

Re: hiring other coders, that I'm also in favor of. But we'd need to straighten out our deployment process first. That is to say, you know, have a deployment process at all instead of poking at files in production and pretending source control doesn't exist. I'm as cowboy as they come, but even I know that just doesn't work if you're not a one-man team, and barely works even if you are. A team can't scale without some kind of discipline. That should be step zero before we add more cooks to the kitchen. Back when it was just me, I used to use the dash image server as a staging server, and I had a single script to deploy to either staging or production. It probably wouldn't hurt to make something like that official. http://dash.ponychan.net/chan/oat/

And a side note (echoing >>162561) I really hope the current codebase doesn't stagnate in the shadow of a rewrite. There's never a guarantee a rewrite will be successful, in fact the last rewrite effort in Python petered out about halfway through. Despite our code's subpar aesthetics, it's the code that directly affects the users today, and it's certainly battle-tested and has served us reliably and consistently for several years against some pretty hostile and determined actors.

The OP mentioned a lesson to be learned from Netscape. Here's a second one (though I don't take such an extreme view as Joel, and Ponychan isn't quite on the scale of Netscape, it's still a valuable piece of wisdom): http://www.joelonsoftware.com/articles/fog0000000069.html

>>162717
I was pretty excited about that python rewrite. There were some really neat ideas floating around during that.