Tuesday, August 31, 2010

A reStructuredText template for novel design using the Snowflake Method

This has been moved to my writing blog: http://swblack.blogspot.com/2010/08/why-authors-should-future-proof-their.html

[If you just want the goods, the original reStructuredText (.txt) template is available as well as a rich-text version that was uploaded to Google Docs.]

Why authors should future-proof their notes

This post has been moved to my writing blog: http://swblack.blogspot.com/2010/08/why-authors-should-future-proof-their.html

On the writing project

Until the end of NaNoWriMo 2010 this blog will also cover my writing projects. The success (or failure) of NaNoWriMo will determine whether I should think about having a separate literary blog in addition to this rather technical blog.

This "Projects and pastimes" blog has a history of being project notes, and usually fairly technical (when I'm not just ranting about some technology). If I'm going to pursue writing, it would make sense to keep the two separate. (As my spiritual blog will remain separate.)

At one point this blog was part of a personal blog. I've done the splitting before. I just wanted to warn folks.

Wednesday, April 14, 2010

My response to Twitter

Well, that's better news than I was suspecting. Once I got to the notes about not favoring automated features, I was concerned that the whole idea would be a wash.

On the plus side, if I'm never going to release it, I'm basically feature complete. All I need to do is add some additional error checking. (It should have some error checking now, but it could use a little more.)

If you're curious, the thing is currently a 140 line BASH script using curl to make the Twitter calls. It took me ~2-3 hours to get all the features I wanted and to verify they all worked. (This would be how I got a fully functional proof-of-concept before I thought to ask about whether such a program would be allowed.) I may try out a show using the current script before I do much more to it. It would be cool to integrate location tracking and timed uploads of photos, but both of those can wait until I rewrite the thing in Python -- and I won't be doing that until I can prove the core idea is moderately successful.

You are correct that there will be no automated account creation. I clearly read the section about scraping the site will cause your account to be terminated. Automating web browser actions in such a manner is functionally the same, and sites can be programmatically scraped in a manner that they look like they're having automated browser actions, so each is really just as bad. The plan has always been for each character to get the account created manually. I am glad that I don't have to worry about limits there. It should be easy enough to stay within reason.

re:other limits. The FAQS or API docs or other site information mention specific limit numbers. That's where I found out such things existed and were enforced. It is easier to just plan for reason and check for error, though, so I'm happy with the answers. To pull this off, the timing on everything needs to look like normal human tweets, so there shouldn't be any problems over-stretching the bounds here.

re: Replying to @people. This wouldn't be at all random. This would be very specific feedback *initiated* by the human. This is really to help keep up the illusion that it is all really happening. If someone asks a specific question about the story, the answer can be presented as if it is just one person replying to another via Twitter. I would expect most people to just watch silently and that would be it, but if someone asks a question directed to a character it only makes sense for that character to respond. In general, the focus will be on the other characters. Randomly including names of followers would -- quite rightly -- be seen as spam.

Since this isn't going to be a distributed project, I'll sketch out an idea, then create a website for the particular show before requesting a "source" identifier. This should make it even easier to identify the tweets as coming from an automated source.

I hope that also clarifies my personal stance on some of the issues you raised.


Steven Black

Tuesday, April 13, 2010

And Twitter replied...


Thank you for writing in. This application is indeed a cool concept but we agree that it presents some opportunities for spammers. Overall, we'd prefer that you not make it publicly available for general use, but feel free to move forward with your own uses. To answer some of your questions specifically:

2. We do not reveal our limits, as if they were to get out, users looking to abuse the system would operate just within the limits, and this would create bad user experiences. Account creation cannot be accomplished through the API, so it would be the operator's choice how many accounts to create, correct? Automating browser actions to sign up new accounts is not recommended.

4. If real people are @replied to, it should be made clear to them (either in the biography field or on an external site describing the play) that following these accounts subjects them to @replies. Unexpected or unsolicited @replies are often perceived as spam and could be reported as such, and even cause the sending account to be suspended.

5. Again, we do not discuss these kinds of limits. There are signals on both the absolute quantity of tweets but also the velocity of tweets, and even if you set a limit on the number, an account could theoretically post them all in a short time and still get suspended. Enacting an absolute limit would not therefore be required, as our systems would still monitor the accounts individually and take action as necessary.

Please let me know if you have any other questions.

[twitter representative name removed]

Sunday, April 11, 2010

Because I always need a new project...

The following was sent off to the Twitter folks to get their feedback:

#941064 Concerns about a new application I'm developing

I've prototyped an application which is designed to allow -- essentially -- plays acted out over Twitter. The idea is to essentially have a set of characters twittering from some altered reality. The idea is that I could put on a "War of the Worlds"-type drama (or perhaps a zombie invasion) using a small handful of Twitter accounts.

The application essentially runs a script, in a manner you would expect given the desire to put on "twitter dramas":

userid TIME-SPEC message

The definition of TIME-SPEC is sufficient to allow both exact times, as well as offsets from the previous message, so it should be both accurate enough and not clunky.

What I have now works -- I've done just enough testing to know that -- but I want to make sure that I neither violate any Twitter rules, nor make it easy for spammers to abuse my application.

1. Is the very concept of this something expressly not allowed?

2. On "serial accounts": To perform a twitter drama, multiple accounts are required. One account for each character -- otherwise the effect just doesn't work. However, to follow the drama either each post needs #marked, or the "viewing public" needs to follow every account. I think a larger cast with #ImATwiterDrama breaks the feel when compared to a smaller set of actors that the viewers need to individually follow. I think the strength here lies in limiting the number of characters. Allowing that writers can work within reasonable limits, what would be a reasonable limit to keep the spammers at bay?

3. Since these tweets would be a work of fiction, limiting their ability to post to trending topics makes a lot of sense. I can see the possible need for #ShowName, but other than that they shouldn't be allowed to #mark posts to influence trending topics.

4. The Twitter platform provides a unique method of integrating "viewer feedback" in to the show. While most of the replies will be between characters, real people will be @replied to -- but this is only allowed when the @human is currently following the character. This puts the human in charge, and should prevent reply-spam.

5. Regulating the number of tweets a day: This application makes tweets, but isn't designed to read tweets. (Reading tweets would be done by the author using their normal application.) The number of tweets normally allowed is pretty large. Should I add an application-side limit on the tweet frequency, or is this not needed? If a story has too many tweets it can start becoming clutter, but a slow build-up may lead to a couple days of frenzied activity. I just don't want to be too attractive to the spammers.

6. Absolutely no support for following people. If the character's accounts are to follow anyone it needs to be done by the author using their normal software. The goal is to get people to follow these accounts, not for these accounts to follow people. Also note, since the software should only allow @replies when the targeted human is following the character, allowing the character to follow a human does nothing as far as the software is concerned.

Since this program is essentially an automation tool, things need to be thought-out well before it is released so that it doesn't become attractive to the spammers. I know that. Once I had the proof-of-concept done I became upset as I realized how it could be abused. I still think it is an interesting idea, though, and provided it doesn't implicitly violate the terms of service, I would like any feedback you may have which would allow me to do this while still evading the spammers.

Thank you.