jsha / blocktogether Goto Github PK
View Code? Open in Web Editor NEWShare your blocks and subscribe to others'
License: GNU General Public License v3.0
Share your blocks and subscribe to others'
License: GNU General Public License v3.0
Would be great if I could set my block list as public so it could be discovered.
example: /show-block/@stefanhayden
So users can see the difference between actions that were manually requested versus done by stream.js in response to an at-reply.
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.
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.
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).
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.
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.
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.:
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?
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.
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.
Currently they show only uids.
Right now if there are more than 5000 blocks there's no way to show them all. Implement pagination and/or search and sorting.
Steps to reproduce:
Actual result:
Server crash
Expected result:
Error code in JSON response, ideally triggering a redirect to /.
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.
Redirect_by_id stopped working, use https://twitter.com/intent/user?user_id=NNN.
Since this reflects how recently an account has been active, it's likely to be a useful way to sort large lists of blocks.
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.
During deploy this would detect a model mismatch quickly and trigger a rollback.
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)
Right now some errors just leave the connection open with no response.
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.
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?
These are the people I would be most interested in knowing about who they block.
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 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.
Probably delete the user from the BtUsers table. Probably also flush their stored Blocks and Actions.
Right now there are some indexes on the server that I manually added. These should be represented in migrations.
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.
If there are more blocks than can be displayed on a single page, we'd still like to block all of them.
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.
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.
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.
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.