Closed rougetimelord closed 6 months ago
Yo @cooljeanius and/or @kheina, for your review :)
Before merging, though, I wonder if it'd be better to squash and merge, or to create a merge commit?
I think I decided that edit eligibility wasn't a good metric to determine if someone was a subscriber or not cause it showed regardless, so probably worth double checking that @cooljeanius
also I normally squash and merge
I think I decided that edit eligibility wasn't a good metric to determine if someone was a subscriber or not cause it showed regardless, so probably worth double checking that @cooljeanius
hm, I would like to hear what @rougetimelord has to say...
In my little bit of exploration the edit_control
and edit_control.is_edit_eligible
properties are always there, but is_edit_eligible
is only set to true for accounts with premium. I haven't seen any false positives (i.e. non-premium user who doesn't have it set to true), but I have seen some false negatives.
Idk, it's not a reliable metric to catch every account with a hidden check but it seems to get most of them?
Ok more observations, for premium users is_edit_eligible
seems to remain true even after editable_until_msecs
. But it's true for tweets made by yourself until editable_until_msecs
? And sometimes true for other non-premium accounts before then? But definitely false after for non-premium users. The behavior seems a bit bugged on Twitter's end
The behavior seems a bit bugged on Twitter's end
Hm, so do we wait for them to fix it, or just assume it won't ever get fixed?
Hm, so do we wait for them to fix it, or just assume it won't ever get fixed?
I'm guessing it won't be fixed/the behavior is correct but just looks weird (maybe it's set to true on self tweets to show the edit menu button to push you towards paying up?). I think the best choice is to add a check for self and/or check if editable_until_msec
is in the past.
That should be enough to not cause false positives but it would increase the rate of false negatives further?
Hm, so do we wait for them to fix it, or just assume it won't ever get fixed?
I'm guessing it won't be fixed/the behavior is correct but just looks weird (maybe it's set to true on self tweets to show the edit menu button to push you towards paying up?). I think the best choice is to add a check for self and/or check if
editable_until_msec
is in the past.That should be enough to not cause false positives but it would increase the rate of false negatives further?
well ok, do you want to give it a try and test?
Oof ok I'm abandoning trying to use the edit_control stuff to detect premium. I found a case where the timestamp was in the past and the eligibility was true on a non-premium user, so I'm flummoxed... Going to revert that but leave in the check for expandable tweets since that doesn't have the same problem.
Oof ok I'm abandoning trying to use the edit_control stuff to detect premium. I found a case where the timestamp was in the past and the eligibility was true on a non-premium user, so I'm flummoxed... Going to revert that but leave in the check for expandable tweets since that doesn't have the same problem.
What's the current status on this?
What's the current status on this?
Whoops!! I did some messy reverting but the branch is currently there
What's the current status on this?
Whoops!! I did some messy reverting but the branch is currently there
"there" as in ready for review/squash-merging?
Yup!
Changelog
Deployment Checklist
src/manifest.ts
andpackage.json
have the correct version numbermake chrome
,make firefox
)npm run build
2
to chrome webstore and firefox addons