Technical

Writing

  • Short stories/speculative fiction
    • CID as the library of babel
    • Interplanetary communication / state machine
    • Packet switched electricity
    • saving sun for later (make something we take for granted extremely scarce)
  • Essays
    • Analog software: software by analogy and by atomic building blocks that interface with each other
      • We should be able to directly manipulate them, like files, rather than only indirectly work with them, like layer activations in a neural network.
      • Software representations for similar ideas should be obviously similar in some way – they should click together, or look similar, or feel similar to the touch.
      • Ideas should remember where they came from – what blog I copied it from, which author I quoted it from, and so on.
    • Essay on epistemic play + Jestermaxxing + mill’s take on why censorship is unethical
    • limits to BFT
      • some malicious activity is indistinguishable from legitimate activity (e.g. deleting a document)
        • semantic byzantine fault tolerance vs protocol byzantine fault tolerance
      • Making distributed systems reliable is inherently impossible; we cling to Byzantine fault tolerance like Charlton Heston clings to his guns, hoping that a series of complex software protocols will somehow protect us from the oncoming storm of furious apes who have somehow learned how to wear pants and maliciously tamper with our network packets. (The Saddest Moment by James Mickens)
      • “I have never had a real-life experience that resembled a Byzantine fault tolerant protocol.”
    • two axes of collaborative vs local-first software
      • ultimately about state reconciliation
      • one is temporally (offline-first) the other is spatially (collaboration across multiple computers)
      • two axes, not mutually exclusive
      • maybe worth plotting where everything sits lol
      • data is either
        • collaborative: co-editing
        • persistent: saved somewhere (as opposed to ephemeral)
        • versioned: can time travel
    • independent research is applied taste
      • Aesthetics as a heuristic for non obvious optimality
    • Good search (aggregators) turns random networks into scale-free networks (see: network theory)
    • The sequel to SQL (Against table databases)
      • Data interoperability is really hard with SQL
        • I think interoperability in the context of the web means being able to transparently understand and share data, agnostic of platform.
        • Closed platforms disallow this as they curate the information they present to end-users/devs through the frontend but close off access to the actual data itself.
        • This forces one ‘correct’ way of looking at data (which is often not the case!)
      • What about evolution of applications?
      • Taking evolution to its natural extension, a different application all together?
      • How do we create sources of truth that are legible outside of the application, possibly in ways that the application developer never anticipated?
      • Well, we’ve done this already once! The applications on our computers ‘share’ data between them is through the file system
        • An application then is a specific view on types of data rather than a standalone thing. Data can be dragged through different applications. Each data is annotated with a type.
      • How might we do this for more general data?
      • Recent years has seen a revival of academic and research interest in the tuple store which will allow us to pull out structure when we need it. It embraces a pluriversal view of data — a world where multiple alternatives co-exist
        • We can think of a triple store as a distributed and fragmented SQL database, where instead of tables with rows and value, we have entities with attributes and values. Any application can declare new attributes or alias an attribute to a more common one. The most important part is that applications that share attributes can automatically interoperate their data by using the same attributes
        • This type of ‘decentralized’ database means there is no canonical schema. You can’t mistake the map for the territory because everyone has their own map and can’t force others to view the ’truth’ of the world through your map
        • See more: https://jzhao.xyz/thoughts/Rhizome-Research-Log#october-19th
        • (Inkandswitch explored this with Cambria)
      • One common critique of this is that we lose efficiency and that by knowing the structure of the data ahead of time, we can better optimize queries, etc.
      • Using tuples doesn’t prevent us from creating indices and using incremental view maintenance! A lot of really good recent research on differential data flow
      • Importantly, this gives us moldable data which enables people to have the raw material to sculpt and play with
        • (AtProto making the data and schema public means that we’ve seen an explosion of clients and projects that use BlueSky data)