Earlier quoted context omitted.
You can do the same for the Reddit API, change the agent header and then you have unlimited API calls.
How would that work, I couldn't find much on the web?
Reconstructing Twitter's Firehose
101–110 of 112 posts
Re: Reconstructing Twitter's Firehose
#102To store such a firehose stream of data, you will need approximately 0.3gb of storage per one second of data. This is if you only collect username, timestamp and tweet, excluding any additional metadata such as data center, likes and retweets, not to mention images and videos. Full calculation here: https://docs.google.com/spreadsheets/d/1BIAguT9Qvy0GK-dalpQf...
I believe your calculations are too high by a factor of 1000... 53 bytes/(typical tweet) * 6000 typical tweets/second is 318 KB (or 0.3 MB) per second, not 318 MB.
Re: Reconstructing Twitter's Firehose
#103Discord also utilizes Twitters Snowflake algorithm for the ridiculous amount of messages that are sent in chats.[1] [1] https://discordapp.com/developers/docs/reference/
Link doesn't work for me, I just get a partially-loaded page with an eternally-spinning spinner (FF65 on OSX). Gotta go to https://discordapp.com/developers/docs and then click on the Reference link in the sidebar.
Re: Reconstructing Twitter's Firehose
#104Earlier quoted context omitted.
These are hardcoded in the apps. If they disable a key, they would need to release a new version of the app (ok), and all users would need to update (infeasible).
Wouldn't they just enforce the limit with those keys as well?
If they were to do the same with their official clients they'd become unusable.
Re: Reconstructing Twitter's Firehose
#105>Twitter’s statuses lookup API endpoint allows for a total of 1,200 API calls every 15 minutes. Each call allows the user to pass 100 ids for a total of 120,000 id requests every 15 minutes using both APP auth [...] Use the secret consumer keys from Twitter to bypass these limits: https://gist.github.com/shobotch/5160017
You can do the same for the Reddit API, change the agent header and then you have unlimited API calls.
> NEVER lie about your user-agent. This includes spoofing popular browsers and spoofing other bots. We will ban liars with extreme prejudice.
Re: Reconstructing Twitter's Firehose
#106Earlier quoted context omitted.
They're snowflake IDs, not exactly sequential. Timestamp bits, shifted all the way left Data center id shifted left Server id shifted left Increment this millisecond Since the left bits are the timestamp, they are date/time sortable and a much more useful index/primary key/whatever than a UUID.
You can prefix the uuid with a timestamp for the same effect without leakage. There are chronological uuid projects: https://github.com/uucid-project/spec
UInt64's are going to be all around more efficient.
Re: Reconstructing Twitter's Firehose
#107Re: Reconstructing Twitter's Firehose
#108Discord also utilizes Twitters Snowflake algorithm for the ridiculous amount of messages that are sent in chats.[1] [1] https://discordapp.com/developers/docs/reference/
Link doesn't work for me, I just get a partially-loaded page with an eternally-spinning spinner (FF65 on OSX). Gotta go to https://discordapp.com/developers/docs and then click on the Reference link in the sidebar.
Re: Reconstructing Twitter's Firehose
#109Earlier quoted context omitted.
You can prefix the uuid with a timestamp for the same effect without leakage. There are chronological uuid projects: https://github.com/uucid-project/spec
You can , but why would you? You're advocating slapping lipstick on a pig not really engineered for this use case vs. using something that was designed for it. UInt64's are going to be all around more efficient.