Kirsle.net
The reasons for the switch-over are numerous:
index.cgi on Kirsle.net was sucking up so much memory. ;)I named the new project Rophako, because I was sitting at the Github "new repository" screen for a half hour trying to think of a name, and ended up just making use of my Azulian Translator to come up with a name. So, Rophako is Azulian for "Website." I'm a clever genius, I know. ;)
You can check out Rophako on Github: https://github.com/kirsle/rophako. The "default website" that comes with it isn't very polished yet; I literally just finished writing the code to support Kirsle.net. So, sometime later I'll tidy up the default website and have a working copy of it running on some subdomain like rophako.kirsle.net.
Anyway, this is the new CMS. I ported over all my old blog posts, comments, comment subscriptions, and things of the sort. All the old URLs should work too, due to my kirsle_legacy.py module in Rophako. If anybody finds any broken links or issues with the site, let me know. :)
Update (4/9/14):
I've polished up Rophako's default site and have an example running here: http://rophako.kirsle.net/
That's the site you'd get if you download and install Rophako (minus the blog posts and photos ;) ). So... the project is officially in "beta" status now and is usable!
Fortunately it wasn't too difficult to fix my code for taint mode to work. I was already centralizing my various string filtering functions to a small handful, which just needed to untaint the strings before returning them.
Then it was just a matter of making sure I ran these filters everywhere that a user ID gets passed into a function (I was relying on the fact that my userExists() check would fail if you give a bad user ID number, but the variable was technically still tainted so I had to fix that properly).
I've thoroughly tested all areas of my sites to make sure nothing broke. Hopefully I didn't miss any. :)
So I've decided to post about a fleeting thought I once had, about where the Siikir CMS may end up one day (specifically, for Kirsle.net). Just to clarify, both siikir.com and kirsle.net run my Siikir code; they only differ in the pages and web design. The back end is kept in sync between the two.
I increasingly dislike Facebook, but I'm sorta stuck with it because it's the only way to keep in touch with certain people. There are a few open source, distributed social networking projects, such as Diaspora and GNU Social. The idea of these distributed networks is that anybody can set up their own Diaspora or GNU Social server, create their account on their own server (or let their friends or family create accounts), and they can still connect with millions of others who have accounts on various different servers.
They do this by utilizing open standards like OAuth and OpenID to share content between the servers. In theory, every Diaspora server should be able to communicate with every GNU Social server, even though the software is different, because they use the same protocols for sharing data.
I'm not interested in creating a social networking platform for the sake of creating a social networking platform. I'm more interested in finding something to replace Facebook for me. This is the primary goal of creating my Siikir CMS. I built it because I wanted to run Kirsle.net on it, and so Siikir supports web blogs, photo albums, messaging and commenting.
This way I can keep my blog and photo albums and things on Kirsle.net instead of on Facebook. But, I'm slowly adding Facebook integration into the Siikir CMS, so that eventually, I'll be able to post new photos on Kirsle.net and have my Facebook news feed automatically notify my friends to come and check them out. This is the short term goal; the long term goal is to implement OAuth and other standards so that Siikir can link with Diaspora and GNU Social servers.
In other words, Siikir may eventually grow up to be a distributed social network platform like Diaspora... even though that isn't really its goal.
(siikir.com will probably remain as an isolated island to itself, because it doesn't really fit the model of "general purpose social network." But if the Siikir code gets to this point, it will be released as an open source social networking platform)
With mod_perl, the Apache server would run its own built-in Perl interpreter which would be re-used between requests, so that the overhead of having to load the Perl interpreter for every request goes away.
I tested it on my dev server first, and got it all set up and then realized it doesn't work with mod_suexec. With mod_suexec, you can have multiple users on the web server who each have their own websites, and their Perl/CGI scripts will execute in the name of the user instead of as the global Apache user. So then, it makes permission handling easier: the Perl script can read and write files owned by the same user who owns the entire website. But, with mod_perl, the Apache user executes the Perl scripts and this causes problems.
So I found an alternative: FastCGI. It's black magic to me, but it works similarly to mod_perl (reusing the same Perl process for multiple requests), but it does work with mod_suexec. So, I've gotten Kirsle.net and Siikir.com to both use FastCGI now, and, well, both sites run a lot faster. :)
Every request still creates its own unique instance of the Siikir CMS object, but I did tweak my JsonDB plugin a bit for performance too: while every request has its own CMS object, the JsonDB plugin is always a singleton object--it is only initialized once, and then it is shared between every request. Also, it caches the DB documents when it reads them and keeps the cache in memory until the document changes on disk. So this helps tremendously with the file I/O problem on my server. Running the search page on Siikir.com gives results in less than 3 seconds, whereas before it would easily take 10 to 15 seconds.
I'm still keeping a lookout for new bugs that may emerge, though. I have to test and make sure the JSON document caching is working properly, for example. But for now everything seems to be working out pretty well. :)
* There's an admin GUI for reconfiguring the site's plugins (not useful for end users)
* All photo thumbnails are now square shaped. I'm using the jQuery Jcrop plugin for this.
* Comments on everything by a guest user now supports Facebook Graph API to login with Facebook.
These changes are now live on both sites. Also, the web blog and photo commenting code is live on Siikir now too (but blogs are still for admins only until I work out a safe way to restrict HTML for the regular users).
Everybody's existing photos were automatically cropped down. New photos uploaded get cropped automatically, but the user is immediately given the option to change the thumbnail himself. You can also re-crop the photo at any time from your photo view page.
Siikir.com has just been uploaded to my web server. I said I'd have it up by the new year, and I did. :) It's a gay social network site (see my previous post about it).
Now that it's up I'll mention some of the other features I came up with for it that I haven't seen other sites do, or do correctly.
"Self-moderating" photo system. It's annoying when a site makes you wait 24+ hours for an admin to come by and approve every pic you upload. So on Siikir, I came up with a better way: all public pics go live immediately!
If a user flags your pic as being inappropriate, then it goes into the "Pending Approval" mode and is temporarily taken down until an admin can look it over. If the admin judges that the pic is perfectly fine and not in violation of the rules, it goes back up, and cannot be flagged ever again by other users; it has the admin's blessing. If the picture is indeed in violation of the rules, the admin will have it deleted.
This whole system is full of statistics keeping though, if a user abuses the system and keeps on flagging pictures just to be a pest, the admin can see how many pics they've flagged and how many of those flags turned out to be false. Eventually in a future update I'll be building in a karma system, so that users who consistently upload good pics will require more flags before it goes into "pending approval" mode.
All free. SO annoying when sites ask for money to use some crucial and obvious feature, like replying to messages or seeing who thinks you're hot. Siikir will make its money in other ways, like Google Adsense or a "featured profile" feature to come.
First I should say what my project is. It's called Siikir (pronounced like "seeker"), and it's a gay social network website and mobile app. I'm creating it because I'm disappointed in all the currently existing things that it will be competing with; they all have features that annoy, or else a lack of features that is also annoying.
If any of y'all know me from when I was like 16, that's when I programmed a gay social network site from scratch that I called RainbowBoi; I abandoned it a year later from lack of interest, but the disappointing sites out there today have motivated me to try a second time.
I won't spoil the full list of features just yet, but one of the big ones is that "Grindr stalking" will be much more difficult (if not made impossible) to do with it, than it is on the iPhone app, Grindr.
Grindr is an iPhone app for gay guys where you can locate all the other gay guys near you. Its feature set is rather limited: one profile to a device, you can have one pic, a small set of profile details, you can send messages and pictures to other users and you can bookmark users. Sure, Siikir will be competing with this, but the competition will look like RiveScript vs. AIML; my feature set already surpasses Grindr. But this post isn't about that.
No, it's about Grindr's bookmark feature.
You can boot up Grindr, locate somebody you know (such as an ex boyfriend that you haven't quite gotten over yet), and... bookmark them. Don't send them a message, just bookmark them. This will place them at the very top of your list of guys, forever. And the poor victim has no idea that you've even bookmarked him.
And now you can just silently stalk him ad infinitum. He can't upload a new picture, change his profile or anything without you knowing about it. He can't delete Grindr and reinstall it, because Grindr ties a profile to a device and he'll still be bookmarked on his stalker's phone. He has to be lucky enough to find out what profile is the stalker's and block him to be free.
Siikir will prevent this sort of abuse.
On Siikir, when you locate a profile in a "public" place (like the search results page), the link to view their profile will be temporary (but share-able). The link in your browser URL won't look like "/users/kirsle", but rather something like "/users/hash.432ebc113ac1662=". The URL is encrypted, a random hash that will expire after 15 or 30 minutes or so.
Search result URLs are temporary, but are shareable; if you find somebody you wanna show your friend, you can paste that URL over MSN Messenger; but regardless the URL has been generated by the server and has an end-of-life already ticking down to zero. This URL can't be bookmarked in your web browser, for it won't be there anymore when you try to return to it.
The only way to get a permanent URL, then, is to make contact with the user. Siikir will have a bookmark system, but the user you bookmark will be notified that you have bookmarked them. Sending them a message and saying hello is just as fine. Either way, before you get a permanent link, the user has to also be aware of who you are.
The obvious loophole is that you only need to find somebody who already has the permanent link and just get it from him. Sure. That's why for the extra privacy-conscious individual, they can turn on an optional "Make my profile unlinkable" feature. This will make it so that, even on a user's bookmark or inbox page, the links to your profile (which would've been permanent links) are also temporary. Only, these links cannot be shared on MSN; they are temporary and tied to the session of the end user who sees the link. Search result links can continue to be shared though, but are, of course, still temporary.
I only have a couple key components of the site left to develop and it will go live with a public beta shortly. I plan to have it up and running by the new year. The Android app will follow quickly after the site goes up, followed later by an iPhone version (as soon as I work up the courage to wrestle Apple with their app store procedure).
0.0018s.
