#bradfield
The push to share data on [[Protocols]], and not platforms, is gathering steam on the Web. For years now, both consumers and creators of numerous web systems have bemoaned the lack of interoperability of a single user’s data between systems. It is these silos that people have been attempting to bridge or bring down since time immemorial (or at least since attempts to section off swaths of the Web became commonplace). What has gone unchallenged in this discourse is the siloing of data between applications on our local machines.
This document proposes an open protocol for sharing data between applications in order to make our local computing more responsive and adaptable to our changing conditions. This document also proposes bringing the well-regarded and explored concept of the Unix [[pipe]] to GUI applications as a way of applying the protocol to local systems. Finally, this document ends with an implementation of the protocol and pipe system applied to a calendar app and weather widget; [[Calendar widget with interop]]
- CRDT’s because the final state of the application may depend on outside or multiple changes happening at once, from different sources
- Using Protobuf or something similar for sending our data: we want transmission to be as efficient as possible
- Push updates to applications: changes are events that are emitted to any possible receivers
- How will new receivers know where to listen for events?
- For that matter, how will senders know where to send their events?
- Does everyone emit into a single stream, to which everyone listens? See: D-Bus
- Signing data: to encourage interop, there must not be a single authority blocking the creation of new applications (either in the sense of apps or applications of the network for new uses); thus, we need certain assurances about the origin of data for the receivers
Proposed architecture: each application has a standardized process space, like how fork-ing a Unix process creates the same. The application runs inside this space, which acts as the intermediary and munger of different data sources: receiving data from the network or other processes. Ironically enough, this is a screenshot of a Notes.app drawing copied and pasted into this document.
“Env” includes data available by way of database or file access or however else a non-networked, non-connected, non-piped application would store its own data.
Pushing application: "I have these fields to send to you." REQ
Receiving application: "I hear you and only know how to handle these specific fields" ACK
PA: sends just those fields SEND
RA: "Got just those fields, thanks" ACK
(Is there a close connection action that needs to happen? Or are these sockets just chillin, wide open, tokin in the spring sun, boppin they heads)
- Weather forecast that takes into account calendar/where you’ll be in the future
- Any user-entered text preceded by TODO ends up in a Reminder app (class of SaaS apps that are org-mode features)
Steps from the incomparable Matt Webb
Talk version of the above post:
Spark belief that this could all grow into something wonderful by building that minimum viable network with your protocol
a compelling visualization of the future
We start to see how this simple protocol can be adapted to existing software systems, like an internet-connected parking meter that won't accept payment when parking is illegal in certain conditions (street-cleaning day, for instance).
A lá [[Alan Kay]], speaking in slogans gives up some fidelity, but can get people excited
- "UNIX pipes for GUI apps"
- GUI applications sandboxed by the OS – how big of a problem will this be?
- How can this be designed so that it will be easy to debug?
- Quora question answered by Alan Kay about if this is even possible -- tl;dr yes
- D-Bus: