Less common pay keywords

[Kjell Bublitz (@m3nt0r)]

I have trouble with the word "give", "tipjoy" or "pay". Altough they
fit perfectly they are hard to discover in a tweet. That's especially
a problem if you plan to retweet messages or just feed other text into
twitter..

If someone creates a transaction within a message and have my app
retweet it MY account is charged. That's evil..

Example:
- somebody: "i would give @m3nt0r $0.50 if he would only allow it."
- me (bot): "i would give @m3nt0r $0.50 if he would only allow it.
(via @somebody)"

It would be better if there were only phantasy keywords like "rtip".
We could easily block them to stop this from happening.

I really thought alot about this and it looks like there is no sane
way around this problem. Of course i could just strip "give" and "pay"
but then alot sentences wouldn't make sense anymore.

Suggested Solutions:
- Account options to configure allowed words
- Account options to put all transactions on hold until confirmation.
- Radical step: remove "give", "pay" and "tipjoy" from allowed words.
- Don't allow "give", "p", "rtip" to appear anywhere in a tweet
anymore.
- API Method to check if a tweet contains a transaction. (To validate
before retweeting)

What do you think?

[Ivan Kirigin]

I like the idea of creating an API endpoint that, given the text of a
tweet, will describe the transaction that will result.

We ignore retweeted transactions that follow a certain syntax. The
(via @username) syntax is both hard to understand for a human and hard
to find compared to other syntax. I very often read tweets thinking
the user posting is the author, only to see the "via" at the end.

We ignore anything after "rt ", "rt:", "retweet" or "»". The
http://tatatweet.com app auto-retweets posts, and it successfully
blocks payment tweets by starting with a "»", e.g.
http://twitter.com/ycfounders

Ivan
http://tipjoy.com

[Kjell Bublitz]

Hello Ivan,

thats good to know! I like "»" for what i am trying. Thank you.

About possible new endpoint:

Some parameters that would be cool:
- status_id
- min_amount ( default = 0.01 )
- max_amount ( default = null )
- from_status_id ( starting from, if not single status )
- to_status_id ( ending at, if not single status )
- twitter_user_id ( only from this user )
- tipjoy_user_id ( same as above )

Notes:
- "from" and "two" would be helpful to analyze a timeline, for
example. "from" would be the same as "since_id" in the twitter api.
- The difference between "from" and "to" may not be greater than 100
(to save you processing power). This upper limit should be sufficient.
- The "min/max_amount" is useful if, for example, an app only accepts
certain amounts and doesn't care about other tips.
- "twitter_user_id" also helps to narrow down given range of tweets.

Kjell