Decentralyze
type: channel
description: Designing for Practical Decentralization
date: 2017-06-20T12:23:34Z
update period: hourly
update frequency: 1
update base: 2000-01-01T12:00+00:00
generator agent: wordpress.com
items: Ridesharing 3.0: Forget About Uber
items: Back to Blogging
items: GrowJSON
items: The Web is like Beer
items: NSA Certified
items: Fix 303 with client-side redirects
items: RDF Steps Carefully Forward
items: Elevator Pitch for the Semantic Web
items: Can we use Lean Startup methods to build the Semantic Web?
items: Simplified RDF

Ridesharing 3.0: Forget About Uber
type: item
creator: sandhawke
date: 2017-06-18T14:30:11Z
subject: Web Architecture
description: [Most] solutions [to the Uber problems] are pushing water uphill, because people actually like the service. I have another solution: let’s rebuild the service without any major company involved. Let’s help software eat the world on behalf of the users, not the stockholders.
encoded: Uber, whatever its faults, provides value to its users, both the drivers and the riders. People appreciate or even enjoy the service, even if they don’t like the corporate behavior or economic disruption. Solutions seem to mostly include boycotts (in favor of taxis or competitors like Lyft) and legal action. But most of those those solutions are pushing water uphill, because people actually like the service. I have another solution: let’s rebuild the service without any major company involved. Let’s help software eat the world on behalf of the users, not the stockholders. In this post, I’ll explain a way to do it. It’s certainly not trivial, and has some risks, but I think it’s possible and would be a good thing. The basic idea is similar to this: riders post to social media describing the rides they want, and drivers post about the rides they are available to give. They each look around their extended social graph for posts that line up with what they want, and also check for reasons to trust or distrust each other. That’s about it. You could do this today on Twitter, but it would take some decent software to make it pleasant and reliable, to make the user experience as good as with Uber. To be clear: I’m aiming for a user experience similar to the Uber app; I’m proposing using social media as an underlying layer, not a UI. What’s deeply different in this model is the provider of the software does not control the market. If I build this today and get millions of users, someone else can come along tomorrow with a slightly better interface or nicer ads, and the customers can move easily, even in the middle of a ride. In particular, the upstart doesn’t need to convince all the riders and driver to switch in order to bootstrap their system! The market, with all its relationships and data are outside the ridesharing system. As a user, you wouldn’t even know what software the other riders and drivers are be using, unless they choose to tell you. With this approach, open …

Back to Blogging
type: item
creator: sandhawke
date: 2017-06-16T18:32:10Z
subject: Uncategorized
description: As I remember it, about ten years ago, I started this blog for one main reason. I had just watched a talk from the CTO of Second Life (remember them, when they were hot?) about his vision for how to expand by opening up the system, making it decentralized. I thought to myself: that’s going […]
encoded: As I remember it, about ten years ago, I started this blog for one main reason. I had just watched a talk from the CTO of Second Life (remember them, when they were hot?) about his vision for how to expand by opening up the system, making it decentralized. I thought to myself: that’s going to be really hard, but I’ve thought about it a lot; I should blog my ideas about it. As I dug into the problem, however, I realized how many sub-problems I couldn’t really solve, yet. So I never posted. (Soon thereafter, Cory Ondrejka left the Second Life project, moving on to run engineering at Facebook. Not sure if that’s ironic.) Now, what feels like several lifetimes later, I’m ready to try again. This time the “industry darling” I want to tackle first is Uber. Okay, it’s already become widely hated, but the valuation is still, shall we say, … considerable. So, coming soon: how to decentralized Uber.

GrowJSON
type: item
creator: sandhawke
date: 2014-06-30T21:17:56Z
subject: Uncategorized
description: I have an idea that I think is very important but I haven’t yet polished to the point where I’m comfortable sharing it. I’m going to share it anyway, unpolished, because I think it’s that useful. So here I am, handing you a dull, gray stone, and I’m saying there’s a diamond inside. Maybe even […]
encoded: I have an idea that I think is very important but I haven’t yet polished to the point where I’m comfortable sharing it. I’m going to share it anyway, unpolished, because I think it’s that useful. So here I am, handing you a dull, gray stone, and I’m saying there’s a diamond inside. Maybe even a dilithium crystal. My hope is that a few experts will see what I see and help me safely extract it. Or maybe someone has already extracted it, and they can just show me. The problem I’m trying to solve is at the core of decentralized (or loosely-coupled) systems. When you have an overall system (like the Web) composed of many subsystems which are managed on their own authority (websites), how can you add new features to the system without someone coordinating the changes? RDF offers a solution to this, but it turns out to be pretty hard to put into practice. As I was thinking about how to make that easier, I realized my solution works independently of the rest of RDF. It can be applied to JSON, XML, or whatever. For now, I’m going to start with JSON. Consider two on-the-web temperature sensors: > GET /temp HTTP/1.1 > Host: paris.example.org > Accept: text/json > < HTTP/1.1 200 OK < Content-Type: text/json < {"temp":35.2} > GET /temp HTTP/1.1 > Host: berkeley.example.org > Accept: text/json > < HTTP/1.1 200 OK < Content-Type: text/json < {"temp":35.2} The careful human reader will immediately wonder whether these temperatures are in Celcius or Fahrenheit, or if maybe the first is in Celcius and the second Fahrenheit. This is a trivial example of a much deeper problem. Here’s the first sketch of my solution: > GET /temp HTTP/1.1 > Host: paris.example.org > Accept: text/json > < HTTP/1.1 200 OK < Content-Type: text/json < [ {"GrowJSONVersion": 0.1, "defs": { "temp": "The temperature in degrees Fahrenheit as measured by a sensor and expressed as a JSON number" }, {"temp":35.2} ] > GET /temp HTTP/1.1 > Host: berkeley.example.org > Accept: text/json > < HTTP/1.1 200 OK < Content-Ty…

The Web is like Beer
type: item
creator: sandhawke
date: 2014-03-11T13:28:09Z
subject: Uncategorized
description: Lots of people can’t seem to understand the relationship of the Web to the Internet. So I’ve come up with a simple analogy: The Web is to the Internet as Beer is to Alcohol. For some people, sometimes, they are essentially synonymous, because they are often encountered together. But of course they are fundamentally different […]
encoded: Lots of people can’t seem to understand the relationship of the Web to the Internet. So I’ve come up with a simple analogy: The Web is to the Internet as Beer is to Alcohol. For some people, sometimes, they are essentially synonymous, because they are often encountered together. But of course they are fundamentally different things In this analogy, Email is like Wine: it’s the other universally popular use of the Internet/Alcohol. But there are lots of other uses, too, somewhat more obscure. We could say the various chat protocols are the various Whiskeys. IRC is Scotch; XMPP is Bourbon. gopher is obscure and obsolete, …. maybe melomel. ssh is potato vodka. I leave the rest to your imagination. Note that the non-technician never encounters raw Internet, just like they never encounter pure alcohol. They wouldn’t know what it was if it stepped on their foot. Of course, chemists are quite familiar with pure alcohol, and network technicians and programmers are familiar with TCP, UDP, and IP. The familiar smell of alcohol, that you can detect to some degree in nearly everything containing alcohol — that’s DNS.

NSA Certified
type: item
creator: sandhawke
date: 2014-02-27T14:53:22Z
subject: Uncategorized
description: The world of computing has a huge problem with surveillance. Whether you blame the governments doing it or the whistleblowers revealing it, the fact is that consumer adoption and satisfaction is being inhibited by an entirely-justified lack of trust in the systems. Here’s how the NSA can fix that, increase the safety of Americans, and, […]
encoded: The world of computing has a huge problem with surveillance. Whether you blame the governments doing it or the whistleblowers revealing it, the fact is that consumer adoption and satisfaction is being inhibited by an entirely-justified lack of trust in the systems. Here’s how the NSA can fix that, increase the safety of Americans, and, I suspect, redeem itself in the eyes of much of the country. It’s a way to act with honor and integrity, without betraying citizens, businesses, or employees. The NSA can keep doing all the things it feel it must to keep America safe (until/unless congress or the administration changes those rules) and by doing this additional thing it would be helping protect us all from the increasing dangers of cyber attacks. And it’s pretty easy. The proposal is this: establish a voluntary certification system, where vendors can submit products and services for confidential NSA review. In concluding its review, the NSA would enumerate for the public all known security vulnerabilities of the item. It would be under no obligation to discover vulnerabilities. Rather, it would simply need to disclose to consumers all the vulnerabilities of which it happens know, at that time and on an ongoing basis, going forward. Vendors could be charged a reasonable fee for this service, perhaps on the order 1% gross revenue for that product. Crucially, the NSA would accept civil liability for any accidental misleading of consumers in its review statements. Even more important: the NSA chain of command from the top down to the people doing the review would accept criminal liability for any intentionally misleading statements, including omissions. I am not a lawyer, but I think this could be done easily by having the statements include sworn affidavits stating both their belief in these statements and their due diligence in searching across the NSA and related entities. I’m sure there are other options too. If congress wants to get involved, I think it might be time …

Fix 303 with client-side redirects
type: item
creator: sandhawke
date: 2012-04-06T20:12:27Z
subject: Uncategorized
description: I am trying to stay far away from the current TAG discussions of httpRange-14 (now just HR14). I did my time, years ago. I came up with the best solution to date: use “303 See Other”. It’s not pretty, but so far it is the best we’ve got. I gather now the can of worms […]
encoded: I am trying to stay far away from the current TAG discussions of httpRange-14 (now just HR14). I did my time, years ago. I came up with the best solution to date: use “303 See Other”. It’s not pretty, but so far it is the best we’ve got. I gather now the can of worms is open again. I’m not really hungry for worms, but someone mentioned that the reason it’s open again is that use of 303 is just too inefficient. And if that’s the only problem, I think I know the answer. If a site is doing a lot of redirects, in a consistent pattern, it should publish its rewrite rules, so the clients can do them locally. Here’s a strawman proposal: We define an RFC 5785 well-known URI pattern: .well-known/rewrite-rules . At this location, on each host, the host can publish some of its rewrite and redirection rules. The syntax is a tiny subset of the Apache RewriteRule syntax. For example: # We moved /team to /staff RewriteRule /team/(.*) /staff/$1 301 # All the /id/ pages get 303'd to the doc pages RewriteRule (.*)/id/(.*) $1/doc/$2 303 The syntax here is: comments start with a slash; non-comments have four fields, separated by whitespace. The first field is the word “RewriteRule”. The second is a regular expression. The third is a string with back-references into the regular expression. The fourth is a numeric redirect code. Any line not matching this syntax, or otherwise not understood by the client, is to be ignored. Clients that do not implement this specification will function unchanged, not looking at this file. Clients that do implement this specification keep track of how many times they get an HTTP redirect from a given host. If they get three or more redirects during one small period of time (such as a minute, or one run of the client if the client is short-lived), they perform a GET on /.well-known/rewrite-rules. If the GET succeeds, the result should be cached using normal HTTP caching rules. If the result is not cached, this protocol is less efficient than server-side red…

RDF Steps Carefully Forward
type: item
creator: sandhawke
date: 2011-04-15T00:53:45Z
subject: Uncategorized
description: 18 months ago, when Ivan Herman and I began to plan a new RDF Working Group, I posted my RDF 2 Wishlist. Some people complained that the Semantic Web was not ready for anything different; it was still getting used to RDF 1. I clarified that “RDF 2” would be backward compatible and not break […]
encoded: 18 months ago, when Ivan Herman and I began to plan a new RDF Working Group, I posted my RDF 2 Wishlist. Some people complained that the Semantic Web was not ready for anything different; it was still getting used to RDF 1. I clarified that “RDF 2” would be backward compatible and not break existing system, just like “HTML 5” isn’t breaking the existing Web. Still, some people prefered the term “RDF 1.1”. The group just concluded its first face-to-face meeting, and I think it’s now clear we’re just doing maintenance. If we were to do version numbering, it might be called “RDF 1.0.1”. This might just be “RDF Second Edition”. Basically, the changes will be editorial clarifications and bug fixes. The adventurer in me is disappointed. It’s a bit like opening your birthday present to find nice warm socks, instead of the jet pack you were hoping for. Of course, this was mostly clear from the workshop poll and the charter, but still, I had my hopes. The most dramatic change the group is likely to make: advise people to stop using xs:string in RDF. Pretty exciting. And, despite unanimous support from the 14 people who expressed an opinion in the meeting, there has now been some strong pushback from people not at the meeting. So I think that’s a pretty good measure of the size change we can make. As far as new stuff…. we’ll probably come up with some terminology for talking about graphs, and maybe even a syntax which allows people to express information about graphs and subgraphs. But one could easily view that as just properly providing the functionality that RDF reification was supposed to provide. So, again, it’s just a (rather complicated) bug fix. And yes, making Turtle a REC, but it’s already a de facto standard, so (again) not a big deal. The group also decided, with a bit of disappointment for some, not to actively push for a JSON serialization that appeals to non-RDF-folks. This was something I was interested in (cf JRON) but I agree there’s too much design work to …

Elevator Pitch for the Semantic Web
type: item
creator: sandhawke
date: 2011-02-02T15:03:40Z
subject: Uncategorized
description: SemanticWeb.com invited people to make video elevator pitches for the Semantic Web, focused on the question “What is the Semantic Web?”. I decided to give it a go. I’d love to hear comments from folks who share my motivation, trying to solve this ‘every app is a walled garden’ problem. In case you’re curious, here’s […]
encoded: SemanticWeb.com invited people to make video elevator pitches for the Semantic Web, focused on the question “What is the Semantic Web?”. I decided to give it a go. I’d love to hear comments from folks who share my motivation, trying to solve this ‘every app is a walled garden’ problem. In case you’re curious, here’s the script I’d written down, which turned out to be wayyyy to long for the elevators in my building, and also too long for me to remember. Eric Franzon of SemanticWeb.Com invited people to send in an elevator pitch for the Semantic Web. Here’s mine, aimed at a non-technical audience. I’m Sandro Hawke, and I work for W3C at MIT, but this is entirely my own view. The problem I’m trying to solve comes from the fact that if you want to do something online with other people, your software has to be compatible with theirs. In practice this usually means you all have to use the same software, and that’s a problem. If you want to share photos with a group, and you use facebook, they all have to use facebook. If you use flickr, they all have to use flickr. It’s like this for nearly every kind of software out there. The exceptions show what’s possible if we solve this problem. In a few cases, through years of hard work, people have been able to create standards which allow compatible software to be built. We see this with email and we see this with the web. Because of this, email and the Web are everywhere. They permeate our lives and now it’s hard to imagine modern life without them. In other areas, though, we’re stuck, because we don’t have these standards, and we’re not likely to get them any time soon. So if you want to create, explore, play a game, or generally collaborate with a group of people on line, every person in the group has to use the same software you do. That’s a pain, and it seriously limits how much we can use these systems. I see the answer in the Semantic Web. I believe the Semantic Web will provide the infrastructure to solve this problem. It…

Can we use Lean Startup methods to build the Semantic Web?
type: item
creator: sandhawke
date: 2011-01-28T13:17:20Z
subject: Uncategorized
description: I’m disappointed in the pace of development of the Semantic Web, and I’m optimistic that the Lean Startup ideas can help us move things along faster. I’ve been a fan of Eric Ries and the Lean Startup ideas for while, but last night I was lucky enough to get to see him speak, and to […]
encoded: I’m disappointed in the pace of development of the Semantic Web, and I’m optimistic that the Lean Startup ideas can help us move things along faster. I’ve been a fan of Eric Ries and the Lean Startup ideas for while, but last night I was lucky enough to get to see him speak, and to chat with some other adherents. There are a lot of ideas here, but the bit that jumps out at me today is this, loosely paraphrased: Reality distortion fields are bad. Instead of using charisma, style, and emotions to motivate your colleagues to act on faith, motivate them with experimental evidence. I think we have scant evidence that the Semantic Web will work, and that most of us have been working on this as an act of faith. We believe, without solid evidence, that it can work and will be a good thing when it does. You could say we’re operating in an RDF (resource description framework) RDF (reality distortion field). The Lean Startup methodology says that we should get out of that field as quickly as possible, doing the fastest experiments possible that will teach us what really works and does not work. On faith we can do 5+ year projects, hoping to show something interesting. Instead, we should be doing month projects to test a hypothesis about how this is all going to be useful. It’s a shame that most of us are funded in ways that don’t support or reward this at all. It’s a shame the research funding agencies operate on such a glacial and massive scale; in many ways they seem geared more towards keeping people busy and employed than actually innovating and producing knowledge for the world. Below are my notes taken during Eric’s talk. I have not cleaned them up at all, so you can see just how badly my fingers spell “entrepreneur” when my brain has moved on to something else. I believe slides and the talk itself are available on line; it’s a talk he often gives, so if you have the time, watch it instead of just skimming my notes. (eg this one at Stanford.) Someone else with much bette…

Simplified RDF
type: item
creator: sandhawke
date: 2010-11-10T18:24:46Z
subject: Web Architecture
description: I propose that we designate a certain subset of the RDF model as “Simplified RDF” and standardize a method of encoding full RDF in Simplified RDF. The subset I have in mind is exactly the subset used by Facebook’s Open Graph Protocol (OGP), and my proposed encoding technique is relatively straightforward. I’ve been mulling over […]
encoded: I propose that we designate a certain subset of the RDF model as “Simplified RDF” and standardize a method of encoding full RDF in Simplified RDF. The subset I have in mind is exactly the subset used by Facebook’s Open Graph Protocol (OGP), and my proposed encoding technique is relatively straightforward. I’ve been mulling over this approach for a few months, and I’m fairly confident it will work, but I don’t claim to have all the details perfect yet. Comments and discussion are quite welcome, on this posting or on the semantic-web@w3.org mailing list. This discussion, I’m afraid, is going to be heavily steeped in RDF tech; simplified RDF will be useful for people who don’t know all the details of RDF, but this discussion probably wont be. My motivation comes from several directions, including OGP. With OGP, Facebook has motivated a huge number of Web sites to add RDFa markup to their pages. But the RDF they’ve added is quite constrained, and is not practically interoperable with the rest of the Semantic Web, because it uses simplified RDF. One could argue that Facebook made a mistake here, that they should be requiring full “normal” RDF, but my feeling is their engineering decisions were correct, that this extreme degree of simplification is necessary to get any reasonable uptake. I also think simplified RDF will play well with JSON developers. JRON is pretty simple, but simplified RDF would allow it to be simpler still. Or, rather, it would mean folks using JRON could limit themselves to an even smaller number of “easy steps” (about three, depending on how open design issues are resolved). Cutting Out All The Confusing Stuff Simplified RDF makes the following radical restrictions to the RDF model and to deployment practice: The subject URIs are always web page addresses. The content-negotiation hack for “hash” URIs and the 303-see-other hack for “slash” URIs are both avoided. (Open issue: are html fragment URIs okay? Not in OGP, but I think it will be okay and use…