selja@hepta

introduction to the bad ideas

hello! tonight i have for you some bad ideas i've had for the development of this blog. the first one of them i've actually started developing, for funsies, and the second one of them i've seriously considered. at the end of this post i muse on some of the problems both of them share.

bad idea #1

okay so the thing is that my current idea for the email thing is "writing my own smtpd that only accepts specially constructed messages so i can simply throw away almost everything with an error". it's not happening yet, but i've got a draft for how the server should work, and i'm working on it. so if in the future i make a note that you can send comments to a specific address in a specific format, you can then help me test this silly idea.

it will still require a pretty large amount of manual work (since the site is fully static and pre-generated and so would the comments be) but it's silly and i want to try it. also, it doesn't fulfill one of my criteria for the comments system, which is "relatively little attack surface for me to worry about". like, in some ways it's worse than web forms since it's at least relatively easy to make an application that just writes out form inputs. on the other hand, the thing i'm planning might make most email spam irrelevant... we'll see, i guess!

bad idea #2

but more importantly for this post, i've considered doing something silly: i've considered adding a microblogging feature to this site. you know, like twitter or tumblr or whatever.

i could already kind of do this by just adjusting my scripts slightly - i could pretty easily edit the publishing script to not put posts marked "microblogging" on the main feed, and i could easily generate a feed and display page for them. but that would be kinda janky, because i'd need a file for each post and they'd all get the same metadata as all other posts unless i special cased everything. i could also just make one special page like now or about that's the Microblog Page and generate a special feed for that... but really like, that's still kind of silly and janky.

i haven't decided how i'm gonna do this but it might end up being something like a micropub server..? after all, i've already found out that microformats match up pretty well to the posts i have here, and the format of micropub is. kind of trivial. so i might do it. but i might just also use a proprietary format, it really depends on what kinda clients are already available and whether i need to make my own regardless.

the core issue with both of these bad ideas

really whatever i do i just kinda run into one of the core things i'm thinking about here - i don't really want to have much state on the server. almost everything i have here (other than ephemera like logs and whatever stuff is needed Specifically To Run This Particular Server) is just a copy of data i also have elsewhere - i could literally take any static web host and deploy a full copy of this blog there right now.

if i put some state on the server that just lives there, i'll actually have to go out of my way to get it off the server if i want to deploy it anywhere else. that's slightly problematic, though for comments and microblogging it's not an enormous problem since microblogging is kind of ephemeral anyway, and the manual processing of the comments would require downloading them off the server regardless. but i don't really like it regardless.

also, i don't want much interactivity on the server, because that exposes me to issues that i couldn't reasonably mitigate. the first problem is denial of service - if i put a form or mail server or whatever here, i'm just going to be potentially using unbounded disk space and i'll have to manage somehow. the second is spam - the microblog won't cause this, but a comment form or mail server will, since its purpose is to invite messages from the outside, and i would have to deal with that spam... somehow.

the third issue of interactivity is unknown security issues. i can be fairly sure that my http server won't completely fuck up presenting static content, and that its http request parsing is moderately robust... but the more interactive a component i add, the more i have to deal with the possibility that some of that user input is malicious and succesfully exploits a security issue, gaining control of someting on the server. and this actually combines with the issue about state on the server - if something compromises the server, i can't just trivially redeploy it from scratch if some of the state is only on the server.

(and, also, if i make the server myself then fixing the security issues is on me, and i likely won't come up with patches on short notice, so it'll require shutting the service off... etc)

in summary?

i've got some silly ideas brewing for what i'm gonna do here and while i haven't decided on how they'll be implemented in the end, exactly, at least the smtp idea is moving along at a slowish pace, but moving nevertheless.

i'll post an update if any of these come to pass, and if i figure out something for the issues mentioned above.

nya