Using the Web for decentralized coordination of distributed processes.

You can get there from here.

Tyler Close
Google, engineer
Waterken Server, project leader

decentralized
There is no single authority in the network that everything is vulnerable to.

Web Data Model

origin, resource, URL, GET, POST, response, representation

CA URL

https://example.org

(scheme)://(host):(port)

y-property

Granovetter Diagram

YURL

https://sha-256-bcn57qkphyqkjfrt.yurl.net

(scheme)://(algorithm)-(fingerprint).yurl.net:(port)

web-key

./#s=4mrz4gknjpc6zi

./#s=(permission token)

https://sha-256-bcn57qkphyqkjfrt.yurl.net/#s=4mrz4gknjpc6zi

YURL + web-key

arbitrary number and size of trust domains

Summary

distributed
Processes are separated by a potentially unreliable network.

Repetition

Idempotent POST

?x=4mrz4gknjpc6zi&w=2&m=1

?x=(session-id)&w=(window-id)&m=(message-id)

DEMO: at most one withdrawal

Distributed Consistency

DB stores outbound message queue

DEMO: stop the world

Summary

coordinated
Processes need to cooperate to achieve meaningful results, potentially in the face of mutual suspicion.

Application code is coordination code

URL as promise

When responding to a request requires making another request, the response must be a promise.

/#o=&s=vwvrzxa64rw6bb

APIs for asynchrony

Uniform Messaging Policy

Powerbox

provided resource ↔ Customer page ↔ Powerbox ↔ Provider

DEMO: a sneak peek at a browser powerbox

Conclusion

The existing Web infrastructure provides good support for DCDP and is being evolved to provide excellent support. A revolution of our perspective might be needed, but not of our tools.