Live data from Hacker News

Reconstructing Twitter's Firehose

docs.google.com

101–110 of 112 posts

Re: Reconstructing Twitter's Firehose

#101
post #56

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?

Same problem as the mobile app for Twitter, they can't block people that are not logged in the mobile app so they don't rate limit them.

Re: Reconstructing Twitter's Firehose

#102
post #78

To 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.

Yikes, you are totally right. Fixed

Re: Reconstructing Twitter's Firehose

#103

Discord 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.

If you remove the trailing forward slash the link works fine.

Re: Reconstructing Twitter's Firehose

#104
post #62
post #14

Earlier 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?

They explicitly want to cripple third-party apps to push users to use their (awful) official clients, and their way of doing so is to enforce unreasonably low limits.

If they were to do the same with their official clients they'd become unusable.

Re: Reconstructing Twitter's Firehose

#105
post #56
post #4

>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.

Just be careful about how much you change it, since you could get banned. You might be able to get away with changing the app ID or version, but even that's risky.

> NEVER lie about your user-agent. This includes spoofing popular browsers and spoofing other bots. We will ban liars with extreme prejudice.

https://github.com/reddit-archive/reddit/wiki/API

Re: Reconstructing Twitter's Firehose

#106

Earlier 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

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.

Re: Reconstructing Twitter's Firehose

#108

Discord 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.

[deleted]

Re: Reconstructing Twitter's Firehose

#109

Earlier 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.

You wouldn't, just showing that it's an easy problem to solve.

Re: Reconstructing Twitter's Firehose

#110
post #101

Earlier quoted context omitted.

How would that work, I couldn't find much on the web?

Same problem as the mobile app for Twitter, they can't block people that are not logged in the mobile app so they don't rate limit them.

How come they can block people on the web again?
Post reply on HN