Skip to content

Instantly share code, notes, and snippets.

@chrisbodhi
Last active June 30, 2023 02:22
Show Gist options
  • Save chrisbodhi/a474d312ae6f4c0d9a365c74b75b7be6 to your computer and use it in GitHub Desktop.
Save chrisbodhi/a474d312ae6f4c0d9a365c74b75b7be6 to your computer and use it in GitHub Desktop.
Start of a proposal for a protocol for broadcasting data to local applications

A protocol for distributing data between applications, and then reacting to it appropriately

#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]]

Protocol design

  • 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

Putting the protocol to work

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)

Use cases

  • 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)

Adoption

Steps from the incomparable Matt Webb

Talk version of the above post:

Belief

Spark belief that this could all grow into something wonderful by building that minimum viable network with your protocol

Desire

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).

Slogans

A lá [[Alan Kay]], speaking in slogans gives up some fidelity, but can get people excited

  • "UNIX pipes for GUI apps"

Considerations/Challenges

  • 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?

Research

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment