Rediscovering the Intel AMT Vulnerability - <AUTHOR> https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability <comment><USER4> _Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL /empty response hash (response="" in the HTTP Authorization header).

Authentication still worked. We had discovered a complete bypass of the authentication scheme._

What. the. fuck.

This is not the kind of bug you should ship in _anything_ if you have the barest bit of testing in place, much less a large company like Intel, in an enterprise feature which has a lot of security ramifications, and which has apparently existed for a long time (years?).

Edit: Also, this is really good evidence for short and hard disclosure deadlines. What's the chance something as simple as this wasn't known by someone else? All they had to do was decide to look and they found something within minutes. It's not like this is obscure or doesn't get your much, it's about as juicy as they come.

<comment><USER5> Wow. Just Wow.

After reading about this over several days I would have _never_ guessed it was such a gaping hole. This reminds me of a software bug I encountered in the 90s with a version of the Renegade BBS software (a Telegard hack). In one minor revision, you could login to any account by just not bothering to enter a password. Though the "sysop" (admin) account often had a custom name, for convenience, you could login by your user number and the sysop user number was always zero. A good friend of mine had his entire system wiped out by a malicious user with this little problem.

It doesn't sound like this is a matter of leaving the password field blank, but rather sending a request with a tool like cURL and setting the header to an empty/NULL response, but it's about as close to _just as bad_ as you can get. Sheesh.

<comment><USER6> So what might the coding error have been? I mean, it seems like null password matches any password. Parsing null can be hard, but seriously?

<comment><USER5> In the case of Intel's AMT, I'm not sure what could have possibly gone wrong, but it sounds like this is something that has happened in other applications that use Digest Authentication.

In the case of Renegade's BBS software, I don't exactly recall the specifics and since it's been several years, I may not have this exactly right but I'm fairly certain this is how it happened because I did a _lot_ of work with the code it was based on[0].

The bug occurred only if the user didn't provide a password. So, effectively, you could login by not providing a password or by providing the correct password. In the original Telegard source, the login prompt did _nothing_ if no password was provided, it simply discarded the provided Enter and waited for a password. This was handled by a global function that was used for accepting input. I'm guessing that function was refactored (I ended up doing this ... it was pretty ugly IIRC) in the Renegade code and it became possible to send a blank password. The login routine was an interesting beast, as well. I remember reviewing it in the original code and scratching my head ... it made _positively no sense_ and so I threw it out and replaced it with a much simpler implementation. Rumors had swirled around the release of the source code that this obfuscation was intentional and that there was a back-door built into the login routine. I'm not sure if that's true or not but the sheer amount of code to do a string comparison was a little ridiculous[1] -- passwords were not hashed, they were stored in plain text in a record (struct- like component) dumped to a file and were even viewable in the sysop control panel's User Editor.

It's entirely possible that they _didn 't_ refactor this bit of logic but changed something in that mess that caused an empty string to evaluate _true_ along with a matched string. Or it could be that they refactored that like I did and put an OR where an AND belonged. If they refactored that global ReadLine method to allow empty returns, they may have felt a need to check for an empty value at this prompt, though I'm not sure what the motivation for this would have been. An empty or NIL value wouldn't have caused the application to crash -- there's no null reference exceptions when you're dealing in a non-OOP language -- you're not executing methods attached to the String type because such a thing didn't exist in the language.

The developer should have discovered the problem _way_ before it was ever released in the wild, but I get why it was missed. He probably checked a bad value and a good value but never thought to check no value at all. Hell, it was a mystery why all of these Renegade boards were going down and a bunch of folks assumed it was a back-door, as was suspected about the original Telegard code. It was a few weeks before people figured out that it was such a _simple_ screw-up.

[0] The source code wasn't public, it wasn't open source. In fact, it only existed because an older version of Telegard had its source code leaked, which the Renegade developers used to create their product (there were a number of "Telegard Hacks" in those days, including one I wrote and later rewrote from scratch and served as the _entire reason I decided to become a software developer_ ).

[1] Sounds suspicious at first glance but there were so many really poorly performing things about Borland Pascal's core libraries that it was not uncommon to write several hundred lines of inline assembly to do things like "write text to the screen quickly". I had done this, myself, on a few occasions -- the specifics were something around writing to memory reserved for use by the display capabilities of the 8088/80286/80386 (BIOS reserved memory IIRC).

[2] NIL was Borland Pascal's "null", and I believe it supported empty strings. Unlike ISO PASCAL at that time, Borland Pascal had a real string type which was stored in memory as a character array with a length field at the 0th index. It didn't use null terminated character arrays like C/C++ which made working with strings in the language elegant by comparison. Strings, however, were 8-bit ASCII ... this being the 90s with the target being DOS and all.

<comment><USER6> OK, it's explained in [https://arstechnica.com/security/2017/05/the-hijacking- flaw-...](https://arstechnica.com/security/2017/05/the-hijacking-flaw-that- lurked-in-intel-chips-is-worse-than-anyone-thought/)

The code compares the correct "hash and the hash response received from the browser, with N set to the length of the response received from the browser". So if the browser returns "", that's compared with the first zero characters in the correct hash, which is also "". Funny.

</comment></comment></comment></comment></comment><comment><USER7> Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching.

That's the problem you should discuss, not this particular exploit.

<comment><USER8> Having a "management engine" with direct access to the network and to memory is questionable in itself. Its code being secret indicates there's probably something bad going in. If it only does what Intel says it does, it doesn't need to be secret.

<comment><USER9> Unfortunately, a "management engine" with some degree of control over the CPU is necessary for, well, management. As in remote management, which is something that big corps with thousands of machines want, and the more control it gives the better.

The code itself is as secret as the code of any proprietary Windows-based remote administration tool they could supply as a poor man's substitute if the ME didn't exist. It's just how this industry works.

This doesn't indicate that there is anything "bad" going on. What _is_ bad is that Intel, being the cheap bastards they are, combined this remote management and DRM, virtualization, TPM, CPU initialization and hell knows what else into one blob running on one MCU with no way to separate and disable the unneeded/unwanted/buggy/vulnerable garbage from actually useful functionality. And that such critical part is closed to third party scrutiny.

<comment><USER10> This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium.

The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence.

All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel providing a signed confession. Both improbable and unrealistic. In many ways the detail, scale and scope of revelations in the past 5-10 years make skepticism and hard questions essential. The benefit of doubt has long moved the other way. This alternative is a kind of forced naiveté and denial.

<comment><USER11> > The fact that both AMD and ARM integrated similar technologies at around the > same time is too much coincidence.

Don't believe the FSF's FUD. TrustZone is really not comparable at all to Intel's Management Engine or AMD's Secure Processor:

* TrustZone is an operating mode of the CPU, not a separate processor. Fundamentally, it's not all that different from supervisor mode; it's just more privileged. (If you really wanted, you could probably write an OS that ran parts of the kernel in TrustZone.)

* You don't have to have anything running under TrustZone. Indeed, most processors which support TrustZone (e.g, most Android phones) aren't using it at all.

* The TrustZone specification is publicly available [1]. You can read about it all you want. (If you're brave enough and have the right development tools, you can even write code to run in it.)

* ARM's reference implementation of a TrustZone OS is also publicly available [2]. If you're curious how it works, you can see for yourself. (This doesn't include the application code which may be present in specific implementations, of course.)

[1]: [https://www.arm.com/products/processors/technologies/trustzo...](https://www.arm.com/products/processors/technologies/trustzone/tee- reference-documentation.php)

[2]: [https://github.com/ARM-software/arm-trusted- firmware](https://github.com/ARM-software/arm-trusted-firmware)

<comment><USER9> > Don't believe the FSF's FUD

Don't believe anti-FSF FUD. If you think they have an issue with TrustZone itself, as opposed to devices using it without owner's control, I'd love to see the links.

</comment></comment></comment></comment></comment></comment><comment><USER9> TL;DR:

      memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len)

Hey, at least they didn't read past the submitted buffer.

edit:

Note that this is only pseudocode and rumor has it that ME firmware is actually written mostly in Java. It's not immediately clear to me how to create equivalent bug in Java, the obvious _string.equals()_ method doesn't ignore length mismatch.

edit2:

s/passwd/passwd_hash to satisfy pedants below ;)

<comment><USER12> > [...] how to create equivalent bug in Java, the obvious string.equals() > method [...]

Java Card, the Java version made for smart cards, does not have strings, and thus no String.equals().

Thought I remembered this from a CCC conference about EMV chips or SIM cards (don't remember which) a few years ago. Googling seems to confirm it: [https://community.oracle.com/thread/1751610?db=5](https://community.oracle.com/thread/1751610?db=5)

<comment><USER13> From what I remember in one of the deep teardowns it's possibly Java ME (which I think is one step above Java Card in terms of features). The file format is JEFF.

</comment></comment></comment><comment><USER14> So the AMT vuln was related to a lack of security on their web service? Somehow this does not increase my confidence in the rest of their code - <USER2> they didn't get this right, what else is wrong?

<comment><USER15> To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.

<comment><USER16> That's more of an argument about inauditable, non-disableable, hostile (the CPU shuts itself off if you blank out the appropriate data structures) code running below ring 0

<comment><USER17> Don't forget in the majority of cases unupdatable too! (No vendor is going to issue fixes for old boards)

</comment></comment></comment></comment><comment><USER18> Closed source custom Java ME and ThreadX blob probably maintained by interns, running all the time with unfettered access to every resource in the system even when the machine is turned off, integrated into almost every enterprise computer network in the world.

What could possibly go wrong.

</comment><comment><USER19> AMD have something similar to this, and there was some mentioning of this in an ama on reddit here:

[https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...](https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/)

What are the reasons for having this, I mean good business reasons? I get that designing cpus is expensive and they reuse as much they can, and that businesses would want the benefits or remote management. However when weighed up against the damage to trust in a company is it worth it enough that they do not offer a line of chips that do not have this pseudo back door present?

<comment><USER20> Most Intel PCs do not have AMT firmware and thus aren't affected by any AMT firmware vulnerabilities.

<comment><USER19> Is management engine not on all modern intel chips, but comes disabled requiring it to be set up in the BIOS?

<comment><USER20> The ME is on all chips but the ME doesn't provide remote management. You're confusing two different things.

</comment></comment></comment></comment><comment><USER21> If AMT provides remote management of devices that are turned off, what program provides authentication of remote management requests when the OS is powered off? Has that interface been audited for authentication vulnerabilities?

If there is an OS-independent, network-accessible AMT management service, when would an admin need to switch from that service to the Windows-hosted web interface? Why can't all AMT operations be performed without an OS?

<comment><USER22> There is no Windows-hosted web interface, the web interface is provided by AMT. LMS is for accessing AMT from the local machine (AMT is listening to the network hardware, so trying to connect to the web UI locally won't work - <USER3> OS will shortcut the network hardware)

</comment></comment><comment><USER23> So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box?

Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?

<comment><USER7> Many enterprise users are affected by this.

<comment><USER23> Sure but they'd be affected regardless, due to enabling a remote management system. All I'm asking is if there's any real damage because this is built in by Intel. If Intel didn't ship this, then OEMs would, just like e.g. Dell DRAC, right? And that'd have the same attack surface.

<comment><USER24> I'm not familiar with DRAC, but if it's something added by an OEM wouldn't it have to be in the UEFI/BIOS layer or higher?

AMT/ME and its ilk are a physical coprocessor built into the CPU, whether it's "enabled" or not, not something that can be added or removed after the fact.

</comment></comment></comment></comment><comment><USER25> So does this cut down the attack to people on your network? Would a simple NAT protect me here?

Also it's bizarre that they're disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don't read hacker news and who aren't exactly going to update their BIOS as an everyday thing.

<comment><USER23> This feature is only active if you set it up and configure it for your company/management system. Random Lenovo customers aren't at risk. The only people at risk are companies that set AMT up, and then they should be looking for security issues with all the vendors they use.

</comment></comment><comment><USER26> The article says that a Local Management Service (LMS) must be installed for the bug to be demonstrated[0], and describes a Windows package that provides that. Is there a Linux equivalent?

[0] I say "demonstrated" instead of "exploited", since I don't understand the details sufficiently to rule out exploitation in the absence of LMS.

<comment><USER27> Yes, there is.

I haven't looked into the exploit, but if the attack uses AMT's http(s) interface, you could also simply access the AMT port(s) from a remote machine. The service simply allows one to speak to the local ME.

</comment></comment><comment><USER28> FTA: "the discovery of a possible zero-day in widely distributed firmware"

Is this CPU firmware? Or microcode? Or is it logic board firmware (UEFI base)? And if it's CPU firmware, is that replaceable or is it permanently baked into the CPU?

</comment><comment><USER29> Will blocking ports 16992 and 16993 at router block this attack (as those are the AMT ports.)?

</comment><comment><USER30> [withdrawn]

<comment><USER31> I'm not sure what you're trying to say -- we can't discuss IME being a second computing system inside of your computer controlled by someome else?

Because I seem to have just done that.

We can even talk about why the existence of that system is problematic, since it gives someone else control over "your" computer.

<comment><USER30> [withdrawn]

<comment><USER31> Are you just trolling?

I've read literally dozens about how Intel ME is a potential vector and it's problematic to have, particularly when unneeded on consumer devices (a number of them here on HN). There's whole discussions about it from people like Libreboot and others who work on fully open systems. Every security professional I've worked with has been aware that there's a potential hardware level backdoor you can't wipe out the firmware for without bricking your machine, and has opinions about it.

I typed "Intel management engine second computer" in to Google, and found articles calling it a privacy/security threat and potential backdoor ranging back to 2010/2011 timeframe on the first page of results. (That's not even a _good_ phrase to search with to find info, I just wanted to prove the point that you can find pieces with literally the first thing that comes to mind.)

<comment><USER32> It seems super useful to me. It lets you do OS installs without a keyboard/screen using VNC. Note that stuff like IPMI is standard in the server world.

<comment><USER31> Sorry, perhaps I phrased it poorly.

I certainly see the benefit in the server world (eg, managing a data center) and even in the corporate one (eg, managing a lot of workstations), and didn't mean to imply that everyone thought it was a negative. (Though, even in that space, some people do because of the closed source nature where they don't have full control of the system.)

Rather, I meant that everyone who was serious about security was aware that it was there and included it in their threat modeling. It's not worse than other remote management technologies (and may be better, depending on your needs and trade-offs).

However, for certain systems, there's never a need for the remote management capabilities, and hence represents a threat for which there's no upside when included. (I would argue most consumer systems fall under this.)

There are of course, a range of opinions depending on ideological bent, and my main point was that there _was_ a discussion about it happening.</comment></comment></comment></comment></comment></comment>


Volkswagen wasn't the only company rigging emission levels - <AUTHOR> http://www.independent.co.uk/news/business/news/volkswagen-wasnt-the-only-company-rigging-emission-levels-says-expert-a6668611.html <comment><USER2> Article is devoid of anything new. Even the title is lying, as the article just claims that other manufacturers 'may' cheat.

So it's all rehash of pretty much everything we already know, and nothing more.

aka clickbait</comment>


Ask HN: Reverse Accelerator - <AUTHOR>

Ok, so this idea's been bouncing around in my head for the past 24 hours and I want you guys to tell me if I'm crazy or not.
They say that 3 out of 4 start ups fail. And they fail for any number of reasons; sometimes the market isn't educated enough, sometimes the economy goes down, sometimes the founders can't handle the business aspect of the company. Point is, a ton awesome start-ups fail for reasons other than the product.
So what if we put together a small fund, $2.5m. We went to every VC in the valley and asked them about their favorite investments that failed for reasons other than the technology. We put together a list of 100 such companies and approach whomever retained the rights to the tech after the company dissolved and attempt to acquire it for around $50k. 90% will turn us away, but there will be at least 5 who have some code sitting on a harddrive that will never be used again, or something similar. 5 pieces of technology that were vetted and funded by VC's but failed to succeed as a company.
With those 5 pieces of tech we put together 5 companies, recruiting experienced entrepreneurs, developers and sales people, and give each company $250,000.
We just took $2.5m and created 5 companies with a combined valuation of roughly $10m.
I feel like these companies are more likely to succeed than the average start up because we know the tech is solid; we sourced it, and we wouldn't fund it if we didn't believe in it ourselves. And we assembled an experienced team to manage it. But if even one of those companies has a successful exit, than the fund will easily clear the $2.5m investment.
I called it a reverse accelerator because rather than the founders coming to us with an idea for mentorship and $ to help them build their company, we come to them with tech and $ and help them build their company.
Am I crazy? <comment><USER2> Related: There is an opportunity for a company (or even multiple companies) to build a suite of complimentary software and services from the IP and former customer bases of failed startups. The trick (aside from having the funds and clout to negotiate and keep the purchases at small dollar amounts) is to find the areas where two (or more) unsuccessful businesses could have been successful if they were run under the same house.

<comment><AUTHOR> exactly! theres a ton of good ideas and good work sitting on harddrives because the original company didn't succeed, and I'm sure a lot of it has value that could be recycled or reintroduced

</comment></comment><comment><USER3> You're not crazy but I'm not sure to see the added value over a normal "company builder" (where the fund comes up with the idea). Are you sure the idea/market opportunity was the most interesting thing about those failed startups in the first place? They might have raised money for other reasons (team, momentum) which are now gone.

<comment><AUTHOR> Well we could focus on ones that had those issues, but you're right, there isn't much more value-add than a traditional company build, and I suppose I'm not very well informed about those funds</comment></comment>


The Long-Awaited Fed Balance Sheet Taper Begins Today with Mortgages - <AUTHOR> https://www.bloomberg.com/news/articles/2017-10-13/long-awaited-fed-balance-sheet-taper-begins-today-with-mortgages <comment><USER2> So the Fed is throwing individual investors under the bus because they'll have to absorb the volatility?</comment>


Nailgun: Making Java Practical for Command Line Utilities - <AUTHOR> http://martiansoftware.com/nailgun/background.html

<comment><USER2> Charles Nutter has a writup on using nailgin with JRuby: [http://blog.headius.com/2009/05/jruby-nailgun-support- in-130...](http://blog.headius.com/2009/05/jruby-nailgun-support-in-130.html)

I've tried this and it works fine.</comment>


Mike Davis, 'World's Grumpiest Boss,' Dies at 85 - <AUTHOR> http://www.nytimes.com/2016/09/26/business/edward-davis-worlds-grumpiest-boss-dies-at-85.html <comment><USER2> The link to the memos in Letters of Note.

[http://www.lettersofnote.com/search?q=+Tiger+Davis](http://www.lettersofnote.com/search?q=+Tiger+Davis)</comment>


Pokevision: An Open Letter to John Hanke and Niantic - <AUTHOR> https://medium.com/@yangcliu/an-open-letter-to-john-hanke-niantic-6a32325b67a8 <comment><USER2> Note: author is main developer of Pokevision, which was shut down after API changes by Niantic.</comment>


Ask HN: What projects have you worked on that ended up failing - <AUTHOR> <comment><USER2> 1\. Small, fixable failures: software crashed in production every night at 4AM.

2\. Utter failures: long ago tried to do something like [https://capnproto.org/](https://capnproto.org/), wasn't up to it.

3\. Worked on many projects that were replaced or cancelled a year later; the largest was an airline reservation system.

4\. Started a startup, it failed due to lack of attention to what users wanted.

You can hear full version of these stories and how to avoid other failures of mine at [https://softwareclown.com](https://softwareclown.com)

</comment><comment><USER3> I worked for an MLM company that was flying high when I started ($400M+ annual sales) then tanked and closed. Team of about 30 devs and sys admins built a complete e commerce system, duplicated outlook as a web app, and a lot of other stuff. All that software is gone. Best team I've ever been on. Projects didn't fail but the company did.</comment>


Awesome Pascal – A curated list of Delphi, FreePascal, and Pascal shiny things - <AUTHOR> https://github.com/Fr0sT-Brutal/awesome-pascal <comment><USER2> There's a tender place in my heart for Pascal. The first language I was taught was Turbo Pascal (I had sort of taught myself QBasic before that, as much as one can from reading the help manual and stumbling through), and the built-in libraries was as close to the liberty and scope of Python as you could get in those days. It really inspired me to continue down the path of software development.

I also have fond memories of BBS door games and software, a large portion of which was built with Pascal.

I digress: but it's nice to reminisce about those old days.

<comment><USER3> > and the built-in libraries was as close to the liberty and scope of Python > as you could get in those days

And even better with Delphi that additionally had better rapid UI creation possibilities than Visual Basic, and on top of that, differently than Visual Basic, produced a self containing executable, not depending on anything external.

<comment><USER4> Yeah, but the VB executables themselves were tiny (in P-Code form, which was the default, they were also much more compact than machine code) and while a single exe+runtime itself was larger than the ~300K a minimum that Delphi 2/C++ Builder would produce (with +~100K for a program that did something interesting), it would take 3-4 programs sharing the runtime to quickly win that difference back.

This is actually a (minor) issue i have with Lazarus - the executable files do not depend on anything, but they are too large (~2MB minimum nowadays, if you remove all debug info, etc) so if i want to create several "small" utilities that focus on one thing instead of a multi-tool, i waste a lot of space (and most importantly nowadays, bandwidth).

At least with Delphi you can compile the executable with the runtime library as a separate file to be shared among the programs (my guess is that they wanted to do something the VB shared runtime, but it didn't seem to catch on as nobody used it like that).

<comment><USER3> > the VB executables themselves were tiny (in P-Code form, which was the > default, they were also much more compact than machine code)

Now that you mention and I think about it, as VB was compiled to the p-code and depended on the big common runtime which executed it, it can be seen as one Windows-specific spiritual precursor of... Java.

<comment><USER4> Yeah, actually Microsoft used P-Code way before VB1 - AFAIK their C compiler was able to emit it and several of their products were compiled as P-Code instead of machine code, which helped to save disk space (a premium at the time, especially considering it could make a difference on how many floppy disks they shipped) and quickly port their applications to other emerging platforms at the time (like the Macintosh).

Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code to be executed by a runtime they implemented quickly in a lot of systems (including the original IBM PC).

<comment><USER3> > Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which > only emitted P-Code

Yes, and I've actually experimented with UCSD Pascal on a 8-bit machine (Apple II). Turbo Pascal was, of course, much faster on it (using Z-80 card).

</comment></comment></comment></comment></comment></comment><comment><USER5> Wow, that's a comprehensive list! I've been searching for the most useful resources I've used in 25 years and they're all there.

On the other hand, I see that Delphi usenet forums have been closed for a year... long time I had not checked.

<comment><USER6> If you're looking for a relatively active community, you can check this subsection of a long-running German forum, recently created to replace the Google+ group that's closing down: [https://en.delphipraxis.net](https://en.delphipraxis.net).

<comment><USER7> Thanks for sharing that link. Will check it out. Was feeling bad about the fact that the comp.lang.pascal.delphi (name right?) group (a Usenet group, and then gatewayed via Google Groups) was not very active, and/or had spam (but that was common to many Google groups - yes, I mean Google, not Google+, though I know you said Google+, although some time later I noticed that Google may have done something about the spam issue on Google groups, and it came down a lot, IIRC).

<comment><USER8> Delphi is still relatively used in Germany, with an yearly conference taking place.

<comment><USER7> Had heard of this (and in fact more generally that (ex-)Borland products are popular there, which is good, but thanks for mentioning it.

</comment></comment></comment></comment></comment><comment><USER9> With the amount of slow electron apps these days I wish more people would write native programs in Pascal / Delphi. It's blazingly fast and easy to write (although the language has a few idioms it takes time to get used to).

<comment><USER10> I think that there is room for improvement... Flutter is something very interesting, though yet another language (Dart). React Native is also interesting, but actually creating for cross-platform has some niggles. I would think a nice cross-platform UI toolkit for Rust, once async/await drop could be huge. WebAssembly + Canvas|WebGL|SVG as a generic runtime base could go a long way to also bridging a gap.

In the end, it really just depends. Right now electron is the closest we've had to a cross-platform application base with a UI that is easily styled and a single codebase for write once, run anywhere that we've had. Most of the cross-platform UI tooling that's come before has kind of sucked. Even getting build pipelines for multiple platforms (even just Linux, Windows and Mac) has been pretty painful. Electron bridges a lot of gaps at the expense of a more bloated baseline.

I think things will get interesting and we'll see some new/old paradigms show up.

<comment><USER8> I rather use JavaFX or Qt for that.

If it can be done just with HTML 5, CSS, JavaScript, then its place is the browser.

</comment></comment></comment><comment><USER11> Why would anyone use Delphi these days? Except the case of maintaining legacy code.

<comment><USER12> I wouldn't use it for my projects, but Delphi still has some strengths that are not so common these days:

\- very fast compile times

\- great backwards compatibility

\- non programmers can create simple programs

<comment><USER13> "non programmers can create simple programs"

What does that mean? You can be a non programmer and make simple programs in most general purpose programming languages.

Are you talking about the VCL library? In that case, there are many other languages that include the same like C# for example.

<comment><USER14> Delphi is hard to beat in ease-of-use of the GUI editing. It's not just that it ships with the component library, it's that the editor integrates it so well.

<comment><USER4> ...and before someone tries to counterpoint that Visual C# has WinForms which is similar to Delphi, yes it is similar, but the functionality available in terms of design in Visual Studio 2019 isn't up to par with Delphi 2.</comment></comment></comment></comment></comment>


Journey Through The JavaScript MVC Jungle - <AUTHOR> http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/ <comment><USER2> I have to say, the more javascript (these days coffeescript) I write, the more I think an mvc structure on the client is usually a big mistake. Mvc means shared global state and putting your data behind an inflexible facade, neither of which is necessary or a good idea in ui programming.

What's the alternative? Components. Encapsulation. Modularity. It's nothing fancy. Just build small, composable functions and objects that manage their own data and subcomponents, and don't reach outside themselves. In this way you end up building up lots of mini mvcs, one on top of the other, to manage requirements with the approach and data structures most appropriate to each, rather than constantly trying to bend a monolithic global model and api into doing exactly what's needed.

You don't need a complex hierarchy of model classes for your data. Just use json. When you need to process or manipulate it, write a function. When you need to send or receive data from the server, $.ajax and handle the result on whichever tier needs it. Send and receive just the data you need in just the structure you need. No syncing or rails-like magic required.

<comment> anton-107 Well, after all when you get your modular components you still need some piece of code to make them work together. It's not like you throw them into your project and they magically become an application.

</comment></comment><comment><USER3> > If you're writing an application that will likely only be communicating with > an API or back-end data service, where much of the heavy lifting for viewing > or manipulating that data will be occurring in the browser, you may find a > JavaScript MV* framework useful.

This, in my opinion is the most critical point when thinking about which framework you want. Once you know that, for example, you are going to do a lot of heavy UI manipulation and you do want an MV* framework, I think you end up splitting hairs about the differences between the frameworks. Spine or Backbone or Ember or whatever. At the end of the day, those frameworks are just the starting point and with any application of significance, the custom standards you put in place will have a much bigger impact than the framework you start off with.

</comment><comment><USER4> The suggested criteria for selecting a framework fails to ask the most important question, what are you building?

The lightweight libraries have their place in weekend-long hack projects. The larger frameworks lend themselves to multi-view, complex applications.

</comment><comment><USER5> Brilliant article. Please note that this was written by Addy Osmani, best known for TodoMVC.

</comment><comment><USER6> Great article! I was just planning on starting a fairly complex Web app with jquery, now i'm thinking I should give one of these js mvc frameworks a shot.</comment>


A human way to define regular expressions in Ruby - <AUTHOR> http://krainboltgreene.github.io/hexpress/ <comment><USER2> Am I the only person who thinks that things like this are totally unnecessary? Is learning/reading regular expressions really that difficult for most people?

Here's the subset of regular expressions that has gotten me through nearly all of the regular expressions I've ever needed to write. As a plus, it has no dependencies!

* - zero or more of the preceding character/group

\+ - one or more of the preceding character/group

? - zero or one of the preceding character/group

$ - end of line

^ - beginning of line

. - one of any one character

\ - escape the following character (for a literal '$' or '.', for example)

[<some characters>] - one of the given characters

[a-zA-Z0-9] - letters and numbers inside a group can have ranges!

(<something>) - capturing group (anything that matches inside it will be accessible in the match object)

<thing1>|<thing2> \- either the first thing, or the second thing (or the third, or the fourth...)

This isn't a complete, or even precise, definition, but knowing those things will get you to the point where you can read and write expressions like this:

^(-|+)?[0-9]*\\.[0-9]+$

which matches things like -.2, 0.123, +0.1, etc. (floating point numbers, basically). This likely has bugs, since I haven't tested it ;)

<comment><USER3> > which matches things like -.2, 0.123, +0.1, etc. (floating point numbers, > basically). This likely has bugs, since I haven't tested it ;)

The fact you can't come up with a regex and be sure it's correct answers your first two questions.

Regexes are incredibly useful, but the syntax is just a bunch of noise. This library turns it into self-docummenting code, which is incredibly valuable. Novices might prefer showing their regex-fu, but after you've spent a good chunk of your life reading and writing code, you value clear code more.

<comment><USER2> Under the hood, what's being generated is still a regex though. How can you be sure ANY code is correct, aside from testing it?

<comment><USER4> True, but your argument can apply to any sort of abstraction (e.g. using C instead of assembly or even assembly over 1's and 0's).

He's arguing that the nicer syntax is a valuable abstraction over regex's overly-complicated syntax, not that the syntax will be 100% the same as regex 100% of the time.

</comment></comment></comment></comment><comment><USER5> I really don't understand why some people are so afraid of regex. Sure, it's not perfect, but these symbol-less solutions feel to me like one step forward and two steps back. A more interesting development would be something along the lines of what Perl 6 is trying to do (if only someone could implement it).[1]

We should start treating regex like a computer language in its own right, rather than some second-hand citizen that we stuff into a single line without any delimiting whitespace. Use the /x switch and comment your code as you would with any other programming language, and you'll find that regex really isn't that scary.

Take the example pattern. The regex written by a human might look something like so:

        m{^
            https? ://        # Protocol
            (?: \w+ \. )?     # Subdomain
            ([\w\-]+) \.      # Domain
            (?: com | org )   # TLD
            /?
        $}x

It's certainly easier to parse. Debugging it is also a lot easier. We can see that this won't match anything with more than one subdomain. We can also see that it won't match subdomains that have hyphens in them. It also looks at a glance much more like a URL and less like some arbitrary Ruby code.

[1]: [http://www.perl6.org/archive/doc/design/apo/A05.html](http://www.perl6.org/archive/doc/design/apo/A05.html)

<comment><USER6> > _something along the lines of what Perl 6 is trying to do (if only someone > could implement it)_

What, like, perl6?

        grammar URL {
    	rule TOP { <proto> '://' <domain> '/' }

    	token proto { 'http' 's'? }
    	token subdom { \w+ }
    	rule domain { <.subdom> [ '.' <.domain> ]? }
        }

        say URL.parse('http://lelf.lu/');

        Betty:hacks lelf$ perl6 gr.p6
        「http://lelf.lu/」
         proto => 「http」
         domain => 「lelf.lu」

<comment><USER7> And for those interested a full RFC 3986 (URI) in Perl6 grammar can be found here - [https://github.com/ihrd/uri](https://github.com/ihrd/uri)

Here is direct link to grammar module - [https://github.com/ihrd/uri/blob/master/lib/IETF/RFC_Grammar...](https://github.com/ihrd/uri/blob/master/lib/IETF/RFC_Grammar/URI.pm)

</comment></comment></comment><comment><USER8> This is interesting. I find that regexes are one of the few places where a comment explaining what a block of code does is generally necessary. Since the "ruby way" is to use aggressively replace comments with method and variable names, a tool like this is a good way to achieve that goal.

That said, this also makes a huge tradeoff against conciseness. Personally, I'd prefer

        # Is foo a valid klingon email address?
        foo =~ /gibberish/

Over

        foo = Hexpress.new.
            start('g').
            maybe('i').
            many('b').
            find('b').
            ...

<comment><USER9> In another rant about how my library isn't needed someone helpfully noted you can actually do comments with the %r{} syntax:

        %r{
          ^
          # foo
          bar
          $
        }

</comment></comment><comment><USER10> Please yes!

I did a little research and this derives from Verbal Expressions, as explained [1] and implemented [2]. In any case, I'm emphatically in favor. I'm the sort of programmer that needs to write maybe one regex per month, and I'm tired as hell of relearning the human-meaningless syntax for regexs, let alone all the little variations between languages. Not to mention, if it can vastly reduce the number of symbols I have to escape when matching special symbols, so much the better.

[1] [http://thechangelog.com/stop-writing-regular-expressions- exp...](http://thechangelog.com/stop-writing-regular-expressions-express-them- with-verbal-expressions/) [2] [http://verbalexpressions.github.io/](http://verbalexpressions.github.io/)

<comment><USER9> I really need to link those in the readme, thanks! I also discovered on releasing this a really old ruby library that predates either of those and I'm adding that too.

</comment></comment><comment><USER11> Wow. My mind is blown.

It almost feels like what high level programming languages are to assembly code.

Sure, we can (and should) learn Regex constructs, but it is undeniable that this library provides an unmatched level of clarity.

Kudos to Krain for coming up with such an elegant solution to the issue of Regex building/reading.

<comment><USER12> Personally, I would not use this. One of the powers of regex is the similarity (depending on complexity and structure) between the regex pattern and what a matching string looks like. By doing it this way, a lot of noise is introduced that can make parsing more difficult.

I don't find:

        find { matching { [word, "-"] }.multiple }

Clearer than:

        ([\w\-]+)

It might be an alternative way introduce regexes though.

I would also like to see a more complex regex written this way.

<comment><USER9> In that example I wanted to show off a the matching and multiple syntax.

</comment></comment></comment><comment><USER13> Regular expressions were very invented to avoid this. Because this works fine only as long your regular expressions are small and few.

Once that fact changes you will find yourself writing and staring at walls of text.

You will do this enough number of times, then only hope that you have a more succinct and powerful way of expressing such a idiom, you will do all that only to realize using regular expressions are the only way to solving a range problems which it was designed to solve.

The easiest analogy I can give you math. Prior to manipulation of symbols, math was pretty much text. The whole of math looked paragraphs of puzzles and word play. Worked fine when you want to do small things like postulates, axioms and a few things derived from that. To move a higher level of abstraction and interplay of concepts we had to get into symbols.

This is something similar.

</comment><comment><USER14> Python's re.VERBOSE let you write [1]

        a = re.compile(r"""\d +  # the integral part
                           \.    # the decimal point
                           \d *  # some fractional digits""", re.X)

Instead of

        a = re.compile(r"\d+\.\d*")

But that is as far as it goes for me. From that point, masking REGEX with additional layer of 10's of functions is not a wise move.

[1] [http://docs.python.org/2/library/re.html#re.VERBOSE](http://docs.python.org/2/library/re.html#re.VERBOSE)

<comment><USER9> It's not meant for simple regex like that. It's meant for complex composed regular expressions.

<comment><USER15> Seems that most languages with built-in regexes lack any operation on them (like `/foo/ \+ /bar/` or `/foo/ | /bar/`). I'd blame the standard library, not praise a third-party one.

</comment></comment></comment><comment><USER16> This completely illustrates what I hate most about ruby: the conflation of 'understandable code' with some sort of insane directive to turn everything into an English sentence without any regard for what the code actually does. At its worst it's almost an obsession with enforcing technical ignorance.

That said, regexes can be tricky to parse and making them clearer to the average person is a worthy goal.

</comment><comment><USER17> I don't understand why so much hate for the library. For me, this is a very ruby way to tackle regular expression problem that newbie like me have.

Not that I'm saying that newbie shouldn't learn regex. But any level of abstraction would be great. Rails abstract the complexity of web development. Hexpress abstract the complexity of regex. Both are win in my book.

</comment><comment><USER18> Like VerbalExpressions, this a good idea carried out without full acknowledgement of the nature of regular expressions. There's no shortcut - concatenation, union, and kleene star. A URL operator doesn't replace any of them.

If there isn't isomorphism between the traditional symbols and the new names, then the expressions will be limited in expressiveness.

</comment><comment><USER19> Here the same[1]. This library squats vocabulary in a bad way. e.g.:

#word is (\w+). This works in english, but breaks very early. Still, it might be correct in some time. "word" is extremely context-sensitive.

[1] [https://news.ycombinator.com/item?id=6319584](https://news.ycombinator.com/item?id=6319584)

<comment><USER9> Good point, and more importantly I should be making use of the special Ruby matchers.

</comment></comment><comment><USER20> It seems like the argument against regexes is that they can get really complex and unreadable. For something as simple as that url, isn't it easier to just use a regex?

Seems like in the 'unreadable' regex case, you'll have a boatload of verbose function calls to construct it.

<comment><USER9> Library owner here. A huge draw for me to make this library was composability, not avoiding regex syntax.

I want to share patterns without having to do much.

</comment></comment><comment><USER21> So as computer scientists, we're in the business of tradeoffs right. I think the conciseness tradeoff for clarity is good. Abstracting away from pure regular expression syntax is a good thing, I think, because it offers better AT A GLANCE reading.

Why would that be better? I recently saw Bret Victor's Inventing on Principle talk on Vimeo, and one of the things he mentions that I really agree with is that most of us must 'think like computers' to understand what our code will do. The less we have to do this, the better, because we're terrible computers

Now am I likely to use something like this? No, mostly because I don't program in ruby TOO often, and I am pretty well aware of how to use regular expressions.

</comment><comment><USER22> Here's a link to the VerbalExpressions organization that contains implementations of a similar DSL for various languages: [https://github.com/verbalexpressions](https://github.com/verbalexpressions)

<comment><USER23> Very cool. I like the standalone "start_of_line" more than the start("some string").

<comment><USER9> We actually match (and beat) the VerbalExpressions standard if you `require "hexpress/verbal_expression"`

</comment></comment></comment><comment><USER24> Cute, but I prefer just using Rubular to test out regex's

</comment><comment><USER25> Or instead of learning start maybe with words multiple has either ending you learn ^?\w+(|)$.

I'd imagine that wrappers such as this one do not enable users to create any more complex patterns, than ones they could make with a most basic understanding of regular expressions. Whilst providing neither a base for more complex regex use nor a community to further an understanding of regex.

<comment><USER9> Considering the composability I've designed here I'm not sure how you think it wont "enable users to create more complex patterns"?

</comment></comment><comment><USER26> Now we need a human way to write Ruby in Python.

</comment><comment><USER27> The reason that this library is useful is because I don't have to maintain an AST in my own feeble mind about what each special character in the regex means. I can look at the code, at first glance, and immediately know what the hell is going on.

Also, this.

[https://xkcd.com/208/](https://xkcd.com/208/)

</comment><comment><USER9> Library owner here, I've added some replies to points made but I just want to note that the readme on Github's website was a bit out of date and provides a little more details now.

</comment><comment><USER28> Seems easier to just use a regex. Every programmer should know them already, so this is just another API to remember. Still kinda cool though, but prob not so useful.</comment>


Bitcoin block propagation with IBLT, Part I - <AUTHOR> http://popeller.io/index.php/2015/10/09/bitcoin-block-propagation-with-iblt-infographic/ <comment><USER2> The problem statement is not so simple; one one hand there is incentive for the miner to keep the block small so that it propagates the network faster but that is looking at immediate profit, however, on the other hand, Peter Todd has shown[1] in the bitcoin-dev mailinglist that actually "increasing" the blocksize and even withholding it for some time significantly increases profit in the near long term.

Now, even ignoring this, if we assume the problem statement just as what the author describes, there are problems with his approach. Firstly, big pools have said that they operate at a loss and their aim is not to earn profit from mining but by providing value-added services like 'guaranteed tx confirmation', which big pools can. Secondly, and technically, this only works if data set is low so as to keep collision low [2]. Beyond a certain point there are many false positives and worst case all transactions might be needed to sent anyways.

So although this is not worse than the current status, but certainly could end up not even being useful.

[1] [http://www.mail-archive.com/bitcoin- firstname.lastname@example.com...](http://www.mail-archive.com/bitcoin- firstname.lastname@example.com/msg03200.html) [2] [https://en.wikipedia.org/wiki/Bloom_filter#Interesting_prope...](https://en.wikipedia.org/wiki/Bloom_filter#Interesting_properties)

<comment><USER3> [1]: Selfish mining may be a problem, and only big miners can profit from it. This has nothing to do with IBLTs though, other than that big miners may withhold them just as they would withhold a full block. The rest of us (small miners) can still use IBLTs to decrease our orphan rate.

"providing value-added services": Yes, it's up to each and every miner to decide how and when blocks are transmitted. If they want fast propagation, use IBLT. If not, use full block. Any relay node may as well chose to relay it as an IBLT or as a full block.

"Beyond a certain point there are many false positives and worst case all transactions might be needed to sent anyways": Definately yes! I will present some stats on that in future blog posts. Meanwhile you can look at [https://github.com/kallerosenbaum/bitcoin- iblt/wiki](https://github.com/kallerosenbaum/bitcoin-iblt/wiki) for some data on this.

</comment></comment><comment><USER4> The abstract problem is there is a set of objects and all peers have access to some subset of them. You want to communicated an ordered list of them plus some arbitrary data (your winning hash) to as many peers in as little data as possible.

It seems to me that the best solution is to have a well agreed upon function that keeps them in an ordered state and simply keep track of what transactions your neighbors know about, the information should largely already be there due to the fact that the transactions are dissiminated by a gossip protocol in the first place.

</comment><comment><USER5> Here is where IBLT was specified:

[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2](https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2)

More:

[http://lists.linuxfoundation.org/pipermail/bitcoin- dev/2015-...](http://lists.linuxfoundation.org/pipermail/bitcoin- dev/2015-May/008000.html)</comment>


Proposal to restore a destroyed Ethereum contract - <AUTHOR> https://github.com/5chdn/EIPs/blob/a5-eip-999/EIPS/eip-999.md <comment><USER2> If they want to change history to help a privileged group of people, they should have a generalized mechanism and process for doing so. If I can prove I accidentally lost 1 ETH, let alone millions, I should be able to retrieve it via that same process.

I love Lord Vitalik as much as any ETH nerd, but the more he dictates to help his friends, the more it will hurt the ecosystem.

<comment><USER3> The "generalized mechanism for doing so", in this case, would be the EIP process itself, no?

It's a bit like those clients that say of their software, in its requirements, "I want my software to be customizable after-the-fact with any new logic I desire, up-to-and-including the power to completely rewrite the application." Some people try to solve this problem as stated, resulting in the [https://en.wikipedia.org/wiki/Inner- platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect). Other people recognize what's happening, and just respond with "the customization mechanism is the source code. You can customize it at any time by contracting a programmer to do so for you."

The FDIC of the Ethereum blockchain† seems to be—as this example, and the earlier example of the DAO, would suggest—the Ethereum maintainers themselves. The way the Ethereum maintainers propose changes to the consensus protocol to fix problems is through EIPs. So, if there's an Ethereum "natural disaster", the natural thing to expect in response would be an EIP.

† (as opposed to the _Ethereum Classic_ blockchain, which has no such entity, which is rather the point of the fork.)

You could create another layer _atop_ the EIP process, formalizing specifically the recovery process from a "loss of money" event... but it's really going to boil down to a consensus-algorithm change in the end, so an EIP is going to have to be involved.

(Unless you're suggesting that there should be some way, within the Ethereum VM itself, to aribtrate disputes in a way that invalidates the side-effects of previous contract calls? That'd certainly be a trick... especially given that the said "arbitration" would seem to be a human-complete problem, and Ethereum doesn't even have oracle support yet.)

<comment><USER2> If I can't get my ETH back back when I mess up, then neither should Parity. If the community wants me to get my ETH back when I mess up, then Parity should be able to. I'm not providing a value judgement on whether this is good or bad. I'm saying that it is hypocrisy to let one group get their ETH back over the individual if they have enough political support.

But I see your point about the EIP process. Altering history to benefit a group of people is always contentious, so the EIP process is itself a way to do it on a public forum.

<comment><USER4> It's not hypocrisy to have a threshold of losses before intervening.

<comment><USER5> What's a fair threshold? How could a fair threshold be determined and later justified when people push back against it?

What is the process for adjusting the threshold if the value of the currency swings wildly? A theft of a single Bitcoin is now a theft of thousands of dollars, but years ago it would have been a handful of dollars.

It's easier to say that thefts of any amount should be restored than to deal with all of the politics of picking a threshold. Isn't the Ethereum system designed to avoid politics and the need to trust other people?

<comment><USER6> > What's a fair threshold?

Thresholds are never fair and always arbitrary. However that's not a reason to avoid anything that has an arbitrary threshold. Arbitrary is often better than nothing.

<comment><USER5> When it comes to money, arbitrary rules are definitely worse than nothing. If I use a system to own or transfer money, I want to know exactly what the rules are. I have no confidence in arbitrary protections. Lack of confidence is what kills economies, companies, and currencies. It's in every cryptocurrency project's interest that people who hold the currency have confidence that their rights are protected.

<comment><USER7> Exactly, the cryptocurrency told us the code is law, but in the ETH, the Lord can change the law whenever he wish. It looks absurd.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Stuff like this is why smart contracts won't work for the general public. Nobody wants to live in a world where a bug in a contract lets people steal your money and you can't get it back, even when you can prove who did it. We have contract law to deal with this stuff in the real world.

The problem is, if smart contracts are subject to human governance, what advantages do they have over any other kind of contract? How can they be trusted more than anything else that is subject to human governance? Automatic execution of contracts is nice, but if history can be rewritten later, you can't really build a deterministic system on top of them.

<comment><USER2> I think "smart contract" is a bad name for what it truly is - a program that runs on the blockchain. I tell programmers to think of smart contracts as programs.

An Ethereum smart contract (program) may be useful when applied to a problem currently solved with a legal contract. But not necessarily.

MakerDAO[0] is a project that achieves a token (Dai) that is termed a "stablecoin" as its value is soft pegged to $1 USD. It was launched in late December and has been very successful thus far. Maker achieves this with a series of smart contracts and operates entirely within the blockchain. MakerDAO is the type of project that is unique to smart contracts and is not possible without Ethereum or similar technology. These are the types of projects you should consider when analyzing the longterm technological capabilities of Ethereum. Imagining a world where paper contracts are replaced with Ethereum smart contracts is a misconception.

[0] [https://makerdao.com/](https://makerdao.com/)

<comment><USER5> It's ironic that a crypto project seeking stability decides to peg its valuation against a fiat currency, i.e. the US dollar.

<comment><USER8> As always, you'll have to read into the details. MakerDAO doesn't exactly peg it's value to the US dollar. Here's a good interview about how it works - [https://www.youtube.com/watch?v=ZggkzPJ5Yt4](https://www.youtube.com/watch?v=ZggkzPJ5Yt4)

</comment></comment></comment></comment><comment> ryan-c The person who wrote this EIP works for Parity.

If we're going to be fixing shit like this, can we also restore funds to the poor guy who got robbed of 41k ether?

[https://medium.com/taptrust/frozen-the-story-of-the- largest-...](https://medium.com/taptrust/frozen-the-story-of-the-largest- wallet-burglary-in-ethereums-history-a-massive-mystery-and-a-1b0a81f3ee88)

[https://www.coindesk.com/35-million-refund-developer- appeals...](https://www.coindesk.com/35-million-refund-developer-appeals- ethereum-hard-fork-hack-reversal/)

<comment><USER9> > the hack happened because of a weak passphrase [...] Levy [expected] his > private key would still be needed to access the wallet. But the wallet > generation tool Levy used, developed by ethereum creator Vitalik Buterin, > had a critical flaw in that others could access the wallet just with the > passphrase.

Neither gpg nor ssh keys work that way. Why would Vitalik design the etherium wallet key like that? The passphrase is the last line of defense against people who have managed to access to your system, it's not the first and only defense against remote attackers.

<comment><USER10> > Why would Vitalik design the etherium wallet key like that?

Because he may be very clever at having come up with this whole ethereum system, but that doesn't mean he's wise and experienced. It's a rookie mistake, made by a rookie. It happens. He seems the type to learn from it at least.

<comment><USER11> No, the tool works like a brainwallet. The seed phrase determines the ethereum public and private keys. That way there is nothing else to save, no file backup is necessary. Knowledge of the seed phrase is sufficient. That's a feature, not a bug.

It is not like gpg where the private key is independent, stored on disk and encrypted by the passphrase.

The user messed up in that he didn't understand that he needed to use a strong passphrase or it was possible for anyone in the world to guess it.

<comment><USER12> >No, the tool works like a brainwallet.

Are you saying that is a good thing? It's well known that brainwallet is a footgun.

[https://en.bitcoin.it/wiki/Brainwallet](https://en.bitcoin.it/wiki/Brainwallet)

>An early old-style brainwallet was created by by memorization of a passphrase and converting it a private key with a hashing or key derivation algorithm (example: SHA256). That private key is then used to compute a Bitcoin address. This method was found to be very insecure and should not be used. Humans are not a good source of entropy.

</comment></comment></comment></comment></comment><comment><USER13> From diving in, it looks like the contract backing a smart wallet implementation had a vulnerability/bug/design flaw allowing an arbitrary actor to kill it[0]. It looks like these contracts are treated as a shared library so the contract being killed means any wallet depending on it is bricked.

The solution here seems to be a hard fork of Ethereum to allow revival of that problem contract. This seems unpalatable as, well, avoiding extensive human intervention is a key idea in cryptocoins.

Disclaimer: I got off the cryptocoin train awhile back so if I've mistaken anything, please point it out.

[0] [https://github.com/paritytech/parity/issues/6995](https://github.com/paritytech/parity/issues/6995)

<comment><USER14> It's not the first time Ethereum has hard-forked to roll back a sufficiently bad bug in a smart contract, and it probably won't be the last. They periodically do hard-forks for other reasons as well. Eventually they might declare it 1.0 and stop doing this, but that's not how it's managed today. At this point I think users accept this as a risk of using Ethereum. Of course anyone who doesn't like it is free to try to keep the old chain alive (indeed, Ethereum Classic is still a thing that exists).

<comment><USER15> Ethereum Classic also hard forks in order to make changes and other upgrades to it's protocol.

Ethereum has not yet hard forked to enact this proposal. At the moment it looks very unlikely to gain the support needed.

</comment></comment></comment><comment><USER16> The debate is mostly happening here:

[https://www.reddit.com/r/ethereum/comments/8cdqi8/restore_co...](https://www.reddit.com/r/ethereum/comments/8cdqi8/restore_contract_code_at/)

This change has no consensus like the DAO fix did, and the problem it fixes is both negligible and self inflicted.

<comment><USER17> Points made there:

1) The proposed transaction is a dilution. It reduces the value of everyone else's Ether by a payout to Parity.

2) Businesses which use the Etherium system but aren't closely associated with the insiders are at a disadvantage when the insiders can recover from their mistakes, but outsiders cannot.

<comment><USER18> Curious why people think so w.r.t. (2). Anyone can submit a proposal.

<comment><USER19> for the reason he said in (2), insiders like Parity have much better odds of having their EIP accepted.

but it is your proposal so you knew that.

</comment></comment></comment></comment><comment><USER20> Shit like this will kill eth. If anyone seriously working on this (any anyone with any vested interest in shit like this not happening) wants to have an informal chat about fixing this, I think I have some ideas on fixing this. It's quite legit, if I can say so. Check my profile for email.

<comment><USER21> Serious, not at all snarky question:

It seems like the Ether devs will mess with the block chain anytime something happens. This seems like a terrible way to manage one of the unique coins in the crypto space.

With that said, aren't they worried about the risk this conveys to oncomers? Wouldn't anyone think twice if there's going to be a fork anytime someone screws up a contract at large enough magnitude?

<comment><USER22> Ironically, providing a means to reverse disasters is probably good for Etherum; it reduces the number of investors who leave because they've been burned.

<comment><USER23> It also kills one of the main selling points, which is that code = law. If you want human intervention, go with regular contracts.

<comment><USER22> Unfortunately, code = bugs.

<comment><USER24> I claim that the law is much more full of bugs than typical code.

</comment></comment></comment></comment></comment></comment><comment><USER25> It seems like most people in this thread don't understand that this is just a proposal made by the firm that lost funds and there is very little indication that it will be supported either by the Ethereum Foundation or by the community at large.

</comment><comment><USER26> If this is accepted and implemented, could someone explain how Ethereum is a _decentralised_ cryptocurrency?

<comment><USER27> It's not. The Ethereum foundation will continue to merge EIPs like this that benefit them and their cronies.

The whole ETH/ETC fork was because they messed up the DAO contract, which set a precedent for "code is law, except when it doesn't suit us".

<comment><USER15> This EIP has not been enacted via a hard fork and from the looks of it doesn't have the required support.

The ETC fork happened very early and affected some large percentage of available tokens - I think 15% or so.

</comment></comment></comment><comment><USER28> Related PR [https://github.com/ethereum/EIPs/pull/999](https://github.com/ethereum/EIPs/pull/999)

</comment><comment><USER29> Is the affected associates of Vitalik, the benevolent dictator of Ethereum? Then this may get in.

I mention this because the DAO losses were address by a hard fork.

If enough money is at stake it would be advantageous for Vitalik and other core maintainers to allow for people to pay on getting their PRs accepted. This PR would restore I understand about >$100M in funds. This type of patch is surely worth money in order to accept.

At least if Vitalik and friends took money in order to do these types of arbitrary patch PRs to fix other people's problems, then it would at least be a fair playing field.

Is Vitalik and other core maintainers already getting paid by the people proposing these types of PRs?

<comment><USER30> If you believe a system where people with more money get more votes to be fair.

<comment><USER29> At least it wouldn't be based on who Vitalik knows personally. I would rather a transparent system that operates with known principles rather than one that is arbitrary and based on knowing Vitalik.

</comment></comment></comment><comment><USER31> I know it's not a very popular opinion but I think this is a good idea (disclaimer: i am not affected by this issue). The tech is there for the people, not the other way round.

<comment><USER32> On the other hand, if you want human arbitration of contracts, then it seems like that is already available outside the crypto space.

It's not a cut-and-dried issue, but personally I do tend towards the view that interfering in contracts via hard forks undermines the credibility of the whole idea behind smart contracts. As it is, it seems smart contracts simply do not work as they should. They seem to be vulnerable to both technical _and_ political risks, which is actually worse than a regular contract.

<comment><USER31> It would be part of a planned hard fork (for other reasons). There will not be a hard fork just for this issue.

</comment></comment></comment><comment><USER33> I'm still aghast that "smart contracts" are procedural programs. No wonder a lot of bugs derive from them.

Contracts are functional, being procedural should be the exception.

They should be functional, scoped, limited (by the VM inclusive), testable.

<comment><USER34> The Ethereum VM accepts opcodes like any other modern computing platform. There's a lot of work going into formal verification of contract code. There's nothing in principle that prevents compilation of smart contracts into VM code via a formally verified compiler that implements a functional language.

<comment><USER35> Except the majority of the Ethereum community being ideologically opposed...

<comment><USER36> I'm an Ethereum smart contract dev/auditor and active in the community. I'm not aware of any ideological opposition to more functional or verifiable languages.

In fact, there are several new languages in development to move things in that direction, including Vyper (originally designed by Vitalik) and Bamboo (designed by the person employed by the EF to work on formal verification).

<comment><USER35> My experience proposing actual use of these has been met with complaint and actual jeers in social circles. Further, it's pretty depressing that you suggest Vyper and Bamboo actually offer more formal verification or even correctness.

I don't see either trying to adopt approaches more like Simplicity.

</comment></comment></comment></comment></comment><comment><USER37> I propose to roll Ethereum price back to 2015 for just a day, as a lot of people I know missed it and didn't manage to buy.

</comment><comment><USER38> No. Just No. This is no different than the bank bailouts that inspired the creation of cryptocurrency. Is Parity too big to fail? If the answer is 'yes', then It's ime to convert all your ETH to ETC.

</comment><comment><USER39> Can someone explain this in terms understandable to a software engineer with familiarity with cryptocurrency in general but no specific knowledge of ETH?

<comment><AUTHOR> Ethereum is sort of like Bitcoin, but includes a Turing-complete scripting language. Programs written in this language are called "smart contracts", and can do a much wider range of things than simply dealing with currency.

One of the core principles of blockchain technology is immutability - that is, once a transaction becomes part of a blockchain, it stays there forever and can never be undone. In the case of Ethereum, this also includes smart contracts.

An advantage of immutable contracts is that users can trust that it will always operate in exactly the way the code was written, and the developer who wrote the contract cannot change the rules, or alter the "terms of service" as so often happens in centralised systems. A disadvantage of immutable contracts is that if there is a bug in the code, it remains there permanently and can never be fixed. In this particular case, there was a bug that allowed someone to instruct the contract to "self destruct" (refuse to process any more transactions), thereby locking away a large amount of ETH.

EIP stands for Ethereum Improvement Proposal. This particular proposal (which, as I understand, has not yet been accepted) would alter the Ethereum protocol to handle this specific contract address specially in such a way that reverses effects of the unintended self-destruction, allowing the lost funds to be recovered. This goes against the principle that the blockchain must be immutable, otherwise known as "code is law".

Breaking immutability in such a manner is highly controversial; the debate is about whether the development team should make a one-off fix for this particular case because a lot of people lost a lot of money (or rather ETH), or whether they should leave things as-is to avoid destroying trust in Ethereum's promise of immutability.

This has happened previously on one occasion; see [https://en.wikipedia.org/wiki/The_DAO_(organization)](https://en.wikipedia.org/wiki/The_DAO_\(organization\))

<comment><USER40> While I disagreed with the DAO fork and disagree with this EIP, neither of them changed immutability. The problematic transactions are still there. These are irregular state transitions that are normally illegal but are hardcoded to be allowed as special one-off favors.

</comment></comment></comment><comment><USER41> I'm shocked, SHOCKED, to see that what the banking system has realised hundreds or thousands of years ago, that sometimes things go wrong and you need to undo it, is actually true. Cryptocurrencies deliberately design around what society has _deliberately_ put in place, because _that 's what we want_.

</comment><comment><USER42> Problems like this are a critical flaw in cryptocurrencies. When something goes horribly wrong, who do you go to for help? You don't have a right to recourse with cryptocurrencies. With real money, you have legal rights that can be exercised by simply filing a complaint with the bank. If that doesn't go well, you go to the regulatory agencies or the courts.

Furthermore, if you do succeed in getting help from the community/central committee then you just defeated a goal of cryptocurrencies. Taken directly from the first paragraph of the homepage of the Ethereum website [0]:

> Ethereum is a decentralized platform that runs smart contracts: applications > that run exactly as programmed without any possibility of downtime, > censorship, fraud or third-party interference.

[0]: [https://www.ethereum.org/](https://www.ethereum.org/)

<comment><USER34> Remember, however, that's there's nothing about "real" money that intrinsically bestows upon its users some set of legal rights. Traditional currency users have legal rights because the legal system has had enough time to evolve to handle them properly. A lot of current crypto systems don't specifically include mechanisms for recovery of funds (and, as you point out, many of them claim this shouldn't happen) but that doesn't mean it's not technically possible somehow.

</comment></comment><comment><USER43> Can someone explain where the balance is?

[https://etherscan.io/address/0x863df6bfa4469f3ead0be8f9f2aae...](https://etherscan.io/address/0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4)

<comment> ryan-c My understanding is that contract code is a "library" of sorts, that was imported or called by parity multisig wallets.

<comment><USER18> Exactly. It is the library used by hundreds of wallets. The library itself does not hold any balance.

</comment></comment></comment><comment><USER44> Assuming that in the future most businesses use crytocurrencies (which I think we can all agree on would be awesome and better than what exists), they will need to be able to access their money even if they make a mistake.

We're not taking money from you or I and giving it to a failing institution (a bailout). We are setting up a procedure so that when mistakes are inevitably made, someone can still access their funds.

After all we all agree it is all of these company's funds, right?

</comment><comment><USER45> A relevant earlier EIP, which I assume this conforms to:

> Provide a standardized format for Ethereum Recovery Proposals (ERPs), which > relate to recovery of certain classes of lost funds. Individual ERPs will > follow the same process as any EIP, but will be formatted and evaluated in a > standard way to ensure consistency and transparency.

<comment><USER18> EIP 867 which you are referring to is in limbo, this is not conforming with the ERP.

</comment></comment><comment><USER46> How is this different from the Federal Reserve and Treasury deciding to "save" Bear Stearns but not Lehman?

</comment><comment><USER47> Is it time for a second ETC fork ?

</comment><comment><USER48> this post breaks hacker news mobile page to scroll horizontal

</comment><comment><USER49> The future is weird.

</comment><comment><USER50> This is corruption.

</comment><comment><USER51> is there a reason eth's contracts aren't coded in haskell or similar</comment>


Carnival Cruises emits ten times more sulphur oxide than all of Europe's cars - <AUTHOR> https://ecohustler.com/article/one-corporation-to-pollute-them-all/ <comment><USER3> It would be interesting to compare Carnival to the actual freight/crude vessels.

I have to imagine that all of that dwarfs carnival by a wide, wide margin.

But with flags of convenience, this is actually a semi-tough battle to fight, as they'll just reregister the ships somewhere else.

The low sulphur regulations coming into force in 2020 should help quite a bit in that these ships will have to burn cleaner fuel at the very least.

<comment><USER4> Does it matter how the ship is flagged? I could imagine solutions like, "If you dock in Europe and your ship is out of compliance, you must pay $X in fines." You can tune $X to whatever is needed to cover the calculated negative externalities.

<comment><USER5> This is the way it is in several Europen cities (if not all). The cruise ships burn very pollutingly fuels while in "international waters" but when they enter a port they are required to use cleaner fuel. Those regulations are there.

But nothing regulates what they do in international waters.

<comment><USER6> Couldn't they be required to turn over logs of fuel (type? uncertain how it works) use along with some form of inspections?

<comment><USER7> By definition the port of arrival has no jurisdiction on what the ship does in international waters.

<comment><USER8> No, but they're also under no obligation to allow the ship to dock. Any ability to enforce standards ultimately derives from this option.

</comment></comment></comment></comment></comment></comment><comment><USER9> Sounds bad - but is this a fair comparison?

Each cruise ship takes thousands of people all year round, who otherwise would go on holiday somewhere else (probably somewhere far away given the cost of a cruise). You need to do a total comparison of the pollution emitted by the cruise-style holidays vs going on long-haul holidays elsewhere and sum that up to see whether Carnival are really causing 10x more environmental problems than European cars.

I suspect they are but would rather see more valid comparisons that are harder to refute as the headline.

<comment><USER10> If you read the article, you quickly discover it's not a fair comparison at all, because the headline itself is grossly misleading.

<comment><USER11> The article only talks about sulphur which is a small part of emissions - <USER2> do they compare in other pollutants? Since it hasn't been mentioned, I bet they do much better...

</comment></comment></comment><comment><USER12> I'm curious whether luxury/recreational users of bunker fuel like cruise ships will receive more scrutiny and legislation than cargo and tanker ships. It's easy to scoff at the cruise industry and at people who go on cruises as environmentally insensitive, harder to bring about an increase in shipping costs.

Also, it's 10x the SOx, not 10x the CO2. Here's the source publication, which also analyzes NOx and PM, with a bit of CO2 data mixed in:

[https://www.transportenvironment.org/sites/te/files/publicat...](https://www.transportenvironment.org/sites/te/files/publications/One%20Corporation%20to%20Pollute%20Them%20All_English.pdf)

(As you might guess, the source article is not unbiased...)

</comment><comment><USER13> Look for "Marine Cloud Brightening" and "ship tracks". Dirty fuels contribute to low cloud formation -- these are known to partially mitigate warming effects.

The opportunity is to design a jet to spray salt water off the back of cargo ships to optimize marine cloud formation/brightening around the world. This is one of the most palatable geoengineering solutions out there.

[https://royalsocietypublishing.org/doi/full/10.1098/rsta.201...](https://royalsocietypublishing.org/doi/full/10.1098/rsta.2014.0053)

<comment><AUTHOR> As a software engineer I am really scared of all these geo-engineering solutions. There is no integration environment to test them.

<comment><USER14> "We'll test it in production."

<comment><USER15> #yolo it you mean? I think we only have one livable planet atm

</comment></comment></comment></comment><comment><USER16> According to USA today ([https://www.usatoday.com/story/tech/science/2018/01/22/creat...](https://www.usatoday.com/story/tech/science/2018/01/22/creating- clouds-stop-global-warming-could-wreak-havoc/1054026001/)), scientists want to spray Sulfur oxide into the atmosphere to _stop_ global warming, so all I'm taking from this article is that we need to cruise more?

<comment><USER17> Whenever an article or person says "scientists want to..." or "scientists say..." it usually means that somewhere there is a team who has written a paper with that opinion, and that it is nowhere close to a consensus opinion. I'm quite sure there are many other scientists who will say doing so would be disastrous.

So, in short, try not to be swayed too much by what one researcher says, as filtered through the attention grabbing filter of a lay newspaper.

<comment><USER16> So as someone trained in the sciences, I'm well aware of this. The fact is that sulphur oxide is not a contributor to global warming, and I wanted to post an accessible article expressing this fact for those who are swayed by similar articles, like the one posted

<comment><USER18> As a scientist you will be aware that the devil is the in the detail. SO2 contributes to aerosol formation which can either warm (through absorption of solar radiation on dark particles) or cool (from forming cloud droplets and reflecting radiation) the atmosphere. SO2 emissions at ground level are usually classified as indirect contributors of warming

The article you posted talked about SO2 in the stratosphere - where cloud formation occurs. Cruise ships typically operate at sea level.

</comment></comment></comment></comment><comment><USER19> It would be easy to fix this with regulation like European Sulphur Emission Control Area (SECA) does.

Installing scrubbers and cleaner fuel or moving into LNG are options. They add only little to the price of the ship.

</comment><comment><USER20> The article says "Emits more pollution than all of Europe's Cars", which is a bit of a garbage claim, because obviously all of the CO2 is coming from the cars.

<comment><USER21> > _" obviously all of the CO2 is coming from the cars."_

Wait, how do ships eliminate their CO2 emissions?

Re:

> _" A ship, burning 1 litre of bunker oil produces about as much CO2 as a car > burning 1 litre of gasoline"_

If burning bunker oil produces CO2, as I would expect it does, then obviously all of the CO2 is _not_ coming from cars.

I understand making _' broadly true but strictly speaking flat wrong'_ generalized statements, but to do that in the same breath as criticizing somebody for making "garbage claims" seems... I don't know, worthy of note I guess.

<comment><USER22> A ship, burning 1 litre of bunker oil produces about as much CO2 as a car burning 1 litre of gasoline, but tens of thousands of times more NO2 and SO2.

</comment></comment></comment><comment><USER23> How does this rank in the grand scheme of greenhouse gases? Not that it doesn't still matter, but efforts should be focused on climate change as a whole, not a single cherry-picked gas.

<comment><USER22> In terms of GHGs, cars dwarf cruise ship traffic.

In terms of SO2 and NO2 pollutants, cars burn very clean fuel, very efficiently, with a catalytic converter to scrub their exhaust. Ships run on shitty bunker oil, which is just one step above combustible sludge on the purity scale... And aren't equipped with catalytic converters.

The thing is, even if you legislate that ships can't run on bunker oil in your territorial waters, they'll just run on it while at sea, and switch to a legislated fuel when they dock.

<comment><USER24> Surely an entity such as the EU could go so far as to ban the sale of bunker oil to passenger cruise lines with offices in the EU, or something to that effect?

<comment><USER25> Or just ban companies that use it from operating in the EU

</comment></comment></comment></comment><comment><USER26> It's too bad they can't be nuclear powered.

<comment><USER27> Even if companies had to hire teams of government employees to handle/run the reactors, this still would be an excellent idea. It's a shame it will never happen.

</comment></comment><comment><USER28> Cruise ship manufacturers should do more, but I'd like to see the emissions comparison of those thousands of customers flying to their destinations, then taking small vehicles to reach final destinations.

<comment><USER29> People fly to cruises so frequently that it is part of a the package system.

</comment></comment><comment><USER30> How does what Carnival do with sulfur compare with (i) the rest of shipping, (ii) the rest of human activity, and (iii) volcanoes????

</comment><comment><USER31> Look up the EU Sulphur Directive 2012/33/EU please before writing such rubbish about European waters.

</comment><comment><USER32> Don't sulfur oxides act to increase the Earth's albedo and decrease global warming?

</comment><comment><USER33> If we really meant it with climate policies, cruise ships and private jets would be banned immediately.

<comment><USER34> I oppose banning anything... We just need to take the externalities (costs incured on the environment/population/other stake holders that are currently not included) into account and tax products/services accordingly.

That way, you both (1) reduce the environmental impact, and (2) encourage development of newer, cleaner technologies.

<comment><USER35> Taxing them out of existence isn't any different from banning them.

<comment><USER36> Taxing them to recoup carbon emissions would only reduce air travel, not eliminate all carriers.

Say that it gets 5x or 10x more expensive, there would still be flights, just far less common. And maybe then something like biokerosene becomes cost effective, driving down costs more.

<comment><USER37> Just want to throw it out there that your typical passenger airline operates at a 2.5% margin. Freight airlines are even less. That multiplayer is going directly to consumers.

Nobody wants a world where we're paying $50 to ship a package, $1000 for a short flight, or their grocery bill to double since transportation is most of the cost.

<comment><USER38> The point of carbon taxes is that it captures externalities. To use some real numbers, instead of "$50 a package"; a fully capturing carbon tax on gasoline would raise its cost between $1-$3 a gallon.

People would scream, but the point is that WE'RE ALREADY PAYING $1-$3 a gallon for our CO2. It's just that it's not the driver that's paying, it's people in areas vulnerable to climate change and future generations.

<comment><USER37> I'm not saying we don't pay for it, but discouraging consumption by taxing usage directly at the pump or indirectly at the drill will end up doing more harm than good for our economy.

<comment><USER38> Having Florida sink into the ocean will do more harm to our economy than paying a couple dollars more at the pump.

<comment><USER37> Sounds small when it's the price of a single fill up but $3/gallon would cost US drivers about $500 billion annually and that's before the second order effects of making basically every single good and service more expensive along with it.

I mean losing Florida outright would cost $1 trillion annually so you got me there. As long as we keep half of Florida we're probably good though.

Let that sink in. $3/gallon is about the same as losing the entirety of Ohio. There's a reason we fight wars over this stuff. I desperately want to be better to our environment but these kinds of 'simple solutions' can't possibly work in isolation. Reducing consumption sounds nice until you remember all the people whose lives depend on that consumption to live.

<comment><USER38> It's not a $500 billion loss.

That $500 billion would be spent on something (consumer rebate, carbon sequestration, debt repayment, something). And government spending has second order effects too, estimated at about 1.75x for direct consumer rebates, less for anything else. So it's possible that the carbon tax would have a net positive on the economy.

Even if it isn't a net positive by itself, the net effect will be a LOT less than $500B.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Carnival emits 10x the amount of _one specific pollutant_.

This is a seriously and intentionally misleading headline. Not to diminish the problem, which absolutely should be addressed, but the headline is journalistic malpractice.

<comment><USER9> I think these kinds of headlines are very damaging to the perception of science. They often erase trust and make the public feel disengaged.

<comment><USER39> I have this suspicion that it's intentional. If I were trying to sow doubt about climate change, this sort of article is exactly what I'd push.

</comment></comment></comment><comment><USER40> The devil is, as always, in the detail. Here, the 'air pollution' is oxides of sulphur, which are a consequence of the use of nearly regulation free dirty bunker fuel by ships.

If the measurement is CO2, or other pollutants, it's almost certainly less bad comparatively (though in no way clean).

</comment><comment><USER41> Interestingly I believe the sulphur oxide actually acts to decrease global warming so ...</comment>


Ask HN: Please Review my app - TwitterBatcher.com - <AUTHOR>

Dear HN community, I made an app to satisfy a personal need concerning Twitter. I found it was convenient to upload a bunch of text containing twitter IDs (@accounts) rather than add them manually.
It's pretty handy on Follow Friday to follow recommended friends of friends.
So, to solve this simple problem I made a simple app.
I don't know if many of you have a Twitter account but, I would definitly love to have your feedback about this project HN community.
ps. It uses OpenAuth for authentication, no worries for your data.
Edit: You may encounter failwhales... Keep retrying. <comment><USER2> Clickable link: <http://twitterbatcher.com/>

I love that despite it being a simple app for a simple problem, you've really thought about the UI and design. It does what it says on the tin, and does it well.

I would have liked an extra step after submitting my @users—a list of the users with their full name, their twitter icon, and whether or not they were already following me. This would give me a chance to confirm my choices and correct any mistakes.

Also when I submit a garbage ID like @cyvubinjsoidjajwld I am told "You are already following these Tweeps." rather than that they don't exist.

Good job :)

<comment><AUTHOR> Hello Dave,

Thanks for your appreciation! Having an interstitial page with basic list management before submiting is a great idea. I'll add it on my TODO.

I never tried to submit garbage :) I'll check the Twitter API answer on this one, thanks for spotting it !

Any idea for stats or derived service that can add value to the app ?

Anyway great thanks for your feedback Dave.

</comment></comment><comment><USER3> I'd only suggest that your introductory text does a better job of explaining what the app actually does. I saw the website before I saw your description -- it obviously solves a problem, but I wasn't sure what the problem was until I read your description here.

<comment><AUTHOR> That's insightful! Thanks for your feedback.</comment></comment>