sbenthall / tweetserve Goto Github PK

Should be able to turn off retweeting of @replies. Retweeting an @reply means somebody loses control over their conversational context, which is a privacy violation (c.f. Nissenbaum)

While the current design operationalizes 'networked power' with node degree, that is naive. Take lobbyist-like influencers into account.

Whoohoo!

The print statements are useful because they make it into the emailed cron reports, but right now they are spread out throughout the script code and that is lame.

It would be better to do some more templating and be less ad-hoc.

(tweetserve)harbinger:~/projects/tweetserve$ python script.py
'Waiting 1 minutes'
'# mentioners: 148'
'# unprotected mentioners: 148'
'# unique ids: 104'
Traceback (most recent call last):
File "script.py", line 68, in
tweetserve()
File "script.py", line 36, in tweetserve
friendships = lookup_friendships(ids)
File "/home/sb/projects/tweetserve/funcs.py", line 39, in lookup_friendships
result = t.friendships.lookup(user_id=query,_method="GET")
File "/home/sb/projects/tweetserve/lib/python2.7/site-packages/twitter/api.py", line 245, in call
return self._handle_response(req, uri, arg_data, _timeout)
File "/home/sb/projects/tweetserve/lib/python2.7/site-packages/twitter/api.py", line 276, in _handle_response
raise TwitterHTTPError(e, uri, self.format, arg_data)
twitter.api.TwitterHTTPError: Twitter sent status 403 for URL: 1.1/friendships/lookup.json using parameters: (oauth_consumer_key=xPWeJ3r8hEjI33spI1ZN6B1P0&oauth_nonce=2954199064480817866&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1441848468&oauth_token=2300627557-lhe1sbDBE6xFrLowAb40QDYR4D0BLvCDkKcwQfp&oauth_version=1.0&user_id=70097411%2C3431545366%2C16941591%2C14191640%2C22970910%2C35584702%2C36110368%2C47239208%2C99696173%2C312247861%2C46961216%2C2292266564%2C238436945%2C11916882%2C163291221%2C21568602%2C17050222%2C249331826%2C17886323%2C818805%2C458580088%2C10416252%2C3016048766%2C14585079%2C517032065%2C53040260%2C72323205%2C3552391%2C21037704%2C49266313%2C7135882%2C16473744%2C18261618%2C91244692%2C36504725%2C180441239%2C478807193%2C15820442%2C12289692%2C2432520866%2C22516903%2C633407146%2C1592491%2C14437549%2C89753778%2C16046262%2C14375609%2C16841918%2C15669956%2C348705482%2C963281%2C9662682%2C3072375010%2C359894755%2C214218470%2C2197860163%2C55908595%2C2474576119%2C34302200%2C61625083%2C377491711%2C42462490%2C263020833%2C31245606%2C43437362%2C211574581%2C95268670%2C3129088320%2C2884931%2C19184465%2C238610770%2C16941399%2C10190682%2C42354013%2C93774687%2C94230373%2C13333352%2C16256877%2C3020316528%2C31108470%2C612170622%2C20817793%2C16608649%2C22075279%2C17071427%2C15143317%2C613780382%2C275529122%2C53802919%2C87025073%2C454863282%2C2294846388%2C376503230%2C8836032%2C172490690%2C15267268%2C16255945%2C415339767%2C462952911%2C6000592%2C1845211%2C3518336481%2C14097908%2C30913020&oauth_signature=hKhTLVVlnx2cMoG8y0V7m%2Buk6BQ%3D)
details: {"errors":[{"code":18,"message":"Too many terms specified in query."}]}

Sometimes this will try to RT something that it can't. I think this has to do mainly with if it has already RTed the tweet in question. This should become less of a problem if things scale up, but it would be better to handle this gracefully (for now it just passes without error or logging...)

Better would be to find a different thing to tweet.

tweetserve software is meant to be usable by others and forked to enact other values. Need better docs.

currently the cron configuration sends its reports to my email inbox, which is rad, but it would be better longer term to write these to logs on the server. should have documentation about the cron setup to support this.

Some exclusionary filtering is necessary to prevent exclusionary violence. Probably should preempt this rather than just depend on Twitter's abuse handling.

It's not overly burdensome to look up the friendships on all mentioners with with endpoint

E.g:

https://twitter.com/ryanasmith94/status/459437843169804288

This tweet was RTed even though:

• it is not the most recent tweet by @ryanasmith94
• the more recent tweets had not already been retweeted by TheTweetserve

Mysterious. Possible causes: cached responses to user status query?

Ideally, rather than predictable periods of mention harvesting, this would be on a random schedule. I'm anticipating a threat model where somebody sets up an automated repeater that tries to blast out all other mentions before the scheduled time.

This is a potential feature with pretty major implications; maybe something optional.

Currently it's set up so that when somebody gets tweetserved, the account follows that person back. That means these users can DM the host account.

An interesting feature would be to periodically collect DMs and select one at random to be reposted, but anonymously.

That creates an additional layer of usage--an 'insider' group with special privileges. That could incentivize people to try to get tweetserved in the first place. Kind of cool how that obscures certain identity flags...

Hi Sebastian! I'm one of the co-creators of The Listserve, and I read your slidedeck on The Tweetserve. It's a fascinating idea, and you did a lot of thinking on the concept of parity in networks — far more than we did. We thought a lot about the value in content produced by this mechanism, and how to maximize that value. The metaphor I liked to use was a water balloon. The water is the content that people want to publish on the platform. But the balloon prevents it from reaching a larger network. So the tiny hole we poke in the balloon, which allows content to escape, becomes very valuable.

This may be entirely unhelpful, but it's great to see this taking shape!