Hackers Are So Fed Up with Twitter Bots They're Hunting Them Down Themselves - <AUTHOR> https://theintercept.com/2018/03/16/twitter-bot-detector-software/ <comment><USER2> I got fed up with Twitter's lack of enthusiasm in blocking these accounts so I whipped up a quick proof of concept a while ago. The amount of trivial-to- detect cryptocurrency scams in replies to popular accounts was so high that I put together a hacky PoC: [https://gist.github.com/lorenzhs/864353c202112a38de17ed054f3...](https://gist.github.com/lorenzhs/864353c202112a38de17ed054f31e67c) \-- the scammers' messages have changed now, the messages no longer match that particular filter, but it worked for _weeks_ without Twitter doing anything.

<comment><USER3> I got fed up with Twitter's lack of enthusiasm in blocking all sorts of shitposts that I stopped using it. I've been significantly less angry ever since...

<comment><USER4> Honest question: what's the point of twitter?

<comment><USER5> I tried to make Twitter work for me by only following people I am genuinely interested in. (Founders, CEO's, etc) but even after that I am not engaged.

<comment><USER6> Same, my feed was still filled with inane posts no matter how much I tried to mess with it.

I just gave up.

<comment><USER7> Embrace the banality.

<comment><USER6> [https://www.youtube.com/watch?v=Xd2OmVTKkbY](https://www.youtube.com/watch?v=Xd2OmVTKkbY)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The profile of fake porn accounts the guy in the first part of the story developed is that they "liked more tweets than they retweeted, had fewer than 1,000 followers, and directed readers to click the link in their bios."

If that is the only criteria he's using, many legitimate accounts will be falsely accused.

<comment><USER9> I'm a total Twitter n00b.

But are we really supposed to retweet more than we like? I was treating retweets as a stronger version of 'like', in a sense. Assuming too much retweeting will clog my followers' feeds, and make them more likely to mute or unfollow me.

So yeah, I like far more than I retweet. I also have well less than 1000 followers, being a n00b.

I DO have a link in my profile, but don't actively request people visit. But figure they eventually might (I do much tweeting within the aspiring author community, mentioning my WIP, or Work In Progress, so figure potentially- interested parties could click. But no, not actively marketing, yet...)

<comment><USER10> > Assuming too much retweeting will clog my followers' feeds, and make them > more likely to mute or unfollow me.

If there's one thing I've learned about social media, it's that this totally considerate, natural thought pattern is anathema to the platform vendors.

In the real world, you expect a high Signal-to-Noise ratio, and want to reward people who speak less often because their words become more weighty/significant. Social platforms work on the exact inverse of this principle! They reward high Noise-to-Signal accounts because that keeps the psychological engagement hooks going. The platforms _actively punish_ accounts that aren't continuously, repetitively pushing those buttons. If you ever wonder why the spammiest crap floats to the top, this is why.

We're all just flashing bulbs in the social media slot machine. If we're not frantically flashing, blinking, or otherwise making it difficult for the consumer-gambler to look away, we're not serving the platform's purpose, and we'll be replaced with a bulb that does.

</comment></comment></comment><comment><USER11> This whole problem could be solved by opening account verification up to everyone. Twitter would be amazing if every profile were guaranteed to be a verified human being with government issued ID. Leave it open to those who want to stay anonymous, but give users the option to filter those people out.

<comment><USER12> I refuse to create accounts on site that require even a phone number, let alone government ID. It will eventually get lost and things like passports being faked can land you in prison or watchlists if someone like Israel decides to steal your identity while committing an extra-legal assassination.

<comment><USER13> Perfectly sane reason for not signing up with Twitter.

<comment><USER14> I want to downvote the person you replied to and upvote your comment. HN apparently doesn't work like that so I'll stick with a single upvote :)

<comment><USER15> Once you get enough karma you can downvote comments.

<comment> qu4z-2 But the delay is specifically so you can internalise the fact that downvoting here is a stronger claim than on, say, reddit.

</comment></comment></comment></comment></comment></comment><comment><USER16> Forgive me, as I don't use twitter much, but what is the problem with twitter bots? If I don't follow them, aren't they essentially invisible to me?

I guess they might pollute search results? Is there something else I'm missing?

<comment><USER17> If you follow any billionaires and read their comments they are full of crypto scams.

Things like @elommusk replying to @elonmusk saying "to celebrate this awesome news I'm going to hand out some free bitcoins!, just send 0.1BTC to <address> and i'll return 1BTC!" then 100 replies from other accounts saying "thanks Elon, you're the greatest!"

<comment><USER18> And if you check the address, you can often see thousands of dollars scammed.

Not as lucrative as it seemed to be the first time I noticed them a month ago where a Coinbase tweet had a spam response with an address that made 80k USD in <1 hour, but it's still clearly lucrative.

This is going to force Twitter to finally do something about all the bots since they'll have to deploy countermeasures that generalize across pretty much all bots.

It's clear that Twitter has held a Laissez-faire or blind-eye philosophy towards bots, but it's hard to keep procrastinating once you can trivially verify that your platform is a lucrative tool for scammers.

Not to mention, the top N responses to every high profile tweet are now these scammers and it makes their platform look absolutely uncontrolled.

<comment><USER19> > And if you check the address, you can often see thousands of dollars > scammed.

Just like the fake "Thanks!" replies, I'm sure there are fake actual transactions, meaning the scammer sends bitcoin to itself to make it look legit. The fact that they pay transactions fees doesn't really change much.

So it's very hard to know how much of those thousands of dollars were actually scammed.

<comment><USER20> They don't bother, it's not worth trying to target people who actually check things. The scam tweet usually links to what amounts to a phishing page for crypto transaction tracking sites. It looks very real.

</comment></comment></comment></comment></comment><comment><USER21> This is an interesting approach. Maybe Twitter shouldn't solve the fake accounts problem directly, maybe they should come up with an evaluation criteria and then create a market for identifying fake accounts.

If their evaluation criteria is good, they could get away with 0 cost to build the best possible system (motivated by competition on a market).

<comment><USER22> I think Twitter's biggest problem with fake accounts is not that they are hard to identify, but that if they do identify them and shut them down, it'll hurt their "number of active users" stats

<comment><USER23> I suspect their big problem is more that their site is too big for the moderation staff they have at the moment. Identifying bots is easy for people sure, but it's hard to automate with AI and hiring people to proactively hunt out and shut down bots is expensive.

Of course, the fact doing it too well hurts the stats doesn't help either.

<comment><USER24> > it's hard to automate with AI

I disagree. At least it shouldn't be that hard for a company with Twitter's level of engineering and data science sophistication, and yes, I do realize that most of their best technical talent is long gone.

</comment></comment></comment></comment><comment><USER25> > ("jakten" means "hunt" in Norwegian)

I don't mind the confusion, it's just a fact that we can use knowledge of Norwegian to understand Swedish.

Fun fact, same word as yacht, which is borrowed from dutch jacht with the same meaning as Swedish and Norwegian jakt.

<comment><USER26> Is it just a coincidence that jakten means both hunt and yacht in Norge? (I think I unpicked that chain correctly)

Also, now I come to think about it, it is a bit embarrassing that we (en) pronounce yacht as "yot". I look forward to reading a future man page describing yacht as an archaic form of the correct usage. The man page for the ls command used to describe colour as an archaic term for the "modern" form - color!

<comment><USER27> Wiktionary says that yacht stems from the Dutch word for a hunting ship (one you use to pursue other ships), so various Germanic languages having similar or identical pronunciations for the words for yacht and hunt is no coincidence.

[https://en.m.wiktionary.org/wiki/yacht#English](https://en.m.wiktionary.org/wiki/yacht#English)

</comment></comment></comment><comment><USER28> I tried to start a twitter account, a few minutes later I got blocked: [https://imgur.com/suSH1Qn](https://imgur.com/suSH1Qn)

I didn't tweet anything, just followed some people I found interesting.

I don't want to verify my phone number. Fuck you twitter.

<comment><USER29> I haven't been able to create a Twitter account for over a year now. Home IP.

(Not giving Twitter my phone number)

I think it's deliberate b/c bots seem to be exempt from this phone number requirement.

<comment><USER28> Yeah exactly, is registering an account really automated behavior? It's so obvious they just want my phone number and they are never getting it.

Twitter is dying anyway, at least that is the feeling I have about the website.

</comment></comment></comment><comment><USER30> In the early days of twitter, Trust&Safety was considered the second-lowest team on the totem pole of engineering career advancement possibilities (sorry Internal Tools aka Developer Productivity).

I'm sure that's changed recently, but IMO a lot of the trouble that Twitter/FB/Reddit have had with bots has to do with trying to get good engineers rationally interested in being part of T&S organizations.

Now T&S is sexy, but there's got to be lag time effectively changing the leadership and team structures of these large, established teams.

</comment><comment><USER31> Isn't this self defeating? As everyone has pointed out, it's not hard to detect a bot. So, why can't Twitter just do it? Maybe their review and moderation team is just too backed up. In that case, instead of helping the twitter team, these detection bots, are probably making it worse. Reviews and considerations have to be more thorough, since most of the reports are from automated systems. Systems, they probably have already engineered.

I built a chrome plugin that filtered out Facebook posts by a set of keywords. It took less than an hour. Maybe these "hackers" should do it for Twitter. It would reduce the load on the moderators, while making these bots far less effective. Then, reach out to the Twitter team, and see if there's a way to go about this, that isn't destructive.

<comment><USER32> > _it 's not hard to detect a bot. So, why can't Twitter just do it?_

Presumably a significant part of that is that Twitter cares more about false positives than random third parties do; they're going to get some vicious criticism if they start flagging/closing real accounts as bots. They might also worry more about false negatives, because as soon as they act on bots they'll be accused of bias and only targeting certain positions. (That accusation will hit regardless, but presumably they'd like it to not be _true_.)

It's easy to whip up a tool that gets lots of true positives, but much harder to get a success rate good enough to use.

</comment></comment><comment><USER33> A related discussion from a couple days ago is [https://news.ycombinator.com/item?id=16599802](https://news.ycombinator.com/item?id=16599802).

</comment><comment><USER34> I just hope something similar to a follow graph/follow range comes up as a solution. It gives _way_ more control to individuals to limit the reach of bad actors.

For example: [https://ssbc.github.io/scuttlebutt-protocol-guide/#follow- gr...](https://ssbc.github.io/scuttlebutt-protocol-guide/#follow-graph)

</comment><comment><USER35> As I told @fs0c131y (cited in the article), they're very easy to find. My bot found many of them without even looking: [https://anisse.astier.eu/what-do- you-find-when-you-search-tw...](https://anisse.astier.eu/what-do-you-find- when-you-search-twitter-for-hashes.html)

</comment><comment><USER36> I frankly don't use twitter much anyway... I mostly post things that I like, and in the end use my own account to re-find stuff I posted later... it's a bad bookmark manager is how I use it, but at least then other people might find it useful to.

</comment><comment><USER37> Hey I run a bot and people love it. It adds value and regularlt triggers conversation. All bots are not about porn and mixtapes!

<comment><USER38> This whole bot thing is turning into a classic hysteria.

I really hope it doesn't end up harming a bunch of the 'good guys' like most of the quickly assembled shoddy 'solutions' most public hysterias generate, rather than stopping the legit 'bad guys'.

There have been countless examples of well-intentioned but heavy-handed intervention being a net-negative for society [1].

There could very well be some really interesting legitimately useful bots that will get swept up in this. Or platform limitations added which cripple the utility of all bots...with some an unmeasurable potential loss via future bots which were never created as a result. ....Meanwhile the 'bad guys' find a hundred loop holes to keep operating.

The key is keeping this to a case-by-case enforcement...whether at an individual or specific use-case based level. Not some overarching limitation or stigmatization of bots (across all social media).

[1] See: the drug war, 1970s NYC/Toronto rent control laws resulting in a far _lower_ supply of affordable housing and more dilapidated tenements, anti-oil pipeline activism resulting in more environmental harm via rail and truck transit, pro-poverty housing regulation creating isolated urban ghettos, wage laws reducing total long-term net income for all low-income workers than it gains employed workers in the short term, etc, etc.

</comment></comment><comment><USER39> I'm not sure I understand the point. So they identify bots. Then what? How can one get rid of these accounts?

<comment><USER40> They report them. And then nothing happens because its in the interest of Twitter's business to not do anything about it.

To be fair, I'm sure some will be blocked but the problem with Twitter bots is that the only way to get rid of the problem is to ignore false positives. That will fix the issue but replace it with a different problem, as it clearly won't make for happy users.

I've been using Mastodon quite heavily recently and the "ban first" approach is taken by many instances. They can do that since the network is decentralised. Twitter, on the other hand can't do the same thing.

</comment></comment><comment><USER41> Hypocritical news from twitter.

</comment><comment><USER42> LOUD NOISES

What's with the all-caps title? Did they spit it out from the server using ToUpperCase instead of using CSS text-transform?

<comment><USER33> No, it's that some article titles use all-caps typography and then HN users copy it.

We're going to write a bit of software to convert these, or at least ask submitters to revise them. In the meantime we've edited the title above.

<comment><USER43> It's frustrating that the site markup is (almost) correct[1], because IMO the browser is in the wrong here. I think it makes more sense for the browser to copy the text as it is in the markup, because all-caps is a stylistic choice not a content choice.

I can see the argument the other way around, where the text the user selects should be the text they copy, and that makes sense. But I maintain that the same article with different stylesheets should produce the same text content on the page for the user to copy.

[1]: The markup is in something approaching title case, except that words like `with` are also capitalized. Then the element is using `text-transform: uppercase`.

<comment><USER44> > I can see the argument the other way around, where the text the user selects > should be the text they copy

This is almost never the case for headers and such. New York Times or CNN have fancy logos/headlines, but we don't want to reproduce them each time we refer to the company or specific article - we just want the content. text-transform is a great way to achieve presentation need (bold headlines) without messing up content. Copying - excepting cases of visual copying, e.g. screenshot - should always have an option of content-only copying.

</comment></comment></comment></comment><comment><USER45> The obvious answer is to restrict some API usage, specifically posting, to verified accounts.

This obviously conflicts with Twitter's incentive to maximize their profit and brand. So the next obvious solutions are token measures.

edit: And apparently to downvote anyone who calls them out.

</comment><comment><USER46> > finding these accounts is pretty easy, he used advanced google search and > google reverse image search

All Twitter has to do is develop the most intelligent software ever created and make sure it keeps inching towards generalized AI over time.

<comment><USER47> FWIW I read gp as "_use_ Google", not "_be_ Google".

<comment><USER46> That's why the piece is cute, it presents some personal fiddling as a possible solution. Twitter can't simply use a competitor's technology at scale, and if they did they would be opening a massive risk vector to their core business. The only takeaway is that Twitter has to replicate the most intelligent "ai" in the world.

</comment></comment></comment><comment><USER48> A real hacker move would be to just leave Twitter and go to Mastodon [https://joinmastodon.org](https://joinmastodon.org)

<comment><USER49> Are you suggesting that Mastodon has a better system for identifying harassment, spam, and spam accounts? Or that, given that they're mostly friendly early adopters, they haven't yet encountered the problem?

<comment><USER50> It seems to me like you don't understand the crucial difference between Twitter and Mastodon.

There's no such thing as Mastodon, a singular social network. Mastodon is a series of instances that talk to each other. A sysadmin running the instance can do whatever he pleases in his instance, including closing the registration, banning entire instances from communicating with his instance, and enforcing whichever rules he wants to enforce.

Mastodon doesn't deal with such issues at all. It's sysadmins running Mastodon instances that are supposed to deal with such issues.

It's more like reddit, where mods of subreddits have nearly complete authority over their own space on the social network, than it is like Twitter, in which a single entity is in charge.

<comment><USER51> You mean like how we defederate email servers that have lots of spammers but also lots of legitimate users.

Oh wait no we don't.</comment></comment></comment></comment>


New polymer £5 note released in the UK today - <AUTHOR> http://www.thenewfiver.co.uk/ <comment><USER2> Make money out of oil, what could go wrong?

 _Polymer notes are also better for the environment. This is because they last longer and so we have to print fewer notes, which means less energy is used in manufacturing and cash transportation. When a polymer note has reached the end of its life it will be recycled into new plastic products._

Oh yes, I'm sure the manufacturing of plastic is much more environmentally friendly than paper, and the yield of recycling plastic is much higher and more efficient than recycling paper.

</comment><comment><USER3> Something interesting that doesn't happen in the USA when updated currency is introduced:

 _In May 2017 paper £5 notes will cease to be legal tender and will no longer be accepted by shops._</comment>


Here's the PDF I used to stop 100% of my student loan payments - <AUTHOR> http://www.collegetimes.tv/student-loan-payments/

<comment><AUTHOR> More info about IBR: [http://ibrinfo.org/](http://ibrinfo.org/)</comment>


Microsoft Supercharges Bing Search With Programmable Chips - <AUTHOR> http://www.wired.com/2014/06/microsoft-fpga/ <comment><USER2> This has been going on in the HFT space for a number of years. FPGA's are used to parse data feeds as the sheer volume of quotes overwhelms most systems.

In fact after moving the networking stack into user land and using inifiniband networking gear, its probably the third most common optimization I've seen/heard of for HFT systems.

Here's a quick, but surprisingly accurate description of a common HFT setup: [http://www.forbes.com/sites/quora/2014/01/07/what-is-the- tec...](http://www.forbes.com/sites/quora/2014/01/07/what-is-the-technology- stack-like-behind-a-high-frequency-trading-platform/)

Some one had asked about hte number of quotes that need to be parsed. From forbes...

> Mr. Hunsader: The new world is now a war between machines. For some > perspective, in 1999 at the height of the tech craze, there were about 1,000 > quotes per second crossing the tape. Fast forward to 2013 and that number > has risen exponentially to 2,000,000 per second.

Keep in mind that the "tape" is the slow SIP line that exchanges use to keep prices in sync and show customers that don't use the exchanges direct feeds. ie it aggregates all the quotes from all venues and throws a way alot as they can't be parsed in time or didn't change the top level quote.

With 40+ venues at which a HFT fund can get feeds from 2,000,000 second is a fraction of what a cutting edge HFT would have to parse to keep up with all venues.

The typical setup is that you'll run strategies across multiple machines so you have the gateway machine that directs the quote to the appropriate machine. The biggest problem is the speed at which the quotes arrive.

Unlike a web request, that you can take 300 milliseconds to parse and return, if you don't parse and respond to the quote in under 10-20 micro seconds you've already lost.

So the FPGA transition is to make sure there is never a back log of quotes or any pauses in the handling of bursty quotes. This can't be overstated enough. Margins are squeezed so tightly now that your algo will appear to be working fine until a big burst of quotes happen and your machines can't keep up and when the dust settles in 20 seconds, you'll find you lost $5000, which might be your entire day's profit from that one symbol/algo pair.

<comment><USER3> I'm curious if these kinds of setups are also used in other high-freq scenarios.

For instance, I could imagine using techniques like userland network stack and reserving cores exclusively in services like WhatsApp. I think they're currently on a highly customized Erlang stack and are able to handle huge numbers of queries per machine. Any insiders here with a good background story?

<comment><USER4> You imagine correctly :)

I work in finance and have for the past 6.5ish years in electronic trading.

</comment></comment></comment><comment><USER5> Is there any breakthrough in programming these things? From a quick glance at the paper it seem like the kernels are still hand written in Verilog. Though there seem to be some significant software infrastructure in integrating the FPGAs into cluster management systems.

I think easily and uniformly programming disparate compute devices (CPUs, SIMD, GPUs, FPGAs, ISPs, DSPs, and eventually quantum) is the next BIG problem in programming languages. Several Haskell projects seem promising, but these still tend to be nice DSLs that generate verilog or shaders.

On most mobile SoCs the CPU usually takes an increasingly smaller part of the die; there are 10gbe network cards with FPGAs on them; and we've got parrella. The hardware exists, we sorely need the next breakthrough programming environment.

<comment><USER6> CPUs, GPUs, DSPs, FPGAs... they are so different, it's hard to say they ever _could_ be programmed uniformly.

<comment><USER7> I think they could - in fact I'm starting a PhD in a similar area soon! It's a matter of providing a high level enough programming language (e.g. Haskell) and a smart enough compiler that can automatically parallelise sections, and with the right middleware/compiler back end it should be possible!

<comment><USER6> I buy CPU+GPU unification (in fact I highly anticipate it) and I also buy that a DSP could function as a dynamic coprocessor, as they are often programmed in C.

But my day job revolves around HDLs, and it is my opinion that a higher level language isn't the answer. Fifty years from now it might be, but state-of-the- art HDL compilers just aren't good enough yet. It's like C compilers a few decades ago, where you had to insert some inline ASM in your code here and there because the compilers were still developing.

So I guess what I'm saying is you can't target CPU, GPU, DSP, & FPGA in one compiler until we can master targeting FPGA even just by itself.

<comment><USER8> To make a comparison for anyone who hasn't programmed FPGAs (especially on the path to etching silicon), placement is extraordinarily important. Not only can (will) you make a highly non-optimal layout, FPGAs are not orthogonal. You'll spend a lot of time trying to route the bits that need to talk to each other via direct connection as much as possible instead of going through a gp line or worse.

Depending on the make and model of FPGA, you will have "large" areas that you either can't or don't want to plop logic.

You can have a pretty netlist that validates and simulates correctly (although you'll eventually end up dealing with Cadence, who seem to have the right hand side of the bugs per line of code curve locked up) but still takes weeks or months of that inline ASM work to make it competitive with a rack of Xeons. The edit/compile/debug cycle is not quick by any means past a trivial number of gates.

Dealing with that junk is why IP blocks are so attractive, but you end up on the road to structured ASICs and that just leads to misery.

</comment></comment></comment></comment></comment><comment><AUTHOR> [http://research.microsoft.com/apps/pubs/default.aspx?id=2120...](http://research.microsoft.com/apps/pubs/default.aspx?id=212001)

</comment><comment><USER9> I'd rather have _better_ results than _faster_ results. Faster is only important once you have the quality problem worked out, first make it good and then make it fast has been a long time mantra. The reason is that it is usually very expensive to make something really fast because optimizing code is hard and expensive (case in point they use custom hardware here).

The upside is that they're doing something innovative but if Bing really wants to steal marketshare from Google they have to improve on their quality, not on their speed. I'd rather see them take 10 seconds and deliver an absolutely perfect answer than 0.001 second and deliver something not on par with Google but 10 times faster.

Impressive to see them backing an exotic solution like this though, and if and when they _do_ get it to be better than Google it may pay off.

Are there any developments like this underway at Google?

<comment><USER10> There was no mention of where exactly these would go. I doubt it would be on machines serving response online ... since the bottle neck is often in IO.

Being able to index, process and learn data faster can lead to faster iteration and improve the speed of batch or offline jobs which in turn could improve the relevance.

<comment><USER9> > There was no mention of where exactly these would go.

From the article:

"The system takes search queries coming from Bing and offloads a lot of the work to the FPGAs, which are custom-programmed for the heavy computational work needed to figure out which webpages results should be displayed in which order. "

That looks like they're in the interactive path somewhere.

</comment></comment></comment><comment><USER11> Actually, I already find bing quite fast. Comparing to google search, bing results tend to load a little faster but to be a little lower in quality.

FPGAs may make bing twice as fast as it already is, but I don't feel like it needs to be faster. Although, I guess if its faster they can trade that off for more work done and so better results, perhaps.

<comment><AUTHOR> If they make Bing 2X faster, then they can roughly cut the amount of servers they need by half. They measure "speed" by number of requests that can be fulfilled in Z amount of time.

</comment></comment><comment><USER12> Sounds like there is a market niche starting to develop for FPGA in server applications. I'm not saying rush out and make PCIe powered and communicating FPGA's I'm just saying there maybe a market developing for it.

Especially with good open source dev tools.

<comment><USER6> I think you would just about have to start from square one if you want an open source FPGA toolchain. I don't believe such a toolchain exists _at all_ right now.

So what I'm saying is, forget about developing a PCI-e FPGA board. If you want an open source toolchain for it, you better start there, because that's going to be 99.9% of the effort.

</comment></comment><comment><USER13> Seems like I read about Google doing this almost 10 years ago. I know that IBM has the Netezza product which also uses FPGAs for accelerating queries.

</comment><comment><USER14> I've been ranting about the inadequacies of mainstream processors for almost twenty years. I remember even back in the late 90s, seeing processors that were 3/4 cache memory, with barely any transistors used for logic. It's surely worse than that now, with the vast majority of logic gates on chips just sitting around idle. To put it in perspective, a typical chip today has close to a billion transistors (the Intel Core i7 has 731 million):

[https://en.wikipedia.org/wiki/Transistor_count](https://en.wikipedia.org/wiki/Transistor_count)

A bare minimum CPU that can do at least one operation per clock cycle probably has between 100,000 (SPARC) and 1 million (the PowerPC 602) transistors and runs at 1 watt. So chips today have 1,000 or 10,000 that number of transistors, but do they run that much faster? No of course not.

And we can even take that a step further, because those chips suffered from the same inefficiencies that hinder processors today. A full adder takes 28 (yes, twenty eight) transistors. Could we build an ALU that did one simple operation per clock cycle with 1000 transistors? 10,000? How many of those could we fit on a billion transistor chip?

Modern CPUs are so many orders of magnitude slower than they could be with a parallel architecture that I'm amazed data centers even use them. GPUs are sort of going the FPGA route with 512 cores or more, but they are still a couple of orders of magnitude less powerful than they could be. And their proprietary/closed nature will someday relegate them to history, even with OpenCL/CUDA because it frankly sucks to do any real programming when all you have at your disposal is DSP concepts.

I really want an open source billion transistor FPGA running at 1 GHz that doesn't hold my hand with a bunch of proprietary middleware, so that I can program it in a parallel language like Go or MATLAB (Octave). There would be some difficulties with things like interconnect but that's what things like map reduce are for, to do computation in place rather than transferring data needlessly. Also with diffs or other hash-based algorithms, only portions of data would need to be sent. And it's time to let go of VHDL/Verilog because it's one level too low. We really need a language above them that lets us wire up basic logic without fear of the chip burning up.

And don't forget the most important part of all: since the chip is reprogrammable, cores can be multi-purpose, so they store their configuration as code instead of hardwired gates. A few hundred gates can reconfigure themselves on the fly to be ALUs, FPUs, anything really. So instead of wasting vast swaths of the chips for something stupid like cache, it can go to storage for logic layouts.

What would I use a chip like this for? Oh I don't know, AI, physics simulations, formula discovery, protein folding, basically all of the problems that current single threaded architectures can't touch in a cost-effective manor. The right architecture would bring computing power we don't expect to see for 50 years to right now. I have a dream of someday being able to run genetic algorithms that take hours to complete in a millisecond, and being able to guide the computer rather than program it directly. That was sort of the promise with quantum computing but I think FPGAs are more feasible.

<comment><USER9> > I really want an open source billion transistor FPGA running at 1 GHz that > doesn't hold my hand with a bunch of proprietary middleware, so that I can > program it in a parallel language like Go or MATLAB (Octave).

I fail to see how not having proprietary middleware will enable you to program an FPGA in Go or MATLAB.

FPGA's are not well suited to being programmed in conventional languages (and go is not a parallel language, it employs a clever model that may give you that impression but under the hood it is fairly regular, nothing you could not achieve using co-routines and threads in a different language, maybe syntactically cleaner and easier to understand). MATLAB might be more feasible but still not an easy match. You could conceivably make an FPGA co-processor though that you access from those languages through some library.

If you want to program an FPGA in something that _looks_ like a high level language syntactically there are a number of solutions:

[http://stackoverflow.com/questions/5603285/c-to-hardware- com...](http://stackoverflow.com/questions/5603285/c-to-hardware-compiler-hll- synthesis)

And some newer developments. But none of those change the essence of the chip.

I'm not sure how to convey the difference between an FPGA and something like a high level language any better than 'imagine all your code executing at once'.

FPGAs are something you tell what to be, not what to do (and high level languages tell CPUs what to do, not what to be).

<comment><USER15> Yeah, this rant makes me wonder if poster actually understands how these things work in deep detail.

<comment><USER14> I used VHDL for a semester back in 98 or 99 for my ECE degree. I remember it being extraordinarily brittle compared to something like C, because there were so many ways to trigger unreliability with the wrong clock edges etc. So for example we did almost everything as state machines instead of math. The code was basically unmaintainable by today's standards but was an important learning tool. As I recall, we wrote a VGA signal generator, and if you had less than half a dozen incorrect pixels onscreen, you were doing pretty well. So in fairness, I USED to know this stuff in nauseating detail.

<comment><USER15> Yes, this is because VHDL is not code. It's a different paradigm entirely. The FPGA doesn't "run" the VHDL, etc.

The units in an FPGA are just a little bit of logic with a bunch of connectivity to local busses.

I haven't done much VHDL lately (ECE '96 here) but I do remember how the stuff works. But then again I focused mainly on CPU architecture.

</comment></comment></comment></comment></comment><comment><AUTHOR> [http://www.theregister.co.uk/2014/06/16/microsoft_catapult_f...](http://www.theregister.co.uk/2014/06/16/microsoft_catapult_fpgas/)

</comment><comment><USER16> This is cool and all, but instead of spending money on this project why not try to improve their search engine or just not spend this money since bing loses so much money. I don't mind waiting half a second extra for my search results. It seems more like their thinking is we got a lot of engineers we are paying a bunch of money to lets do some project.

<comment><USER17> This move saves money, since the servers process queries more efficiently-- "Right off the bat we can chop the number of servers that we use in half," Burger says.

"Just improving their search engine" isn't some simple task. Google has a head-start measured in thousands of man-years. Closing that gap takes a great number of smart people a great amount of time.

I assume that Google is improving slower than Bing, since their algorithms and systems are more mature and closer to the "asymptotically ideal search engine".</comment></comment>


Andrew Chen: Has the Facebook platform hit its peak? - <AUTHOR> http://andrewchen.typepad.com/andrew_chens_blog/2008/05/has-the-faceboo.html

<comment><USER2> is it necessary to put your name before every post? we can all see the link with your name in it

<comment><USER3> it's a subtle and effective form of marketing. I don't have a problem with it.

<comment><USER4> I do. If you want to make your name, write or do something great. Broadcasting your own name suggests that there isn't enough substance to speak for itself. This strategy only works (if it does) until people realize you're doing it, at which point they lose respect for you. That doesn't seem like subtle or effective marketing to me.

<comment><USER5> Yup. This reminds me of when Microsoft decided to copy Apple's "Designed by Apple in California" packaging label with an uglier kitschy copy: "Hello from Seattle". <http://www.joelonsoftware.com/items/2007/10/05.html> This unknown name broadcasting is the equivalent of having to wear off-brand clothing labels. When I was a kid and wanted Nike stuff but my parents could only afford some store brand, I'd rather not have had the label than the dumb Nike- wannabe logo that was on the shirt. Putting the off-brand label just made everything cheesy even if the shirt itself was of similar quality to the real deal.

</comment></comment></comment></comment><comment><USER6> Trevor: I hope it has hit it's peak.

</comment><comment><USER7> facebook is the new facebook:)</comment>


Are journalisms start-ups being appropriately funded? - <AUTHOR> http://charman-anderson.com/2010/10/13/are-journalisms-start-ups-being-appropriately-funded

<comment><USER2> Good piece, but the Knight Foundation is offering relatively huge investments to teams that can, generally, provide most or all of their funding for a year, with very few strings attached. The open source string is a very major one, but I think it also offers a great reminder of one fundamental media truth:

 _Technology will not save you._

Look at the newsy startups recently profiled, like Swivel and Verifiable: <http://news.ycombinator.com/item?id=1788264> <http://news.ycombinator.com/item?id=1786982>

Both bet big on proprietary newsy technology, and both busted out. Meanwhile, what does TechCrunch use? Nobody cares. CrunchBase is their proprietary technology, and while I think it is a really cool asset, it probably drives very, very little of their value.

Look at WordPress, which is now driving some huge percentage of the world's media, both mainstream and particularly user-generated. They open sourced and gave away all their valuable assets, but their commercial side is very profitable.

Same can be said for TechMeme to an extent, where the technology isn't so much the value as the people driving it, and that's an aggregator, where personalities aren't supposed to have as much a part of play.

With Knight Foundation, you're given a huge experimental bucket of money and a year's head start to innovate with it. By the end of that year, if you lose because you open source, you probably would've lost with a proprietary product, too.</comment>


Show HN: Vulners.com, new vulnerability aggregator database - <AUTHOR> Hi! One day, working with CVE-Details database I mentioned, that it's damn slow and has no lucene-style search. Using google is actually good...but takes too long to find security stuff.
So..The idea was quite easy - to build my own vulnerability database with google-style search and a lot of sources. Here it is - https://vulners.com It's not just about CVE and security bulletins. It holds information about HackerOne bug bounty programs, hacker forums, vendor bulletins, different exploits databases, metasploit modules and so on.
The most powerful feature is built-in dorks)
Like this: All public Yahoo vulnerabilities:
https://vulners.com/search?query=type:hackerone%20team.name:yahoo
Or maybe SQL injections?:
https://vulners.com/search?query=type:hackerone%20sql%20injection
For linux users... Vulnerabilities in SUSE:
https://vulners.com/search?query=type:suse
Or some exploits for Windows 10:
https://vulners.com/search?query=type:exploitdb%20%22windows%2010%22
Even take a look for info at the hackers forums, some articles by d0znpp?:
https://vulners.com/search?query=type:rdot%20d0znpp
Lets search for Metasploit modules for Apache:
https://vulners.com/search?query=type:metasploit%20apache
Quite easy, yes? And damn fast :) It is absolutely freeware, written with Python, Elasticsearch and MongoDB. Daily updates and upcoming 2.0 version :) Hope, you will like it. Any contacts and feature requests: email@example.com <comment><USER2> This might make a good "Show HN".

Guidelines for Show HN: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Oh,thanks :) Done

<comment><USER3> You can also put a direct link to your website

<comment><AUTHOR> Looks like it too late to edit submission</comment></comment></comment></comment>


Tanenbaum-Linus Torvalds  Debate: Part II - <AUTHOR> http://www.cs.vu.nl/~ast/reliable-os/

<comment><USER2> If anyone is wondering how practical Minix 3 is for daily use, consider that "Currently, only text-mode browsers are supported under MINIX 3."

<http://wiki.minix3.org/en/UsersGuide/WebBrowsers>

</comment><comment><AUTHOR> Open Sources: Voices from the Open Source Revolution, The Tanenbaum-Torvalds Debate: <http://oreilly.com/catalog/opensources/book/appa.html></comment>


IPv6 non-alternatives: DJB's article, 13 years later - <AUTHOR> https://blog.sesse.net/blog/tech/2016-01-06-20-54_ipv6_non_alternatives_djbs_article_13_years_later.html <comment><USER3> > you still need to upgrade all software on the planet and all routers on the > planet.

No, you don't. The biggest benefit to using IPv4 as the routing-infrastructure and extra bits (maybe an IP option) to describe the host is that most of the Internet (routers, etc) don't need to get upgraded, only hosts. Routers don't normally mess with the packets so only the first/last wifi/switch actually need upgrading. This is a small number of devices (certainly much smaller than all!).

There could be a few routers that lose the option, and one option is to just fix _those_ routers (still a much smaller number than _all_ routers), but another option is to rely on connection tracking only when the service is behind such a router. The ubiquity of UPNP suggests this path would have worked just fine.

NAT gives us a 32-bit port number pair, which requires memory, makes denial- of-service attacks easier, and is complicated. An IP option means that the hosts track the connection themselves.

Another option would be to move port numbers into DNS. This might've been simple (48-bit addresses are pretty big), and only affected new services. We upgraded all of the webservers and web browsers faster than IPv6 deployed, so this probably would have just been a simple matter of mothballing IANA.

However, I worry we're not actually arguing about what we think someone a decade (or two) ago thought could be the direction to talk about solving a problem.

IPv6 is the biggest deploy attempted on the Internet, and it's been miserable. We should be talking about its failings, its mistakes, and how we could do better knowing what we learned, not patting ourselves on the back for doing the best we could've done knowing what we knew. IPv6 might be inevitable at this point, but that doesn't mean it was right.

<comment><USER4> > No, you don't. The biggest benefit to using IPv4 as the routing- > infrastructure and extra bits (maybe an IP option) to describe the host is > that most of the Internet (routers, etc) don't need to get upgraded, only > hosts. Routers don't normally mess with the packets so only the first/last > wifi/switch actually need upgrading. This is a small number of devices > (certainly much smaller than all!).

That's the "BangIP" option discussed in the second half of the article and has all the problems discussed there (e.g. it makes multihoming more-or-less impossible)

<comment><USER3> Multihoming (PI) isn't impossible but it certainly requires more work. I'm not yet convinced to throw the baby out with the bath water.

Multihoming is also not the normal case: for a long time ARIN refused to make IPv6 PI allocations to existing IPv4 PI.

</comment></comment></comment><comment><USER5> I for one think the more incompatible V4 and V6 are the better! There are only two things that ever made any sense: 1) try as hard as possible to be fully inter-operable with each other, or 2) full clean break. Clearly, there was never a 100% consensus on the goal. As is now, I see it as a chance to start over with so many silly things (ie, 12 layers of NAT for everything in the cloud). When you look at all the gripping about problems, it's so much of a better pitch to think of it as this new global network to play with that opens more doors instead of some never-going-to-happen retrofit from hell.

<comment><USER6> Seconded. IPv6 brings a lot of nice things that we never would have had in an IPv4 based or extended world. Router fragmentation? Gone! Simple subnetting? Hello ipv6! DHCP? Gone (mostly)! Link local addresses? Got em!

These are all positive things we wouldn't have if we were still clinging to IPv4.

</comment></comment><comment><USER7> _From what I can see, he also readily admits that IPv4 and IPv4+ hosts cannot talk to each other, or more clearly, we cannot start using the extended address space before almost everybody has IPv4+ capable software._

I don't know whether to respond to that with "what?" or "yeah, so what?" but I'm leaning toward the former. IPv4 and IPv4+ hosts would communicate with each other, but IPv4 would only be able to communicate with the overlapping range of IPv4+.

Addresses in this range would have initially been relatively valuable but their value would be expected to decrease over time as more hosts started working over IPv4+.

I think djb was right, but obviously we're unlikely to ever find out.

<comment><USER8> "what"? Since you have a multiple IPv4+ hosts with the same IPv4 address, how would an IPv4 host communicate with an IPv4+ host?

<comment><USER7> The idea of multiple IPv4+ hosts with the same IPv4 address doesn't come into it at all. (Questions of proxying in its various forms aren't really relevant.) So, to answer your question: it wouldn't.

<comment><USER8> What does proxying have to do with it? One of us is terribly misunderstanding the concept. As I understand IPv4+ concept in this article, your router gets address 220.127.116.11 then every device behind it gets 22.214.171.124.0.0.0.1, etc. That way all the routers in between don't need to be upgraded, they just get the packets to your router and don't care about the extra address bytes, and your router gets them to a particular device. Which is great for routers in the middle, but your web browser still has to use IPv4 and NAT workarounds until all the web servers are upgraded to support IPv4+.

<comment><USER7> _As I understand IPv4+ concept in this article, your router gets address 220.127.116.11 then every device behind it gets 22.214.171.124.0.0.0.1, etc._

This is the bit that wasn't in djb's original article AFAIR. My take was that 18.104.22.168 and 188.8.131.52.0.0.0.1 would be the same machine -- or at least allocated to the same entity.

</comment></comment></comment></comment></comment><comment><USER9> IPv6 will get there eventually, there's no immediate need for it to happen overnight, obviously.

<comment><USER10> Indeed, at some point the situation with IPv4 will become so grave that it will become impossible to ignore IPv6. Transitioning to something like BangIP might be much easier, but it will be impossible to force people to adopt it, which will only lead to fragmentation. IPv6 might cause massive fragmentation on the internet right now, but once the IPv6 gets closer to 100% we can start dismantling the IPv4 infrastructure, which will force the remaining few to switch to IPv6. There's no way to do that with BangIP, as it involves keeping the IPv4 infrastructure intact, which will allow people to continue browsing a large part of the web and thus there will be little to no reason for a lot of people to switch to BangIP. In the end IPv6 will be a much better solution than BangIP.

<comment><USER11> > once the IPv6 gets closer to 100% we can start dismantling the IPv4 > infrastructure

It's taken 20 years for IPv6 to get to 10%. In another 20 years (2036), will IPv6 be at 20%, 100%, or 0% (superseded by something else)?

<comment><USER12> Nah. IPv6 didn't really start to get going until v4 exhaustion approached, so 20 years is an overestimate.

v4 will die when the routing table becomes too filtered and/or the number of unreliable tunnels grows too large. You may remember how unpleasant v6 was around 2005 with all the flaky tunnels. v4 may well be like that by 2020 if address trading causes many long-prefix v4 routes.

Being yesterday's technology _and_ unreliable has a poor prognosis.

</comment></comment></comment></comment><comment><USER13> The real reason why IPv6 has been so slow to get deployed is precisely that you can _not_ just take an IPv4-using program and network, fix all the structs and API calls, and have an IPv6 program. This is a sideshow compared to the real problem. IPv6 is profoundly different in _all sorts of ways_. Yes, if you just want to open a TCP connection to a remote system you can use an IPv6 address instead of an IPv4 address and the resulting socket is _usually_ essentially identical (it isn't necessarily but the differences often don't matter for the simple common case), but _almost everything else changes_. "DHCP" changes. Vast new rules about all the classes of IPv6 addresses, and all network hardware needs to implement _new_ code to handle all that. IPv6 addresses are _much_ more complicated than IPv4 addresses.

In fact probably most of the people reading this only _think_ they know what an IPv6 address is... based on my experience with people who think they know what IPv6 is, most are wrong. Do you know what the "link local" portion of the address is off the top of your head? Do you know what an % sign in the IPv6 address signifies? (This being HN, of course a few thousand of you do; you don't need to prove that in a reply. But I bet the majority of people reading this do not.)

Just look at this page: [https://en.wikipedia.org/wiki/IPv6_address](https://en.wikipedia.org/wiki/IPv6_address)

By contrast, I can't link you to the "Wikipedia page on IPv4 addresses", because _it doesn 't rate its own page_. It just gets rolled into a single section on the IPv4 page in general: [https://en.wikipedia.org/wiki/IPv4#Addressing](https://en.wikipedia.org/wiki/IPv4#Addressing)

And that's _just_ addresses. There's huge swathes of other changes that require huge amounts of new code to be added to all network devices.

IPv6 isn't a failure (inasmuch as we really should have been done by now) because it requires a total upgrade of all network devices. Probably the vast bulk of critical devices have been upgraded in the time since IPv6 was first standardized. IPv6 was a failure because it also immensely complicated the network protocol and code did not just have to be "slightly modified" to work, but torn down and replaced with a much larger and more complicated chunk of code. IPv6 is _not_ "just" IPv4 with bigger addresses. IPv6 doesn't fail to interoperate with IPv4 because of trivial networking issues, IPv6 fails to interoperate with IPv4 because it's a _wildly different network stack_ that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything else in the stack is profoundly affected.

The advantage of the "just extend it" plan is that it _would_ have been that easy. Perhaps a judicious application of a few solutions to the worst IPv4 problems could have been added. But IPv6 is the technical equivalent of an appropriations bill in the US Congress. We have to do this, so let's take this opportunity to stuff every wish-list item in there we can. We didn't have to do _that_.

In a way, the article does a better job _defending_ DJB's thesis than attacking it, precisely by pointing out that DJB's plan would have been relatively easy and feasible....

<comment> X-Istence > wildly different network stack that happens to offer similar enough TCP-like > abstractions that user-level code often is only slightly affected, but > everything else in the stack is profoundly affected.

TCP itself hasn't changed. TCP is a protocol that sits on top of IP (version 4 or 6). Same with UDP. Yes the IP stack has changed, that kind of thing happens when you bump the version number ;-)

So from an application standpoint TCP/UDP haven't changed, the only thing that has changed is the structure to set up the IP connection, and even that is hidden away for most users (getaddrinfo() deals with most of the complexities for developers).

Percent signs in an address are only used on link-local segments with link- local addresses, as they are the only way to distinguish what network interface to use. In almost all cases where you are dealing with IPv6 you can completely ignore that aspect because you won't have to deal with it, especially as an application developer trying to make connections to IPv6 hosts, or even starting servers/listening for incoming connections.

> The advantage of the "just extend it" plan is that it would have been that > easy.

I disagree. This still requires that the entire IP stack be upgraded to support it, applications still need to update all of their network handling code to deal with the extensions, we'd be in exactly the same boat.

<comment><USER13> As I said, _application_ programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the _other_ hardware has much larger changes to make than just "extending an address". It's a brand new protocol, not an extension.

I've been involved in some relatively _trivial_ extension of application-level network devices to IPv6, and even _that_ was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just "they're a 4-byte integer"; one big one you embed without even realizing it pretty deeply is that "A network address is _one type_." In dual-stack code, you no longer have "an address". You have two types. That's just an example of the problem.

I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not, because I've seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say _convert_. Of course if you write new code on an abstraction layer that already solved this problem it's easier.) IPv6 _is not_ IPv4, quite profoundly. It's not just addressing changes. Converting to IPv6 _is not_ just "replacing all your gear", it is _rewriting foundational aspects_ of all that gear and a non- trivial amount of the software that uses it. Not mere surface aspects like addressing schemes.

This all looks fine and dandy from 30,000 feet, but when you're on the ground, it's a really hard transition.

<comment><USER14> I have (worked at a networking equipment company on IPv6 support, briefly).

The few bits that are totally different (ARP-to-ND, for example) are all very small bits of code. The really hairy stuff was always the dual-stack - <USER2> assumption of a single IP instance running over any given layer-2 network is baked deeply into most systems, and changing that is a royal pain. That plus the renumbering of constants (ugh ICMPv6).

The way I explained it to people was: IPv6 is exactly the same as IPv4, but with incompatible field sizes and constants, different (but usually MUCH simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous day!).

</comment></comment></comment></comment><comment><USER15> What about Enhanced IP as in www.enhancedip.org?

<comment><USER16> Every problem noted in this article also exists in Enhanced IP. It still requires all software and hardware layers to be redesigned.

Every potential alternative to IPV6 is pointless. IPV6 is already implemented by every network vendor, and every modern operating system. Most consumer ISPs have already implemented it. All remaining ISPs, including Enterprise providers, are in the middle of implementing it.

No alternative protocol, including Enhanced IP, is going to be implemented. Ever.

<comment><USER15> While Enhanced IP requires software upgrades it does not require any hardware upgrades. Enhanced IP rides over the IPv4 network without requiring re-peering like IPv6 does. I have already used Enhanced IP over the Internet and it works fine. Also, I wrote the kernel patches for Linux over a period of less than six months. If I can do this the other operating systems vendors could do it too. Instead of being at 10% network capability after 20 years, Enhanced IP has an advantage because it transports packets over IPv4. Enhanced IP also keeps protocols like ARP and DHCPv4 so there is less disruption here. Further, Enhanced IP uses IPv6 AAAA records for DNS lookups so this area of the network experiences less disruption too. You should consider reading about how we do this as it is pretty interesting. Please read our paper or RFC for further clarification or details. They can be found here: [http://www.enhancedip.org/documentation.html](http://www.enhancedip.org/documentation.html)

The one comment you make on your blog post that is true is that Enhanced IP is not compatible with multiple layers of NAT.</comment></comment></comment>


The Startup Sector That's Quietly Booming - <AUTHOR> http://tomtunguz.com/financial-innovation <comment><USER2> They are booming but certainly not "quietly"

\- Bitcoin is all over the news

\- Capital Access Network, Kabbage, etc are at multi 100M valuations

\- Stripe and Braintree are running around at multi 100M vals.

\- Simple and Green Dot / Loopt have done plenty in the PR circuit re their latest banking products.

\- Kickstarter / Indiegogo are very much mainstream.

\- Square is a PR machine at some 4-8B valuation (AFAIK)

</comment><comment><USER3> I don't buy the hype around crowdfunding and its supposed boom.

I think, particularly in the video game space which has seen some of the biggest backings across all industries/verticals, very few successful "crowdfunded" projects hit the market, and those that do generally become available to mainstream consumers with the backers receiving little in the way of truly worthwhile bonuses for fronting the cash.

After being a hugely avid Kickstarter at the get go, I've long since abandoned the site as failed product after lackluster product either died or left much to be desired when it was released. Anything worth owning will eventually be made available for general purchase in a form far superior; it's like someone took the worst parts about buying first-gen, cutting-edge products and exacerbated them.

<comment><USER4> I've come to be of the opinion that the best position to be in is as an earlier buyer of something funded via Kickstarter. I've yet to back something where my thought has been "I'm so glad I was here for the prototyping and quality assurance phase!"

</comment></comment><comment><USER5> The beauty of the financial sector, #1 - there's a revenue stream already. You just need to skim a little of it. That's really how virtually all get-rich-big systems work.

Beauty #2 - The scale of existing financial organizations makes them particularly slow and resistant to change. Lots of opportunity for disruption, if you can avoid getting squashed.

Beauty #3 - The sudden reach of mobile devices puts a lot of computing and network power into easy reach of startups.

Between these three things, it is any surprise that the sector is booming?

</comment><comment><USER5> I was thinking that all of these new financial disruptions will lead to a boom in smaller, relatively safer startups as well. Some friends of mine are creating a wonderful little startup in the shadow of Square, solving serious business problems for small, mobile vendors (like artists and flea markets) that didn't really exist before mobile credit card processing - or at least, couldn't be solved before that tech existed. I imagine the new technologies will lead to lots of new niche markets appearing.

</comment><comment> o0-0o Fintech is at an interesting crossroads. One road in the Internet. The other is the need for transparency/security. Since general solicitation is now legal; we'll see all types of programs released. May the best technology win. Dealflow is king. It will be the determining factor.

</comment><comment><USER6> Perhaps if the VCs, Tom and Redpoint included, lent their weight to combating the protectionist laws that govern the payments sector, we'd have something to show for all of this supposed progress other than more plastic payment cards with magnetic stripes.

Last I heard from Tom was, "The MTL laws are large barriers to entry for startups. I'd love to help but I'm not sure I'm ready to sign my name to a petition without understanding the issue in much greater depth. Given the time constraints, I'm not sure I can sign the document."

It's been about eight months. How about now?

<comment><USER7> Which protectionist laws are these?

</comment></comment><comment><USER8> Quietly? All of these areas are rather high-profile.

<comment><USER9> Was thinking the same!

</comment></comment><comment><USER10> Flight tracking (e.g., FlightAware) and legal tech (e.g., CS Disco) strike me as fitting the title more accurately.

</comment><comment><USER11> Given that "No one ever talks about Stripe or Coinbase" is obviously not a good basis for an argument, I assume he means "People don't seem to connect these various businesses and observe that 'financial services' as a whole is having a moment?"

</comment><comment><USER12> A booming sector in the U.S., a huge opportunity outside the U.S.

</comment><comment><USER13> Just an unrelated question. What blogging platform is this. I've been seeing a lot of blogs with this same style. Does anyone know.

<comment><USER14> Svbtle

<comment><USER13> Thanks

</comment></comment></comment><comment><USER15> For some peculiar definition of quietly!</comment>


Ask HN: Is anyone solving the problem of having to use many different chat apps? - <AUTHOR> Different parts of my social network are on: SMS, WhatsApp, FB Messenger, Telegram, Signal, Keybase, Slack, IRC, and Google Hangouts.
It's super inconvenient having all of those installed, running, updating and notifying me on my laptop and phone, leaving aside the fact that I have to remember who uses what, when and how.
Are there any efforts to unify the experience somehow, kind of like how for a while I was able to use Pidgin and Trillian to message across multiple platforms? That was over a decade ago.
Anyone who solved this could easily charge me $100+ a year. <comment><USER2> Some of those won't be easily turned into a product, since various services forbid connecting with third-party software (e.g. WhatsApp or Signal).

That said, Pidgin, BitlBee or other multi-messengers are still around and have interfaces to a surprising number of services, sometimes flying under the radar (e.g. Skype apparently works better than ever, thanks to people adapting the API their webinterface uses). Not all that comfortabe to use from mobile sadly.

So no, to my knowledge nobody is really solving it, but there are bits and pieces that can help.

</comment><comment><USER3> I remember using Pidgin and other products to combine all of the various chat and instant messaging platforms into one, but I recall a significant barrier was API access, and these platforms not wanting that to happen. I would really, really love to integrate Facebook messenger into a single app with my other messaging apps, but I could not see Facebook ever agreeing to this now.

<comment><USER2> As far as I know (I don't use it myself), libpurple (which e.g. Pidgin uses) can speak the Facebook Messenger protocol.</comment></comment>