jsha / blocktogether Goto Github PK

Redirect_by_id stopped working, use https://twitter.com/intent/user?user_id=NNN.

Right now some errors just leave the connection open with no response.

Probably delete the user from the BtUsers table. Probably also flush their stored Blocks and Actions.

Right now forAllUsersUpdateBlocks gets the wrong ordering because of sequelize/sequelize#2121, which means that it gets stuck on the most recently updated user.

Either work around the ordering bug, or decide on a way to eliminate the batch background updating altogether (e.g. updating only when the user logs in, or when their blocks are viewed, or similar).

Sometimes Log On will fail the first time - the user gets redirected to /, but clicking it a second time succeeds and takes them to /settings. Might have to do with revoking the app?

Right now the Blocks table grows rapidly because every user gets their blocks fetched every day and we never trim. Once a block batch fetch is complete, all block batches for that user except the most recent two should be deleted.

If person A has a popular block list and puts person B on it, then later decides that was a mistake and unblocks person B, that unblock should propagate through to people who blocked B through A's list.

This is fairly complicated, because if person C is blocking person B because of their presence on A's list, and additionally because of another list where B has not been forgiven, we should not unblock.

When blocking new users that @-reply you, or similar future streaming features, there should be a facility to block and then unblock at some time in the future. One approach: Add a 'notBefore' column to the Actions table, and when enqueueing the block, also enqueue an unblock with a notBefore date set a week or so into the future. Processing the Actions table would skip any Actions whose notBefore date is in the future.

Since actions for a given user are strung out over a period of time by recursive calls, it's common for a block to get picked up by multiple cycles of the actions processing. There should be a final step immediately before calling /blocks/create that reloads the action from DB and checks it's still pending.

Alternately, go back to sending out all blocks at once very quickly.

Right now there are some indexes on the server that I manually added. These should be represented in migrations.

It would be really nice to be able to use this without providing write access to Twitter.

I realize some options (adding to your block list, etc.) require it, but perhaps you could use an approach similar to what Lanyrd does, which is to let users connect as read-only, and only require write-only to perform certain tasks.

This might be more trouble than it's worth, but there might be a lot of people who, like me, won't use this tool because of the suspicious auth request.

If there are more blocks than can be displayed on a single page, we'd still like to block all of them.

Right now if a streaming user (one with 'block new users' enabled) revokes the app, the app will get a message indicating that and will respond by deleting the user from BtUsers. However, if the user is not streaming, we only find out when we make a REST request. We should consistently catch errors from Twitter in REST requests and delete the user when appropriate.

Note this may be solved an alternate way if the app is approved for Site Streams and we are able to stream events for all users.

During deploy this would detect a model mismatch quickly and trigger a rollback.

cf. https://twitter.com/meyerweb/status/496726614424576000

"It bugs me that Block Together says it won’t tweet on your behalf, but the app authorization allows it to post tweets for you."

Is there a way to reduce the permissions Block Together requires?

When a user revokes the app, we get an event on the stream that tells us what happened, and we can delete them from the DB. However, two users consistent have their stream closed by the server immediately after opening. Most likely this is because they have five or more clients that are using streaming on their account. Should investigate this and handle as appropriate.

Right now it's relatively easy to create spoof usernames with similar letters, e.g. i / I / l / L. This would let someone create a block list that appears to belong to a different user.

When displaying usernames, especially as attribution for a block list we should use a font that distinguishes all characters clearly.

These are the people I would be most interested in knowing about who they block.

Related to #44, but coming from the other direction.

Currently: block list is accessible to anyone who obtains the URL after it's generated.
#44 suggests: a discoverable/reasonable URL is created if users opts to make list Public.

PROPOSED: Require BlockTogether app authorized Twitter credentials in line with some permitted list of viewers.

So we might offer the current "secret-through-obscurity" URI, or a discoverable URL with access level set to one of, e.g.:

• Public
• Users I Follow
• Users I Haven't Blocked
• Members Of [Twitter List]
  #44 is a good place to start here, but combining control and discoverability at cost of complexity may be worth considering?

Over time this will leave us with a gradually increasing set of suspended users. We should mark them in some way, and retry fetching them in a different cycle so they don't clog up the main refresh cycle.

As required by Sequelize migrations.

Need to add field. Also modify update-users to ignore users with the deactivatedAt field, but retry them once a day.

Currently they show only uids.

like the "Block young accounts (< 7 days old) that mention you?" option, except the condition is "accounts that mention you and have under n followers" (and have n be adjustable)

I.e. [from:A OR from:B to:A OR to:B]. When reviewing one's own blocks, can be useful to figure out what conversation might have triggered a block.

https://twitter.com/DefiantlyDanica/status/497455308026171393

Since this reflects how recently an account has been active, it's likely to be a useful way to sort large lists of blocks.

After running for a long time, stream.js's notion of how many active streams it has diverges from the number of actually open sockets. Figure out why.

When stream.js starts up, it replays old @-replies to catch any it missed during a restart. If a new account @-replied many times in that window, it will trigger many actions, most of which will be resolved as duplicates. During @-reply replay we should de-dupe Actions before enqueueing.

Right now run-prod.sh runs the processes in an eternal loop, and we kill it by name during deploys. Upstart would be more flexible.

Also, cap deploy is confused by run-prod.sh because it backgrounds but never exits, and so cap deploy waits forever at the end of a deploy and needs to be killed.

Right now if there are more than 5000 blocks there's no way to show them all. Implement pagination and/or search and sorting.

Would be great if I could set my block list as public so it could be discovered.
example: /show-block/@stefanhayden

If a non-logged-in Block Together user visits e.g. /show-blocks/XYZ, and then clicks Log On, they should wind up back at the same spot after logging on.

Steps to reproduce:

1. Log in to Block Together.
2. Visit /settings, enable 'block new accounts' (this turns on streaming for the account). Stay on /settings.
3. On Twitter, revoke Block Together.
4. On /settings, disable 'block new accounts'.

Actual result:
Server crash

Expected result:
Error code in JSON response, ideally triggering a redirect to /.

This is tricky because it's often the case that a new abusive user will accumulate some blocks, get suspended, then unsuspend themselves. We don't want to drop blocks on the floor just because the target happened to be suspended at the time we tried to do the block.

One possibility: add a new state, pending-suspended, that actions go into when the target is suspended. These can get retried on a different cycle than pending actions, say once an hour or once a day. If a pending-suspended action is more than 7 days old, transition it to cancelled-suspended.

So users can see the difference between actions that were manually requested versus done by stream.js in response to an at-reply.

The current style means we get a rate limit exceeded if too many people view your shared link.

We have the blocks in the DB, we should display those.

Right now favorite / unfavorite / block / unblock events are handled separately from tweets, but retweets of tweets that mention you get erroneously detected as mentions by the retweeting user.

The right behavior here is not entirely clear since those retweets may generate unwanted notifications, but we should document exactly which cases will trigger the 'new account block' feature.

Right now when the app detects a user revoked it, it deletes the user object. It should also cascade that deletion to delete Actions, UnblockedUsers, BlockBatches, and Blocks.