Regulation and decentralization: Defending the blockchain

Andreas Antonopoulos urges the Canadian Senate to resist the temptation to centralize bitcoin.

Editor’s note: our O’Reilly Radar Summit: Bitcoin & the Blockchain will take place on January 27, 2015, at Fort Mason in San Francisco. Andreas Antonopoulos, Vitalik Buterin, Naval Ravikant, and Bill Janeway are but a few of the confirmed speakers for the event. Learn more about the event and reserve your ticket here.

We recently announced a Radar summit on present and future applications of cryptocurrencies and blockchain technologies. In a webcast presentation one of our program chairs, Kieren James-Lubin, observed that we’re very much in the early days of these technologies. He also noted that the technologies are complex enough that most users will rely on service providers (like wallets) to securely store, transfer, and receive cryptocurrencies.

As some of these service providers reach a certain scale, they will start coming under the scrutiny of regulators. Certain tenets are likely to remain: currencies require continuous liquidity and large financial institutions need access to the lender of last resort.

There are also cultural norms that take time to change. Take the example of notaries, whose services seem amenable to being replaced by blockchain technologies. Such a wholesale change would entail adjusting rules and norms across localities, which means going up against the lobbying efforts of established incumbents.

One way to sway regulators and skeptics is to point out that the decentralized nature of the (bitcoin) blockchain can unlock innovation in financial services and other industries. Mastering Bitcoin author Andreas Antonopoulos did a masterful job highlighting this in his recent testimony before the Canadian Senate:

“Traditional models for financial payment networks and banking rely on centralized control in order to provide security. The architecture of a traditional financial network is built around a central authority, such as a clearinghouse. As a result, security and authority have to be vested in that central actor. The resulting security model looks like a series of concentric circles with very limited access to the center and increasing access as we move farther away from the center. However, even the most outermost circle cannot afford open access.

Read more…

Comment

Hardware is an elusive constraint on user experience

Andrew “bunnie” Huang on understanding the interplay between software, hardware, and the existing supply chain.

Editor’s note: this interview with Andrew “bunnie” Huang is an excerpt from our recent report, When Hardware Meets Software, by Mike Barlow. The report looks into the new hardware movement, telling its story through the people who are building it. For more stories on the evolving relationship between software and hardware, download the free report.

Andrew “bunnie” Huang has a Ph.D. in electrical engineering from MIT, but he is most famous for reverse engineering the Xbox, establishing his reputation as one of the world’s greatest hardware hackers. He sees an evolving relationship between hardware and software.

“It used to be that products were limited solely by the capability of their hardware. Early radios, for example, had mechanical buttons that acted directly on the physics of the receiver,” says Huang. “As hardware becomes more capable, the user experience of the hardware is more dictated by the software that runs on it. Now that hardware is ridiculously capable — you basically have supercomputers in your pockets that cost next to nothing — pretty much the entire user experience of the product is dictated by the software. The hardware simply serves as an elusive constraint on the user experience.”

Hardware is “a cage,” says Huang, and good software developers learn to work within the constraints of the hardware. “When I work with programmers on new products, I take the first prototype, put it on the desk and I say, ‘Welcome to your new cage.’ That’s the reality. There’s a hard wall. But we try to build the cage big enough so there are options for programmers. A quad core Android phone with a gigabyte of memory is a pretty big cage. Sometimes when programmers feel constrained, they’re just being lazy. There’s always more than one way to skin a cat in the software world.” Read more…

Comment

Cheap sensors, fast networks, and distributed computing

The history of computing has been a constant pendulum — that pendulum is now swinging back toward distribution.

Editor’s note: this is an excerpt from our new report Data: Emerging Trends and Technologies, by Alistair Croll. You can download the free report here.

The trifecta of cheap sensors, fast networks, and distributing computing are changing how we work with data. But making sense of all that data takes help, which is arriving in the form of machine learning. Here’s one view of how that might play out.

Clouds, edges, fog, and the pendulum of distributed computing

The history of computing has been a constant pendulum, swinging between centralization and distribution.

The first computers filled rooms, and operators were physically within them, switching toggles and turning wheels. Then came mainframes, which were centralized, with dumb terminals.

As the cost of computing dropped and the applications became more democratized, user interfaces mattered more. The smarter clients at the edge became the first personal computers; many broke free of the network entirely. The client got the glory; the server merely handled queries.

Once the web arrived, we centralized again. LAMP (Linux, Apache, MySQL, PHP) buried deep inside data centers, with the computer at the other end of the connection relegated to little more than a smart terminal rendering HTML. Load-balancers sprayed traffic across thousands of cheap machines. Eventually, the web turned from static sites to complex software as a service (SaaS) applications.

Then the pendulum swung back to the edge, and the clients got smart again. First with AJAX, Java, and Flash; then in the form of mobile apps, where the smartphone or tablet did most of the hard work and the back end was a communications channel for reporting the results of local action. Read more…

Comment

Pace of change as a metaphor for full-stack design

Jeff Veen on design teams, flat design and skinny jeans, and full-stack design.

I recently sat down with Jeff Veen, vice president of products at Adobe, and CEO and founder of Typekit. Veen has been a designer for more than 20 years; he is an entrepreneur, writer, cyclist, and lover of burritos. His resume includes Adaptive Path; Wired; WebMonkey; Google; and TypeKit, which was acquired by Adobe. Our conversation covered leadership, hiring designers, and the significance of trends.

Design’s leading role

Design is finally receiving the attention and respect of non-designers. Veen talks about a different dynamic, one in which design plays a leading role in the development of products and services:

“The analogy I always give is that when we started Adaptive Path in 2001, one of our stated values was to have design get a seat at the table, and we meant the board table — like the C level. I feel it is entirely possible to have your own table as a designer and invite other people to have their seats. That is still the exception to the rule, which is probably fine; it probably maps to the wide variety of businesses and products that are out there. But increasingly so, the kind of thinking beind the analytical process and the types of problem solving that designers are particularly good at tends to fit well with the kind of digital interactive, largely consumer-based product development that we’re doing these days.

“I think to embrace design means that you need to populate your company with leadership that has a design background. That is a true signifier — not like, “You know, we should hire a couple of designers. We should spruce up the website,” but really investing in design. Where is the leadership? Where’s the decision-making for the priorities, for the direction and vision of not just the product but the company itself? Where is that embodied? Is it embodied at the same level that a good engineer is? It obviously needs to be. [It’s a sign that] a company understands the value of design.”

Read more…

Comment

Designers are engineers

Dirk Knemeyer on the changing role of design in emerging technology.

downward_spiral_qthomasbower_Flickr

The discipline of design is morphing. Designers’ roles and responsibilities are expanding at a tremendous pace. Jonathan Follett, editor of Designing for Emerging Technologies recently sat down with Dirk Knemeyer, founder of Involution Studios, who contributed to the book. Knemeyer discusses the changing role of design and designers in emerging technology.

Changing roles: Designers as engineers

Knemeyer explains the morphing role of designers as technologies advance and disciplines overlap. Designers are expected to have skills or working knowledge of topics well outside design, including programming and industrial design:

“We’re already seeing a convergence of engineering and design. We’ve been talking about it for a decade, that designers need to know how to code. Designers get it, and they’re out there and they’re learning to code. To remain relevant, to remain a meaningful part of the creationary process in these more complicated contexts, that’s only going to accelerate. Designers are going to need to see themselves as engineers, maybe as much, if not more, than as designers in order to be relevant in participating in the design and creation processes within the world of emerging technologies.”

Read more…

Comment

One more word on drones: Warehouses

Drones might never find meaningful retail delivery work, but they might find practical employment in warehouses.

After writing my short post about the use of drones to deliver packages, it occurred to me that there’s one more realistic use case. Unfortunately (or not), this is a use case that you’ll never see if you’re not an Amazon employee. But I think it’s very realistic. And obviously, I just can’t get drones out of my head.

As I argued, I don’t think you’ll see drones for retail delivery, except perhaps as a high-cost, very conspicuous consumption frill. What could get more conspicuous? Drone pilots are expensive, and I don’t think we’ll see regulations that allow autonomous drones flying in public airspace any time soon. Drones also aren’t terribly fast, and even if you assume that the warehouses are relatively close to the customers, the number of trips a drone can make per hour are limited. There’s also liability, weather conditions, neighbors shooting the drones down, and plenty of other drawbacks.

These problems all disappear if you limit your use of drones to the warehouse itself. Don’t send the drone to the customer: that’s a significant risk for an expensive piece of equipment. Instead, use the drones within the warehouse to deliver items to the packers. Weather isn’t an issue. Regulation isn’t an issue; the FAA doesn’t care what you do inside your building. Autonomous flight isn’t just a realistic option, it’s preferable: one massive computing system can coordinate and optimize the flight paths of all the drones. Amazon probably has some of that system built already for its Kiva robots, and Amazon is rather good at building large computing architectures. Distance isn’t an issue. Warehouses are big, but they’re not that big, and something (or someone) has to bring the product to the packing station, whether it’s a human runner or a Kiva robot. Read more…

Comments: 2