jeffemmett
/
orionreed.com
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

blank setup

This commit is contained in:
Orion Reed 2023-09-23 14:36:22 +02:00
parent 7ee88946ba
commit 22d9dccdb9
33 changed files with 207 additions and 10065 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

177
.gitignore vendored
View File

@ -1,24 +1,169 @@
# Based on https://raw.githubusercontent.com/github/gitignore/main/Node.gitignore
# Logs
logs
*.log
npm-debug.log*
_.log
npm-debug.log_
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*
.pnpm-debug.log*
node_modules
# Diagnostic reports (https://nodejs.org/api/report.html)
report.[0-9]_.[0-9]_.[0-9]_.[0-9]_.json
# Runtime data
pids
_.pid
_.seed
\*.pid.lock
# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov
# Coverage directory used by tools like istanbul
coverage
\*.lcov
# nyc test coverage
.nyc_output
# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
.grunt
# Bower dependency directory (https://bower.io/)
bower_components
# node-waf configuration
.lock-wscript
# Compiled binary addons (https://nodejs.org/api/addons.html)
build/Release
# Dependency directories
node_modules/
jspm_packages/
# Snowpack dependency directory (https://snowpack.dev/)
web_modules/
# TypeScript cache
\*.tsbuildinfo
# Optional npm cache directory
.npm
# Optional eslint cache
.eslintcache
# Optional stylelint cache
.stylelintcache
# Microbundle cache
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/
# Optional REPL history
.node_repl_history
# Output of 'npm pack'
\*.tgz
# Yarn Integrity file
.yarn-integrity
# dotenv environment variable files
.env
.env.development.local
.env.test.local
.env.production.local
.env.local
# parcel-bundler cache (https://parceljs.org/)
.cache
.parcel-cache
# Next.js build output
.next
out
# Nuxt.js build / generate output
.nuxt
dist
dist-ssr
*.local
# Editor directories and files
.vscode/*
!.vscode/extensions.json
.idea
.DS_Store
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?
# Gatsby files
.cache/
# Comment in the public line in if your project uses Gatsby and not Next.js
# https://nextjs.org/blog/next-9-1#public-directory-support
# public
# vuepress build output
.vuepress/dist
# vuepress v2.x temp and cache directory
.temp
.cache
# Docusaurus cache and generated files
.docusaurus
# Serverless directories
.serverless/
# FuseBox cache
.fusebox/
# DynamoDB Local files
.dynamodb/
# TernJS port file
.tern-port
# Stores VSCode versions used for testing VSCode extensions
.vscode-test
# yarn v2
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.\*

1
CNAME
View File

@ -1 +0,0 @@
orionreed.com

15
README.md Normal file
View File

@ -0,0 +1,15 @@
# underlay
To install dependencies:
```bash
bun install
```
To run:
```bash
bun run index.ts
```
This project was created using `bun init` in bun v1.0.0. [Bun](https://bun.sh) is a fast all-in-one JavaScript runtime.

BIN
bun.lockb Executable file
View File

Binary file not shown.

4
global.d.ts vendored
View File

@ -1,4 +0,0 @@
declare module '*.md' {
const value: string // markdown is just a string
export default value
}

19
index.html
View File

@ -1,19 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<title>Orion Reed</title>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="icon" type="image/x-icon" href="/favicon.ico" />
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico?" />
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
href="https://fonts.googleapis.com/css2?family=Alegreya+Sans:ital,wght@0,300;0,400;0,500;0,700;0,800;0,900;1,300;1,400;1,500;1,700;1,800;1,900&family=Alegreya:ital,wght@0,400..900;1,400..900&family=IBM+Plex+Mono:ital,wght@0,200;0,300;0,400;0,500;0,600;1,200;1,300;1,400;1,500;1,600&display=swap"
rel="stylesheet">
</head>
<body>
<div id="app"></div>
<script type="module" src="/src/index.tsx"></script>
</body>
</html>

1
index.ts Normal file
View File

@ -0,0 +1 @@
console.log("Hello via Bun!");

9004
package-lock.json generated
View File

File diff suppressed because it is too large Load Diff

44
package.json
View File

@ -1,35 +1,11 @@
{
"name": "example",
"private": true,
"type": "module",
"scripts": {
"dev": "vite",
"prebuild": "node scripts/prebuild.mjs",
"build": "node scripts/prebuild.mjs && vite build",
"preview": "vite preview"
},
"dependencies": {
"@emotion/react": "^11.11.1",
"@mantine/core": "^6.0.19",
"@mantine/hooks": "^6.0.19",
"@preact/signals": "^1.2.1",
"date-fns": "^2.30.0",
"jsonlines": "^0.1.1",
"minisearch": "^6.1.0",
"preact": "^10.13.1",
"preact-router": "^4.1.2",
"react-router-dom": "^6.15.0",
"reading-time-estimator": "^1.9.0"
},
"devDependencies": {
"@esbuild-plugins/node-globals-polyfill": "^0.2.3",
"@preact/preset-vite": "^2.5.0",
"@types/node": "^20.4.9",
"front-matter": "^4.0.2",
"glob": "^10.3.3",
"markdown-to-jsx": "^7.3.2",
"typescript": "^5.1.6",
"vite": "^4.4.9",
"vite-plugin-top-level-await": "^1.3.1"
}
}
"name": "underlay",
"module": "index.ts",
"type": "module",
"devDependencies": {
"bun-types": "latest"
},
"peerDependencies": {
"typescript": "^5.0.0"
}
}

3
public/posts.jsonl
View File

@ -1,3 +0,0 @@
{"date":"2023-01-11T00:00:00.000Z","slug":"test","title":"Objects as Reference","location":"Devon, UK"}
{"date":"2023-02-17T00:00:00.000Z","slug":"wobblywoo","title":"Some temporary title","location":"Mars"}
{"date":"2023-10-30T00:00:00.000Z","slug":"foobar","title":"Foobar","location":"Somewhere in England"}

104
public/posts_md/foobar.md
View File

@ -1,104 +0,0 @@
---
title: Foobar
date: 2023-10-30
location: Somewhere in England
---
## Reference Systems
The last essential component for our understanding of objects is to recognise that reference does not exist in relation to individual objects, but is encoded in *systems* which condition, prefigure, or otherwise shape *how one can refer.* Reference is an aspect of all systems, but while some systems use reference, other systems *provide* it. Filesystems, databases, the Unicode standard, programming languages, URL schemes, and other disparate systems, all provide ways to *refer.* Some of these (like Unicode) have a tightly controlled set of objects already defined (i.e. Unicode codepoints), while databases provide no predefined objects but control how one can refer and the structure of the objects referred to. We might view these systems as shaping *families of objects*, which may be more or less homogenous across a range of characteristics. Observing these systems collectively with all of their overlaps and interactions, a comprehensive picture of their interrelations becomes untenable. Much like software in the real world, these complex interactions and overlaps create something closer to ecologies of objects, rather than clearly delineated, singular systems. A broader *ecological* or *complex systems* analysis is out of scope for this paper, but would depend on foundation we are trying to develop here. As such, we will focus on individual systems of reference and not their complex interactions.
## Characterising Reference
Objecthood is not just a binary condition but a *spectrum* — while something is *an* object if we refer to it, the way in which we refer which shapes the nature of its objecthood. To compare, contrast and otherwise understand objects, we need richer language to understand reference and its role in shaping their existence. The following is a collection of 6 dimensions with which we can position objects and the systems that shape them, paired with illustrative examples. We can think of objects as occupying positions or ranges on these dimensions, and systems shaping upper or lower bounds in which objects are positioned. The goal of these is not formalisation, but to provide language with which we can compare, contrast, and articulate features of existing systems as well as systems which do not yet exist.
**1. Granular - Coarse:** Can the smallest objects be referred to? Or must one reference larger assemblages of these objects?
> Example: A spreadsheet provides reference to individual cells which contain — often but not always — small quantities of information, whereas a traditional filesystem is very coarse, providing reference to arbitrarily large files and not their constituent parts. Note that granular referenceability does not preclude more coarse reference, but coarse reference *does* preclude (or necessitate fragile workarounds for) granularity.
**2. Open - Closed:** Can the objects be referred to from any system? or are objects contained *within* a system which excludes, limits, or otherwise controls referenceability?
> Example: An self-contained application with fully internal state and no APIs or means of reference is a fully closed system, a filesystem which provides the same means of reference as it gives to itself is an open system.
**3. Persistent - Transient:** Is reference assured over time?
> Example: File objects stored in a decentralised filesystem are highly persistent — existing for as long as any one person is using them. In contrast, webpages have an average half-life of just over 2 years and are far less persistent [@Fetterly_2003]. An extremely transient object would be one which exists for only moments, such as a value in a running program.
**4. Atemporal - Temporal:** Can the reference or referent change?
> Example: Content-addressed objects are atemporal — neither their reference or referent change. Unicode words are a mix — reference is fixed, but the referent can change through social means, i.e. the meaning of words can change. A file in a traditional filesystem is temporal — the reference (filename) can change and so can the referent (file content).
**5. Technical - Social:** Is the the relation between reference and referent maintained through technical or social means?
> Example: A file path or database ID is a technical reference, whereas a word or term in text (e.g. "Python") is a primarily social one, as the reference is connected to the referent only in the minds of readers.
**6. Public - Private:** Is power over reference held in common, or is this power held by a private organisation?
> Example: Text is public, you can freely use words or phrases across various systems with near ubiquity. On the other hand, Tweets are private, while Twitter lets you reference tweets via their URL, this is at the behest of the company and they are free to change or to remove this capacity at any time. Private objects range from songs on music apps, interface widgets in creative tools, messages in communication apps, and so on.
# The Role of Objects in Organisation
The organisational role of objects stems from the fact that objects are precisely the things which we can talk about and put into relation. Organisation can mean different things depending on the context, but we can identify two broad meanings of the term:
1. *Organisation-as-object:* A collection of elements with with a given arrangement and structure. This usage emphasises the ways in which these elements or components *are* arranged, grouped, and interconnected.
2. *Organisation-as-process:* The process of arranging and structuring elements or components in a systematic and orderly way. This usage of organisation organisation emphasises the ways in which these elements or components *come to be* arranged, grouped, and interconnected to form a cohesive whole that functions according to certain principles or rules.
We take this combined meaning as a working definition of organisation: The way in which elements *are* or *come to be* arranged, structured, and interconnected. The role of objects here is hopefully clear, as to express or represent structure or relations between objects, these objects must first exist.[^4] This structuring is rarely independent of the systems which condition these objects; changes to the position of a file object in its hierarchy changes the reference itself because its reference is determined by its location in the hierarchical structure. Note that this does not mean a change in *referent*, a text file that is moved to a different place in the hierarchy retains its content (though a small change is often made to its metadata). We also see this coupling in filesystems through the enforcement of metadata.
[^4]: We often create structure for things which do not yet exist. However, to do this we still must use existing objects, it is just their role that is different (i.e. as stand-ins or "holes" which may or may not get replaced or filled later).
## Structural Characteristics of Reference
While reference provides objecthood, this is often entangled with the way in which objects are organised. For example, a reference to a file is derived from its position in a hierarchy, and a reference to a named class in a programs source code is dependent on there being only one class of the same name within some scope to which the class objects belong. I posit that provision of structure ought to be decoupled from provision of reference in information infrastructure, and that this decoupling key to enabling more pluralistic and flexible organisation of information.
**7. Independent - Dependent:** An independent reference refers to an object directly, whereas a dependent reference requires reference to another object.
> Example: A PDF file is an independent object, whereas the pages of that PDF are dependent.[^9]
[^9]: All objects involve *some* level of dependence, as objects cannot exist with complete independence from the systems that their existence is conditional upon.
**8. Primitive - Composite:** A primitive reference points to a unit of information which cannot be further divided into units with semantic value, whereas a composite reference points to some collection or arrangement of these primitives.
> Example: A text paragraph is a composite object because it is composed of characters, a character is a primitive because it cannot be decomposed further into semantically meaningful objects — known as a "seme" in semantics.
**9. Pointer - Token:** A pointer reference points to a well-defined referent, a token reference points to no referent or one that escapes delineation.
> Example: A content-addressed file is a pointer because it has a mechanised relation to its referent (a hash derived from data, i.e. its referent). A tag in a notes app is a token, because its through interrelations with other objects (notes for example), that it becomes useful.[^5]
[^5]: Note that by ignoring a referent we can treat a pointer as a token, but the reverse is not the case. It is common for a pointer object to be repurposed as a token, such as a note being used as a tag in graph-like notes systems such as Roam or Obsidian.
# Objects and Identity
Stateful objects present an interesting challenge for our account. State refers to the present condition of a system, a *stateful* system is thus one which *can have* a present condition — this is in contrast to a stateless system which does not have a present, i.e. has no relation to time [@Harris_2010]. A stateful *object* is therefore one that can have a present condition. While this is a true statement it is not a sufficient definition for objects, as it is non-obvious how we can distinguish between an object that has changed, and an object that has been replaced with a "different" object. We can articulate this more concretely as the problem of *identity*,[^6] which in philosophy is approximate to the question of "sameness” [@Noonan_2022]. While a stateful object has an identity — there is a way in which the object is the same *over time* — object identity is not limited to continuity over time. Identity can extend over space (such as two image objects on opposite sides of the world being "the same"), can have fuzzy boundaries (people can disagree on what objects are part of a meme), can split and recombine (an applications code repository can be forked creating two apps with new identities, and later recombined into a singular "canonical" app), and so on. Object identity depends on technical as well as social systems, and while some systems do treat identity as an essential design consideration [@Hickey_], it is most often a consequence of other decisions around system design, technical efficiency, or other factors. I argue we should *decouple* identity from reference, especially in key systems such as filesystems, databases, and other information infrastructure. I am skeptical that there is any singular *solution* to identity management, but new approaches which are not embedded inside existing systems are sorely needed.
[^6]: This philosophical concept of identity is distinct from the better-known notion of identity in psychology and the social sciences. The concept in the social sciences has to do with a person's self-conception, social presentation, and more generally, the aspects of a person that make them unique, or qualitatively different from others. Whereas in philosophy identity has to do with a relation between X and Y that holds only if X and Y are the same.
# Discussion
I'm going to switch modes for this last section. I've run out of steam for this draft, so let me just touch on some things I might like to discuss in colloquial language.
Identifying three key responsibilities or roles of "object systems", and arguing that the tight coupling of these responsibilities is detrimental to our information infrastructure. Decoupling these is key to enabling "better" objects:
1. *Reference*, which conditions the ways objects come to exist and several of their key properties.
2. *Structure*, which conditions how objects are or can be interrelated and the forms they must take. E.g. filesystems impose metadata on their objects, task manager apps impose ways that tasks can be organised, etc.
3. *Identity*, which conditions the ways objects can be considered the same. This is the least-explored part of the paper so far but is super important, I think there's a lot of under-explored ways we can manage identity, but currently this is left to the mutability rules of a system (e.g. file modification) or is implicit in the structure and use of objects (e.g. we consider an image in two formats to be the same). This topic is so big and interesting it may merit its own paper, and I do have one idea for a generalisable approach, which is to view identity as a kind of *governance.* That is to say, that identity comes first from the ways that *people* agree that something is the same. We could imagine identity systems that are highly pluralistic with many overlapping identities. This governance position is currently dominated by system designers such as those designing filesystems, but I think we could articulate a much more decentralised and participatory approach to identity.
Looking at the "wants from objects", what do different discourses want from the objects of concern in their discourse? Malleable software wants interface objects that can are independent of apps; Itemised systems want user-facing data objects to be independent of application boundaries and freely structurable (calendar events, notes, tasks, contacts, etc); post-document systems want the objects currently hidden inside documents to be decoupled from the documents; and so on... One running theme through a lot of these wants is that objects should be robustly referenceable and independent, and that we need to *disaggregate* key objects into smaller referenceable parts. I'd like to expand and articulate these wants through the dimensions laid out earlier in the paper. And I'd like to argue that these discourses should be articulating demands of information *infrastructure* to enable success with these efforts, and recognise the limits of building isolated systems or new platforms — though this can be an effective way of exploring their goals.
I'd like to explore the predictive and explanatory power of this work. If it is a truly *robust* theory, which I think it could become, this needs to be proved out more empirically. Part of this would involve expanding approaches to analysis, while the dimensions are a nice start I would like to do a more systemic analysis of objects "in the wild" and explore the possibilities of formalising some of this work.
While individual systems have been explored, in practice these systems overlap and interconnect in many ways. Characterising interrelationships among multiple systems is a key point to expand on. E.g. the relation between an interface element and the "code" objects that underly it. There's lots of work that cares about these relationships and tries to do things with them, such as bidirectional lenses, linking languages, or linked data protocols. An empirical analysis would need to consider the many systems in seemingly "singular" objects: a JSON file, for example, involves file objects, unicode objects, named ontology elements, and these all interact nontrivially, such as the way that hierarchical structure is encoded in a linear structure of unicode objects.
There's a lot that could be said about expressibility, user agency, and the role of objects in "digital language" — as through reference we create new “words" to speak *with* and new objects to speak *about.*
I'd like to explore implications for infrastructure design, and this is probably a theme that needs to run through the rest of the paper...
There's a political-economic dimension, mentioned in the "public-private" dimension, that's worth expanding on. Referenceability is one way that companies can obstruct more open, decentralised, and I think generally "better" systems from emerging. One could argue that some companies benefit from a "monopoly on referenceability" and that this is something we should try and escape, a fun idea here is to borrow the notion of "adversarial interoperability" and advocate for a kind of "adversarial referenceability" as a political/economic demand [@Doctorow_2019a].
Through this work it became clear that certain roles of objects are poorly supported:
1. *semantic objects* — which gain usefulness through being stable tokens around which semantic structure can emerge — are poorly supported in our systems. Unicode words or phrases are nice tokens, but are highly dependent on files and are not independent in the way we'd like. Files (especially content-addressed ones) are stable and independent but are primarily *pointers* and have too much imposed structure to be good semantic objects. Imagining the best of both worlds is interesting to me: objects that are robust, atemporal, independent, tokens. Imagine if a phrase like "graph databases" could be its own object with a robust reference like a hash, which could be freely linked to, put into relation with other objects and be used in many contexts and places and not tied to a specific system (as files tend to be, but words do not)...
2. *relational objects* — which gain usefulness through expressing relations *between* objects — are also poorly served, as most relations are implicitly embedded in systems and have no independent representation. Research to address this often imposes *a ton* of assumptions and conditions, such as RDF or other semantic web efforts. I'm interested to explore what can be done here and am working on one approach for content-addressed systems with *content-addressed relations*, these do not impose (but can support the representation of) structure — no ordering of relata, no types/labels, no set arity, etc. These relational objects are compelling to me because they can be stable, independent, atemporal, and granular. One could imagine an ambient graph-like network emerging not through some decentralised database or protocol, but as a side effect of creating these kinds of relational objects in many different contexts.
I've focused on limited kinds of objects, things like files, words, PDFs, reminders, etc. Objects that are mostly referenced through *addressing systems.* The choice of examples in this paper need to be interrogated a lot more and there are other kinds of objects which I barely addressed at all, like the artefacts of HCI research: buttons, widgets, etc. Grappling with the wider existence of objects feels out of scope but is pretty important if this theory is to stand up to scrutiny.
Lastly, an obvious omission to this paper and discussion is a deeper exploration of the *usefulness* of this work to *specific* research efforts, this needs to change but I am still figuring out which discourses and specific research work I want to give the most attention in this paper. Feedback on this is *incredibly welcome*!
There's much more to do! And much to do that I *do not know about yet*! If you can help me figure out *any* of this I will be eternally grateful!
# References {.unnumbered}

138
public/posts_md/test.md
View File

@ -1,138 +0,0 @@
---
title: "Objects as Reference"
date: 2023-01-11
location: Devon, UK
---
**NOTE TO READERS.** This draft is not intended to resemble a complete paper but is a sketch of what one might look like. The goal at this stage is to start discussions, find conceptual issues or major omissions, and discover relevant research. Perhaps most importantly, I'm interested in hearing how *your work* could benefit from this line of research. Any feedback will help move towards more salient, compelling and useful answers.
# Introduction
The phenomena of distinct *things* — variously referred to as objects, entities, items, assets, elements, or artefacts in computing discourse — play a key role in computer use, organisation, and information infrastructure. We share *documents*, arrange *modules* into *programs*, click *buttons*, create *calendar events*, and assemble *systems* out of *components.* The importance of these phenomena — the "nouns" which serve as the basic semantic and organisational units of our systems — is hard to overstate. Yet their broad and nebulous nature has hindered the development of a general account. A robust and general theory of these phenomena — how they come to exist, what they are, and how we can identify and analyse them — is of key concern for information systems, data infrastructure, and systems design.
In this paper I argue that the concept of *object* as it is understood in contemporary philosophy is an appropriate concept and term[^1] to describe the category to which these phenomena belong, and that the concept of *reference* can be used to provide a robust account of how objects come to exist in socio-technical systems. I then introduce a new concept which synthesises these ideas: *objects as reference.* The merits of this concept are explored, an analysis of objects through the characterisation of reference is introduced, and the viability of this concept as a theoretical foundation is discussed.
[^1]: The term "object" is not a new one in computing and has been used in various contexts such as object-oriented programming (OOP). but I find it prudent that we reappropriate this term. After all, it was OOP that took its meaning from philosophy, not the other way around. Introducing a new term (e.g. "entity") to avoid semantic ambiguity will only lead to further confusion in the long term by distancing the term from the concept that it represents.
# A Semantic Account of Objects
The concept of *object* in philosophy is quite an appropriate one to describe the nebulous phenomena of digital *things.* In contemporary philosophy, the word _object_ names a maximally general category, whose members are eligible for being referred to, quantified over and thought of [@Rettler_2017a]. Examples are as diverse as the country of Egypt, the number four, sticky toffee pudding, or the fear of heights. Objects are often contrasted with *subjects* — the subject is an observer, the object is the thing observed. Pragmatist Charles S. Peirce defines objects succinctly as "anything that we can think, i.e. anything we can talk about" [@Peirce_undated]. As objects are a foundational concept of philosophy there are many theories about their nature, but it is the *semantic view* of objects implicit in Peirce's definition that is of interest to us. A *digital* objects is "any digital thing which can be talked about", and thus the definition for the *category* of digital objects is *the maximally general category to which all digital objects belong* — i.e. the category which includes any and every digital thing which can be talked about.
While *object* defines a general category, its members remain abstract without a second key concept, that of *reference.* Broadly, *reference* is a relationship in which a symbol or sign (a word, for example) signifies something, which we call its *referent* [@Michaelson_2022]. The referent may be as concrete as a building, or may be abstract, such as a set of actions, or a family of mathematical objects. For example, when I assert that “Python is a programming language,” I use a particular sort of representational token — the name ‘Python’ — which refers to a particular object — the Python programming language. Reference comes in many forms, from *singular reference* which points to an individual object — e.g. a file path or database ID; *extensional reference* which points to a collection of objects that fall under a definition — e.g. CSS selectors; *indexical reference* which points to different objects depending on context — e.g. the first element of a list, or the word "you" in natural language.[^2]. We refer to things not only to speak of them, but by referring we make new things *to speak of.*
[^2]: Note that there is much debate around exactly *how* these tokens refer and *if* they refer at all [@Michaelson_2022]. But this debate is mostly the concern of philosophical discourse and will not be explored in this paper.
## Objects as Reference
The central thesis of this paper is that objects come to exist *through* reference, i.e. that objects exist *wholly in the sense that you can refer to them* — it is this meaning that is expressed in the phrase "objects as reference". The category of objects includes members as diverse as unicode characters, PDF files, buttons, calendar events, and Python functions. Note that this is not a philosophical thesis but a *pragmatic* one, as it may be the case that — in philosophical terms — there exist objects to which we cannot refer. But these objects, should they exist, are not *observable*, nor are they useful to us or to computing systems. This is not to say we cannot *think of* digital objects to which we cannot refer — but rather that these objects would exist only in the philosophical sense, and are not *digital* objects until referred to in a computing system. One could think of objects which do not yet exist and discuss these objects with others (such as a new algorithm or design artefact), they could even externalise references to these objects in writing or drawings, but without reference within a computing system, this object exists solely in the minds of the people, not computers.
The sheer variety of objects means that (with the singular exception of reference) nothing is universal among them. Examples of objects include files, spreadsheet cells, variables, codebases, memes, emails, icons, paragraphs, and binary digits. Note that while all objects necessitate *reference*, the same is not true for a singular or well-defined *referent.* While a file may have a clear referent (a delineated sequence of binary digits), this is not so straightforward with a text object, as the referent may be anything from a person (e.g. "Napoleon") to an abstract notion (e.g. "the feeling of dread") or to vast systems which escape clear delineation (e.g. "The Internet"). One difference between these references is the role of technology: A file object is a reference to a well-defined referent and is largely the concern of technical systems, while a text object often has no well-defined referent[^3] and is largely the concern of social systems.
[^3]: This is related to the concept of a *floating signifier* in semiotics, which is a signifier that points to no actual object and has no agreed upon meaning. I avoided this term because a word like "Napoleon" has no well-defined referent *in an informational sense*, even though people will likely find agreement on whom the referent is.
The thesis is not that reference captures the full nature of objects, but rather that reference is the way in which they come to exist, i.e. the way that information or data gains *objecthood* — the condition or state of being an object. Reference does play a significant role beyond objecthood and this is something we will come back to. It is important to reinforce that it is the *reference*, not a *referent*, which defines objects. The referent of “Napoleon” is a person in the physical world who clearly does not exist inside a computer system, and this object is connected to a referent only in the interpreters mind. It is through the existence of a reference that we have an object which can be talked about. For a fully informational referent such as the data of a file, objecthood does not come from the existence of the data itself but from reference to it through a filepath, ID, or some other means. In summary, *reference* is the thing through which information gains objecthood; *referenceability* conditions their existence; *references* define objects which currently exist; and *referring* (the *doing of* reference) brings new objects into existence.
>In essence, the thesis argues that reference is the fundamental process through which objects come into being within a computer system. Without reference, data or information would exist in a state of potentiality, lacking the concrete existence that defines an object. **This means that reference is not simply a tool for identifying or accessing existing objects, but an essential component of their very existence.** While there are other factors that contribute to the nature and properties of objects within a computer system, such as their data structure or programming language, it is ultimately reference that defines their status as objects.
>It is important to note that this does not mean that reference captures the full nature of objects within a computer system. As noted earlier, objects may have many different properties and characteristics beyond their referential identity. However, these additional features are built upon the foundational framework of reference and rely upon it for their existence.
>Furthermore, while reference plays a central role in objecthood, it also has broader implications for how we understand and interact with information within computer systems. For example, references can help to establish relationships between different objects or pieces of data, allowing us to navigate and manipulate complex information structures more effectively. Additionally, references can be used to create new objects by linking together existing data in novel ways.
>Ultimately, then, the thesis argues that reference is a foundational concept for understanding how information becomes organized and structured within computer systems. By recognizing the importance of reference in defining objecthood and exploring its broader implications for information management and manipulation, we can gain deeper insights into how these systems work and how we can use them more effectively.
## Reference Systems
The last essential component for our understanding of objects is to recognise that reference does not exist in relation to individual objects, but is encoded in *systems* which condition, prefigure, or otherwise shape *how one can refer.* Reference is an aspect of all systems, but while some systems use reference, other systems *provide* it. Filesystems, databases, the Unicode standard, programming languages, URL schemes, and other disparate systems, all provide ways to *refer.* Some of these (like Unicode) have a tightly controlled set of objects already defined (i.e. Unicode codepoints), while databases provide no predefined objects but control how one can refer and the structure of the objects referred to. We might view these systems as shaping *families of objects*, which may be more or less homogenous across a range of characteristics. Observing these systems collectively with all of their overlaps and interactions, a comprehensive picture of their interrelations becomes untenable. Much like software in the real world, these complex interactions and overlaps create something closer to ecologies of objects, rather than clearly delineated, singular systems. A broader *ecological* or *complex systems* analysis is out of scope for this paper, but would depend on foundation we are trying to develop here. As such, we will focus on individual systems of reference and not their complex interactions.
## Characterising Reference
Objecthood is not just a binary condition but a *spectrum* — while something is *an* object if we refer to it, the way in which we refer which shapes the nature of its objecthood. To compare, contrast and otherwise understand objects, we need richer language to understand reference and its role in shaping their existence. The following is a collection of 6 dimensions with which we can position objects and the systems that shape them, paired with illustrative examples. We can think of objects as occupying positions or ranges on these dimensions, and systems shaping upper or lower bounds in which objects are positioned. The goal of these is not formalisation, but to provide language with which we can compare, contrast, and articulate features of existing systems as well as systems which do not yet exist.
**1. Granular - Coarse:** Can the smallest objects be referred to? Or must one reference larger assemblages of these objects?
> Example: A spreadsheet provides reference to individual cells which contain — often but not always — small quantities of information, whereas a traditional filesystem is very coarse, providing reference to arbitrarily large files and not their constituent parts. Note that granular referenceability does not preclude more coarse reference, but coarse reference *does* preclude (or necessitate fragile workarounds for) granularity.
**2. Open - Closed:** Can the objects be referred to from any system? or are objects contained *within* a system which excludes, limits, or otherwise controls referenceability?
> Example: An self-contained application with fully internal state and no APIs or means of reference is a fully closed system, a filesystem which provides the same means of reference as it gives to itself is an open system.
**3. Persistent - Transient:** Is reference assured over time?
> Example: File objects stored in a decentralised filesystem are highly persistent — existing for as long as any one person is using them. In contrast, webpages have an average half-life of just over 2 years and are far less persistent [@Fetterly_2003]. An extremely transient object would be one which exists for only moments, such as a value in a running program.
**4. Atemporal - Temporal:** Can the reference or referent change?
> Example: Content-addressed objects are atemporal — neither their reference or referent change. Unicode words are a mix — reference is fixed, but the referent can change through social means, i.e. the meaning of words can change. A file in a traditional filesystem is temporal — the reference (filename) can change and so can the referent (file content).
**5. Technical - Social:** Is the the relation between reference and referent maintained through technical or social means?
> Example: A file path or database ID is a technical reference, whereas a word or term in text (e.g. "Python") is a primarily social one, as the reference is connected to the referent only in the minds of readers.
**6. Public - Private:** Is power over reference held in common, or is this power held by a private organisation?
> Example: Text is public, you can freely use words or phrases across various systems with near ubiquity. On the other hand, Tweets are private, while Twitter lets you reference tweets via their URL, this is at the behest of the company and they are free to change or to remove this capacity at any time. Private objects range from songs on music apps, interface widgets in creative tools, messages in communication apps, and so on.
# The Role of Objects in Organisation
The organisational role of objects stems from the fact that objects are precisely the things which we can talk about and put into relation. Organisation can mean different things depending on the context, but we can identify two broad meanings of the term:
1. *Organisation-as-object:* A collection of elements with with a given arrangement and structure. This usage emphasises the ways in which these elements or components *are* arranged, grouped, and interconnected.
2. *Organisation-as-process:* The process of arranging and structuring elements or components in a systematic and orderly way. This usage of organisation organisation emphasises the ways in which these elements or components *come to be* arranged, grouped, and interconnected to form a cohesive whole that functions according to certain principles or rules.
We take this combined meaning as a working definition of organisation: The way in which elements *are* or *come to be* arranged, structured, and interconnected. The role of objects here is hopefully clear, as to express or represent structure or relations between objects, these objects must first exist.[^4] This structuring is rarely independent of the systems which condition these objects; changes to the position of a file object in its hierarchy changes the reference itself because its reference is determined by its location in the hierarchical structure. Note that this does not mean a change in *referent*, a text file that is moved to a different place in the hierarchy retains its content (though a small change is often made to its metadata). We also see this coupling in filesystems through the enforcement of metadata.
[^4]: We often create structure for things which do not yet exist. However, to do this we still must use existing objects, it is just their role that is different (i.e. as stand-ins or "holes" which may or may not get replaced or filled later).
## Structural Characteristics of Reference
While reference provides objecthood, this is often entangled with the way in which objects are organised. For example, a reference to a file is derived from its position in a hierarchy, and a reference to a named class in a programs source code is dependent on there being only one class of the same name within some scope to which the class objects belong. I posit that provision of structure ought to be decoupled from provision of reference in information infrastructure, and that this decoupling key to enabling more pluralistic and flexible organisation of information.
**7. Independent - Dependent:** An independent reference refers to an object directly, whereas a dependent reference requires reference to another object.
> Example: A PDF file is an independent object, whereas the pages of that PDF are dependent.[^9]
[^9]: All objects involve *some* level of dependence, as objects cannot exist with complete independence from the systems that their existence is conditional upon.
**8. Primitive - Composite:** A primitive reference points to a unit of information which cannot be further divided into units with semantic value, whereas a composite reference points to some collection or arrangement of these primitives.
> Example: A text paragraph is a composite object because it is composed of characters, a character is a primitive because it cannot be decomposed further into semantically meaningful objects — known as a "seme" in semantics.
**9. Pointer - Token:** A pointer reference points to a well-defined referent, a token reference points to no referent or one that escapes delineation.
> Example: A content-addressed file is a pointer because it has a mechanised relation to its referent (a hash derived from data, i.e. its referent). A tag in a notes app is a token, because its through interrelations with other objects (notes for example), that it becomes useful.[^5]
[^5]: Note that by ignoring a referent we can treat a pointer as a token, but the reverse is not the case. It is common for a pointer object to be repurposed as a token, such as a note being used as a tag in graph-like notes systems such as Roam or Obsidian.
# Objects and Identity
Stateful objects present an interesting challenge for our account. State refers to the present condition of a system, a *stateful* system is thus one which *can have* a present condition — this is in contrast to a stateless system which does not have a present, i.e. has no relation to time [@Harris_2010]. A stateful *object* is therefore one that can have a present condition. While this is a true statement it is not a sufficient definition for objects, as it is non-obvious how we can distinguish between an object that has changed, and an object that has been replaced with a "different" object. We can articulate this more concretely as the problem of *identity*,[^6] which in philosophy is approximate to the question of "sameness” [@Noonan_2022]. While a stateful object has an identity — there is a way in which the object is the same *over time* — object identity is not limited to continuity over time. Identity can extend over space (such as two image objects on opposite sides of the world being "the same"), can have fuzzy boundaries (people can disagree on what objects are part of a meme), can split and recombine (an applications code repository can be forked creating two apps with new identities, and later recombined into a singular "canonical" app), and so on. Object identity depends on technical as well as social systems, and while some systems do treat identity as an essential design consideration [@Hickey_], it is most often a consequence of other decisions around system design, technical efficiency, or other factors. I argue we should *decouple* identity from reference, especially in key systems such as filesystems, databases, and other information infrastructure. I am skeptical that there is any singular *solution* to identity management, but new approaches which are not embedded inside existing systems are sorely needed.
[^6]: This philosophical concept of identity is distinct from the better-known notion of identity in psychology and the social sciences. The concept in the social sciences has to do with a person's self-conception, social presentation, and more generally, the aspects of a person that make them unique, or qualitatively different from others. Whereas in philosophy identity has to do with a relation between X and Y that holds only if X and Y are the same.
# Discussion
I'm going to switch modes for this last section. I've run out of steam for this draft, so let me just touch on some things I might like to discuss in colloquial language.
Identifying three key responsibilities or roles of "object systems", and arguing that the tight coupling of these responsibilities is detrimental to our information infrastructure. Decoupling these is key to enabling "better" objects:
1. *Reference*, which conditions the ways objects come to exist and several of their key properties.
2. *Structure*, which conditions how objects are or can be interrelated and the forms they must take. E.g. filesystems impose metadata on their objects, task manager apps impose ways that tasks can be organised, etc.
3. *Identity*, which conditions the ways objects can be considered the same. This is the least-explored part of the paper so far but is super important, I think there's a lot of under-explored ways we can manage identity, but currently this is left to the mutability rules of a system (e.g. file modification) or is implicit in the structure and use of objects (e.g. we consider an image in two formats to be the same). This topic is so big and interesting it may merit its own paper, and I do have one idea for a generalisable approach, which is to view identity as a kind of *governance.* That is to say, that identity comes first from the ways that *people* agree that something is the same. We could imagine identity systems that are highly pluralistic with many overlapping identities. This governance position is currently dominated by system designers such as those designing filesystems, but I think we could articulate a much more decentralised and participatory approach to identity.
Looking at the "wants from objects", what do different discourses want from the objects of concern in their discourse? Malleable software wants interface objects that can are independent of apps; Itemised systems want user-facing data objects to be independent of application boundaries and freely structurable (calendar events, notes, tasks, contacts, etc); post-document systems want the objects currently hidden inside documents to be decoupled from the documents; and so on... One running theme through a lot of these wants is that objects should be robustly referenceable and independent, and that we need to *disaggregate* key objects into smaller referenceable parts. I'd like to expand and articulate these wants through the dimensions laid out earlier in the paper. And I'd like to argue that these discourses should be articulating demands of information *infrastructure* to enable success with these efforts, and recognise the limits of building isolated systems or new platforms — though this can be an effective way of exploring their goals.
I'd like to explore the predictive and explanatory power of this work. If it is a truly *robust* theory, which I think it could become, this needs to be proved out more empirically. Part of this would involve expanding approaches to analysis, while the dimensions are a nice start I would like to do a more systemic analysis of objects "in the wild" and explore the possibilities of formalising some of this work.
While individual systems have been explored, in practice these systems overlap and interconnect in many ways. Characterising interrelationships among multiple systems is a key point to expand on. E.g. the relation between an interface element and the "code" objects that underly it. There's lots of work that cares about these relationships and tries to do things with them, such as bidirectional lenses, linking languages, or linked data protocols. An empirical analysis would need to consider the many systems in seemingly "singular" objects: a JSON file, for example, involves file objects, unicode objects, named ontology elements, and these all interact nontrivially, such as the way that hierarchical structure is encoded in a linear structure of unicode objects.
There's a lot that could be said about expressibility, user agency, and the role of objects in "digital language" — as through reference we create new “words" to speak *with* and new objects to speak *about.*
I'd like to explore implications for infrastructure design, and this is probably a theme that needs to run through the rest of the paper...
There's a political-economic dimension, mentioned in the "public-private" dimension, that's worth expanding on. Referenceability is one way that companies can obstruct more open, decentralised, and I think generally "better" systems from emerging. One could argue that some companies benefit from a "monopoly on referenceability" and that this is something we should try and escape, a fun idea here is to borrow the notion of "adversarial interoperability" and advocate for a kind of "adversarial referenceability" as a political/economic demand [@Doctorow_2019a].
Through this work it became clear that certain roles of objects are poorly supported:
1. *semantic objects* — which gain usefulness through being stable tokens around which semantic structure can emerge — are poorly supported in our systems. Unicode words or phrases are nice tokens, but are highly dependent on files and are not independent in the way we'd like. Files (especially content-addressed ones) are stable and independent but are primarily *pointers* and have too much imposed structure to be good semantic objects. Imagining the best of both worlds is interesting to me: objects that are robust, atemporal, independent, tokens. Imagine if a phrase like "graph databases" could be its own object with a robust reference like a hash, which could be freely linked to, put into relation with other objects and be used in many contexts and places and not tied to a specific system (as files tend to be, but words do not)...
2. *relational objects* — which gain usefulness through expressing relations *between* objects — are also poorly served, as most relations are implicitly embedded in systems and have no independent representation. Research to address this often imposes *a ton* of assumptions and conditions, such as RDF or other semantic web efforts. I'm interested to explore what can be done here and am working on one approach for content-addressed systems with *content-addressed relations*, these do not impose (but can support the representation of) structure — no ordering of relata, no types/labels, no set arity, etc. These relational objects are compelling to me because they can be stable, independent, atemporal, and granular. One could imagine an ambient graph-like network emerging not through some decentralised database or protocol, but as a side effect of creating these kinds of relational objects in many different contexts.
I've focused on limited kinds of objects, things like files, words, PDFs, reminders, etc. Objects that are mostly referenced through *addressing systems.* The choice of examples in this paper need to be interrogated a lot more and there are other kinds of objects which I barely addressed at all, like the artefacts of HCI research: buttons, widgets, etc. Grappling with the wider existence of objects feels out of scope but is pretty important if this theory is to stand up to scrutiny.
Lastly, an obvious omission to this paper and discussion is a deeper exploration of the *usefulness* of this work to *specific* research efforts, this needs to change but I am still figuring out which discourses and specific research work I want to give the most attention in this paper. Feedback on this is *incredibly welcome*!
There's much more to do! And much to do that I *do not know about yet*! If you can help me figure out *any* of this I will be eternally grateful!
# References {.unnumbered}

39
public/posts_md/wobblywoo.md
View File

@ -1,39 +0,0 @@
---
title: "Some temporary title"
date: 2023-02-17
location: Mars
---
# Discussion
I'm going to switch modes for this last section. I've run out of steam for this draft, so let me just touch on some things I might like to discuss in colloquial language.
Identifying three key responsibilities or roles of "object systems", and arguing that the tight coupling of these responsibilities is detrimental to our information infrastructure. Decoupling these is key to enabling "better" objects:
1. *Reference*, which conditions the ways objects come to exist and several of their key properties.
2. *Structure*, which conditions how objects are or can be interrelated and the forms they must take. E.g. filesystems impose metadata on their objects, task manager apps impose ways that tasks can be organised, etc.
3. *Identity*, which conditions the ways objects can be considered the same. This is the least-explored part of the paper so far but is super important, I think there's a lot of under-explored ways we can manage identity, but currently this is left to the mutability rules of a system (e.g. file modification) or is implicit in the structure and use of objects (e.g. we consider an image in two formats to be the same). This topic is so big and interesting it may merit its own paper, and I do have one idea for a generalisable approach, which is to view identity as a kind of *governance.* That is to say, that identity comes first from the ways that *people* agree that something is the same. We could imagine identity systems that are highly pluralistic with many overlapping identities. This governance position is currently dominated by system designers such as those designing filesystems, but I think we could articulate a much more decentralised and participatory approach to identity.
Looking at the "wants from objects", what do different discourses want from the objects of concern in their discourse? Malleable software wants interface objects that can are independent of apps; Itemised systems want user-facing data objects to be independent of application boundaries and freely structurable (calendar events, notes, tasks, contacts, etc); post-document systems want the objects currently hidden inside documents to be decoupled from the documents; and so on... One running theme through a lot of these wants is that objects should be robustly referenceable and independent, and that we need to *disaggregate* key objects into smaller referenceable parts. I'd like to expand and articulate these wants through the dimensions laid out earlier in the paper. And I'd like to argue that these discourses should be articulating demands of information *infrastructure* to enable success with these efforts, and recognise the limits of building isolated systems or new platforms — though this can be an effective way of exploring their goals.
I'd like to explore the predictive and explanatory power of this work. If it is a truly *robust* theory, which I think it could become, this needs to be proved out more empirically. Part of this would involve expanding approaches to analysis, while the dimensions are a nice start I would like to do a more systemic analysis of objects "in the wild" and explore the possibilities of formalising some of this work.
While individual systems have been explored, in practice these systems overlap and interconnect in many ways. Characterising interrelationships among multiple systems is a key point to expand on. E.g. the relation between an interface element and the "code" objects that underly it. There's lots of work that cares about these relationships and tries to do things with them, such as bidirectional lenses, linking languages, or linked data protocols. An empirical analysis would need to consider the many systems in seemingly "singular" objects: a JSON file, for example, involves file objects, unicode objects, named ontology elements, and these all interact nontrivially, such as the way that hierarchical structure is encoded in a linear structure of unicode objects.
There's a lot that could be said about expressibility, user agency, and the role of objects in "digital language" — as through reference we create new “words" to speak *with* and new objects to speak *about.*
I'd like to explore implications for infrastructure design, and this is probably a theme that needs to run through the rest of the paper...
There's a political-economic dimension, mentioned in the "public-private" dimension, that's worth expanding on. Referenceability is one way that companies can obstruct more open, decentralised, and I think generally "better" systems from emerging. One could argue that some companies benefit from a "monopoly on referenceability" and that this is something we should try and escape, a fun idea here is to borrow the notion of "adversarial interoperability" and advocate for a kind of "adversarial referenceability" as a political/economic demand [@Doctorow_2019a].
Through this work it became clear that certain roles of objects are poorly supported:
1. *semantic objects* — which gain usefulness through being stable tokens around which semantic structure can emerge — are poorly supported in our systems. Unicode words or phrases are nice tokens, but are highly dependent on files and are not independent in the way we'd like. Files (especially content-addressed ones) are stable and independent but are primarily *pointers* and have too much imposed structure to be good semantic objects. Imagining the best of both worlds is interesting to me: objects that are robust, atemporal, independent, tokens. Imagine if a phrase like "graph databases" could be its own object with a robust reference like a hash, which could be freely linked to, put into relation with other objects and be used in many contexts and places and not tied to a specific system (as files tend to be, but words do not)...
2. *relational objects* — which gain usefulness through expressing relations *between* objects — are also poorly served, as most relations are implicitly embedded in systems and have no independent representation. Research to address this often imposes *a ton* of assumptions and conditions, such as RDF or other semantic web efforts. I'm interested to explore what can be done here and am working on one approach for content-addressed systems with *content-addressed relations*, these do not impose (but can support the representation of) structure — no ordering of relata, no types/labels, no set arity, etc. These relational objects are compelling to me because they can be stable, independent, atemporal, and granular. One could imagine an ambient graph-like network emerging not through some decentralised database or protocol, but as a side effect of creating these kinds of relational objects in many different contexts.
I've focused on limited kinds of objects, things like files, words, PDFs, reminders, etc. Objects that are mostly referenced through *addressing systems.* The choice of examples in this paper need to be interrogated a lot more and there are other kinds of objects which I barely addressed at all, like the artefacts of HCI research: buttons, widgets, etc. Grappling with the wider existence of objects feels out of scope but is pretty important if this theory is to stand up to scrutiny.
Lastly, an obvious omission to this paper and discussion is a deeper exploration of the *usefulness* of this work to *specific* research efforts, this needs to change but I am still figuring out which discourses and specific research work I want to give the most attention in this paper. Feedback on this is *incredibly welcome*!
There's much more to do! And much to do that I *do not know about yet*! If you can help me figure out *any* of this I will be eternally grateful!
# References {.unnumbered}

4
public/stream.jsonl
View File

@ -1,4 +0,0 @@
{"date":"2019-01-01T00:00:00.000Z","text":"# This is a test\nhere is some text... I think once I can author posts and thoughts in here, I'll be able to get a lot more done.\n","id":0}
{"date":"2020-01-01T00:00:00.000Z","text":"Lorum ipsum dolor sit amet, conse.\n- This is a task\n- This is another task\n","id":1}
{"date":"2023-05-11T00:00:00.000Z","text":"multiple file formats\n\n\n- heterogenous decentralisation\n- cats is about objects which are processes, making them deployable as infrastructure\n- processes are blocks. cats, like blocks, do not care what the objects being processed are\n- RIDs for CARs? (is this RIDs for identity too?)\n\t- how to represent and deploy inter-systemic (Identity) relations\n- are relations the same as blocks? are they a superset? subset?\n- to Z: how would a non-process relation be represented as a block? i.e. relations\n\t- symmetric blocks? \n- content-addressed files form a network of acyclical reference\n\nportable relations & (RIDs for) content-addressed relations\n```\nRID[CID] -> {\n\trelation: RID (Identity)\n\trelata: set | (set, set)\n}\n```\n\n```\nAdd -> {\n\trelation: AddBlock\n\trelata: [\n\t\tspace_1,\n\t\tspace_2\n\t]\n}\n\nReduceDimensions -> {\n\trelation: ReduceDimensionsProcess\n\trelata: {...}\n}\n\nIsomorphic -> {\n\trelation: Isomorphism\n\trelata: {...}\n}\n```\n\n```\nIdentity -> {\n\trelation: Identity\n\trelata: {O1, O2, ..., On}\n}\n```\n\nIdentity and symmetric functions\n\n$C(S, D) \\land \\forall O_1, O_2 \\in \\text{Identity}: S(O_1, O_2) \\land (O_1 \\neq O_2 \\rightarrow D(O_1, O_2))$\n\n- $S(f, g) \\equiv \\forall x \\in \\text{Domain}(f) \\cap \\text{Domain}(g): f(x) = g(x)$\n\n$S((f_1, g_1), (f_2, g_2)) \\equiv \\forall a \\in \\text{Domain}(f_1) \\cap \\text{Domain}(f_2): g_1(f_1(a)) = a = g_2(f_2(a))$ and $\\forall b \\in \\text{Domain}(g_1) \\cap \\text{Domain}(g_2): f_1(g_1(b)) = b = f_2(g_2(b))$.\n","id":2}
{"date":"2023-05-11T00:00:00.000Z","text":"I need to try and catch this system out with some `special characters` and unescaped bit's of stuff... What about links? [like this](https://www.google.com)","id":3}

5
public/stream_md/1.md
View File

@ -1,5 +0,0 @@
---
date: 2019-01-01 00:00:00
---
# This is a test
here is some text... I think once I can author posts and thoughts in here, I'll be able to get a lot more done.

6
public/stream_md/2.md
View File

@ -1,6 +0,0 @@
---
date: 2020-01-01 00:00:00
---
Lorum ipsum dolor sit amet, conse.
- This is a task
- This is another task

4
public/stream_md/3.md
View File

@ -1,4 +0,0 @@
---
date: 2023-05-11 00:00:00
---
I need to try and catch this system out with some `special characters` and unescaped bit's of stuff... What about links? [like this](https://www.google.com)

58
public/stream_md/4.md
View File

@ -1,58 +0,0 @@
---
date: 2023-05-11 00:00:00
---
multiple file formats
- heterogenous decentralisation
- cats is about objects which are processes, making them deployable as infrastructure
- processes are blocks. cats, like blocks, do not care what the objects being processed are
- RIDs for CARs? (is this RIDs for identity too?)
- how to represent and deploy inter-systemic (Identity) relations
- are relations the same as blocks? are they a superset? subset?
- to Z: how would a non-process relation be represented as a block? i.e. relations
- symmetric blocks?
- content-addressed files form a network of acyclical reference
portable relations & (RIDs for) content-addressed relations
```
RID[CID] -> {
relation: RID (Identity)
relata: set | (set, set)
}
```
```
Add -> {
relation: AddBlock
relata: [
space_1,
space_2
]
}
ReduceDimensions -> {
relation: ReduceDimensionsProcess
relata: {...}
}
Isomorphic -> {
relation: Isomorphism
relata: {...}
}
```
```
Identity -> {
relation: Identity
relata: {O1, O2, ..., On}
}
```
Identity and symmetric functions
$C(S, D) \land \forall O_1, O_2 \in \text{Identity}: S(O_1, O_2) \land (O_1 \neq O_2 \rightarrow D(O_1, O_2))$
- $S(f, g) \equiv \forall x \in \text{Domain}(f) \cap \text{Domain}(g): f(x) = g(x)$
$S((f_1, g_1), (f_2, g_2)) \equiv \forall a \in \text{Domain}(f_1) \cap \text{Domain}(f_2): g_1(f_1(a)) = a = g_2(f_2(a))$ and $\forall b \in \text{Domain}(g_1) \cap \text{Domain}(g_2): f_1(g_1(b)) = b = f_2(g_2(b))$.

25
rome.json
View File

@ -1,25 +0,0 @@
{
"$schema": "https://docs.rome.tools/schemas/12.1.3/schema.json",
"organizeImports": {
"enabled": false
},
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
},
"javascript": {
"formatter": {
"semicolons": "asNeeded",
"quoteStyle": "single"
}
},
"formatter": {
"enabled": true,
"indentStyle":"space"
},
"files": {
"ignore": ["src/parsers/*"]
}
}

38
scripts/prebuild.mjs
View File

@ -1,38 +0,0 @@
import {glob} from 'glob';
import fs from 'fs';
import fm from 'front-matter';
function loadPosts() {
const posts_dir = 'public/posts_md/';
const posts = glob.sync(`${posts_dir}*.md`).map((file) => {
const content = fs.readFileSync(file, 'utf8');
const slug = file.replace(`${posts_dir}`, '').replace('.md', '');
const { title, date, location } = fm(content).attributes;
return { date, slug, title, location };
});
return posts.sort((a, b) => new Date(a.date) - new Date(b.date));
}
function loadStream() {
const streams_dir = 'public/stream_md/';
const posts = glob.sync(`${streams_dir}*.md`).map((file) => {
const content = fs.readFileSync(file, 'utf8');
const md = fm(content)
const { date } = md.attributes;
const text = md.body;
return { date, text };
});
posts.sort((a, b) => new Date(a.date) - new Date(b.date))
posts.forEach((post, i) => {
post.id = i;
})
return posts
}
function saveJsonl(entries, file) {
fs.writeFileSync(file, entries.map((e) => JSON.stringify(e)).join('\n'));
}
saveJsonl(loadPosts(), 'public/posts.jsonl');
saveJsonl(loadStream(), 'public/stream.jsonl');

42
src/components/Header.tsx
View File

@ -1,42 +0,0 @@
import { Box, createStyles, Container, Group, Anchor } from '@mantine/core'
const useStyles = createStyles((theme) => ({
home: {
color: theme.black,
fontFamily: theme.headings.fontFamily,
marginRight: theme.spacing.sm,
fontSize: '1.1em',
fontWeight: 700,
'&:not(:hover)': {
textDecoration: 'none',
},
},
link: {
color: theme.black,
fontFamily: theme.headings.fontFamily,
fontSize: '1.1em',
fontWeight: 400,
'&:not(:hover)': {
textDecoration: 'none',
},
},
}))
export function Header({ dark }: { dark?: boolean }) {
const { classes } = useStyles()
return (
<Box bg={dark ? 'red' : ''} py="2rem">
<Container size="40em">
<Group align="end" spacing="sm">
<Anchor href="/" className={classes.home}>
orion reed
</Anchor>
<Anchor href="/posts" className={classes.link}>
posts
</Anchor>
<Anchor href="/stream" className={classes.link}>
stream
</Anchor>
</Group>
</Container>
</Box>
)
}

7
src/hooks/useTitle.ts
View File

@ -1,7 +0,0 @@
import { useEffect } from 'preact/hooks'
export function useTitle(title: string) {
useEffect(() => {
document.title = `${title} | Orion Reed`
}, [])
}

29
src/index.tsx
View File

@ -1,29 +0,0 @@
import 'preact/debug'
import { render } from 'preact'
import Router from 'preact-router'
import { Home } from '@/pages/Home'
import { Posts } from '@/pages/Posts'
import Post from '@/pages/Post'
import Stream from '@/pages/Stream'
import { NotFound } from '@/pages/404'
import { MantineProvider } from '@mantine/styles'
import { Box } from '@mantine/core'
import { theme } from '@/theme'
export function App() {
return (
<MantineProvider withGlobalStyles withNormalizeCSS theme={theme}>
<Box mb="xl">
<Router>
<Home path="/" />
<Posts path="/posts" />
<Post path="/posts/:title" />
<Stream path="/stream" />
<NotFound default />
</Router>
</Box>
</MantineProvider>
)
}
render(<App />, document.getElementById('app'))

8
src/pages/404.tsx
View File

@ -1,8 +0,0 @@
export function NotFound() {
return (
<section>
<h1>404: Not Found</h1>
<p>It's gone :(</p>
</section>
);
}

45
src/pages/Home.tsx
View File

@ -1,45 +0,0 @@
import { Header } from '@/components/Header'
import { useTitle } from '@/hooks/useTitle'
import { Container, Text, Title, Anchor, Space } from '@mantine/core'
export function Home() {
useTitle('Home')
return (
<>
<Header />
<Container size="40em">
<Title order={3}>Hello! 👋</Title>
<Text>
My research investigates the intersection of computing, human-system
interfaces, and emancipatory politics. I am interested in the
potential of computing as a medium for thought, as a tool for
collective action, and as a means of emancipation.
</Text>
<Text>
My current focus is basic research into the nature of digital
organisation, developing theoretical toolkits to improve shared
infrastructure, and applying this research to the design of new
systems and protocols which support the self-organisation of knowledge
and computational artifacts.
</Text>
<Title order={3}>My work</Title>
<Text>
Alongside my independent work I am a researcher at{' '}
<Anchor href="https://block.science/">Block Science</Anchor> building{' '}
<i>knowledge organisation infrastructure</i> and at{' '}
<Anchor href="https://economicspace.agency/">ECSA</Anchor> working on{' '}
<i>computational media</i>. Previous work includes software and video
game development, programming tools, and film production. I have
expertise in knowledge representation, programming systems design, and
human-computer interaction.
</Text>
<Title order={3}>Get in touch</Title>
<Text>
I am occasionally active on Twitter as <i>@OrionReedOne</i> and on
Mastadon as <i>@orion@hci.social</i>. The best way to reach me is
through Twitter or my email, <i>me@orionreed.com</i>
</Text>
</Container>
</>
)
}

87
src/pages/Post.tsx
View File

@ -1,87 +0,0 @@
import {
Box,
Container,
Text,
TypographyStylesProvider,
createStyles,
Group,
} from '@mantine/core'
import Markdown from 'markdown-to-jsx'
import fm from 'front-matter'
import { readingTime } from 'reading-time-estimator'
import { Header } from '@/components/Header'
import { getCurrentUrl } from 'preact-router'
import { useState, useEffect } from 'preact/hooks'
import { friendlyDate } from '@/utils'
import { useTitle } from '@/hooks/useTitle'
const useStyles = createStyles((theme) => ({
title: {
color: theme.black,
fontSize: '2.5em',
fontWeight: 400,
},
subtitle: {
color: theme.black,
fontSize: '2em',
fontWeight: 400,
},
info: {
color: theme.black,
opacity: 0.8,
fontWeight: 500,
},
}))
async function getPost(name: string) {
const response = await fetch(`${name}.md?raw`)
return fm(await response.text())
}
export default function Post() {
const current = getCurrentUrl().split('/')[2]
console.log(current)
const [post, setPost] = useState(null)
const { classes } = useStyles()
useEffect(() => {
if (current) {
getPost(`/posts_md/${current}`).then(setPost)
}
}, [current])
if (!post) {
return (
<>
<Header />
</>
)
} else {
useTitle(post.attributes.title)
const readTime = readingTime(post.body).text
const date = friendlyDate(post.attributes.date)
const location = post.attributes.location
return (
<>
<Header dark />
<Box mb="lg" bg="red" py="lg">
<Container size="40em">
<Text className={classes.title}>{post.attributes.title}</Text>
<Text className={classes.subtitle}>{post.attributes.subtitle}</Text>
<Group position="apart">
<Text className={classes.info}>{date}</Text>
<Text className={classes.info}>{location}</Text>
<Text className={classes.info}>{readTime}</Text>
</Group>
</Container>
</Box>
<Container size="40em">
<TypographyStylesProvider>
<Markdown>{post.body}</Markdown>
</TypographyStylesProvider>
</Container>
</>
)
}
}

75
src/pages/Posts.tsx
View File

@ -1,75 +0,0 @@
import { Header } from '@/components/Header'
import {
Container,
Group,
Title,
Text,
Anchor,
useMantineTheme,
createStyles,
} from '@mantine/core'
import { friendlyDate, getJsonl } from '@/utils'
import { useTitle } from '@/hooks/useTitle'
const posts = await getJsonl('/posts.jsonl')
const useStyles = createStyles((theme) => ({
index: {
fontFamily: theme.fontFamilyMonospace,
fontSize: '0.75em',
alignSelf: 'flex-end',
},
date: {
fontFamily: theme.fontFamilyMonospace,
fontSize: '0.75em',
alignSelf: 'flex-end',
},
}))
function PostListItem({ slug, title, date, index }) {
const { classes } = useStyles()
const black = useMantineTheme().black
return (
<Group>
<Text color="dimmed" className={classes.index}>
{`${index}`.padStart(3, '0')}
</Text>
<Anchor href={`posts/${slug}`} td="none" color={black}>
{title}
</Anchor>
<Text color="dimmed" fs="italic" className={classes.date}>
{friendlyDate(date, 'MMM dd')}
</Text>
</Group>
)
}
function Frame({ children }) {
return (
<>
<Header />
<Container size="40em">
<Title>2023</Title>
{children}
</Container>
</>
)
}
export function Posts() {
useTitle('Posts')
return (
<Frame>
{posts.map((post, index, array) => {
return (
<PostListItem
slug={post.slug}
title={post.title}
date={post.date}
index={array.length - 1 - index}
/>
)
})}
</Frame>
)
}

159
src/pages/Stream.tsx
View File

@ -1,159 +0,0 @@
import {
Group,
Text,
Container,
Stack,
Flex,
createStyles,
Title,
TextInput,
Anchor,
} from '@mantine/core'
import { Header } from '@/components/Header'
import Markdown from 'markdown-to-jsx'
import MiniSearch from 'minisearch'
import { signal } from '@preact/signals'
import { friendlyDate, getJsonl } from '@/utils'
import { useTitle } from '@/hooks/useTitle'
const search = signal('')
const streamItems = await getJsonl('/stream.jsonl')
const miniSearch = new MiniSearch({
fields: ['text'], // fields to index for full-text search
storeFields: ['date', 'text'], // fields to return with search results
searchOptions: {
fuzzy: 0.1,
prefix: true,
},
})
miniSearch.addAll(streamItems)
const heading = { fontSize: '1.2em', marginBottom: 0 }
const margin = '0.3em'
const marginY = { marginTop: margin, marginBottom: margin }
const useStyles = createStyles((theme) => ({
group: {},
item: {
color: theme.black,
fontFamily: theme.headings.fontFamily,
lineHeight: '1.2em',
flexWrap: 'nowrap',
fontSize: '0.85em',
'& :first-of-type': {
marginTop: 0,
},
'& p': marginY,
'& ul': { ...marginY, marginLeft: '0em', paddingLeft: '1em' },
'& blockquote': {
marginTop: '0.8em',
marginBottom: '0.8em',
marginLeft: 0,
paddingLeft: '1em',
borderLeft: `0.25em solid ${theme.colors.gray[3]}`,
},
'& h1': heading,
'& h2': heading,
'& h3': heading,
'& h4': heading,
'& h5': heading,
'& h6': heading,
'& code': {
fontFamily: theme.fontFamilyMonospace,
background: theme.colors.gray[1],
borderRadius: theme.radius.sm,
paddingLeft: '0.2em',
paddingRight: '0.2em',
fontSize: '0.8em',
},
'& pre': {
background: theme.colors.gray[1],
padding: theme.spacing.sm,
borderRadius: theme.radius.sm,
},
},
date: {
fontFamily: theme.fontFamilyMonospace,
fontSize: '0.8em',
marginRight: '0.2em',
whiteSpace: 'nowrap',
},
search: {
'& input': {
':focus': {
border: `1px solid ${theme.colors.gray[4]}`,
},
fontFamily: theme.headings.fontFamily,
fontWeight: 500,
},
},
}))
const markdownOptions = {
overrides: {
a: Anchor,
},
}
function StreamItem({ date, markdown }) {
const { classes } = useStyles()
return (
<Group className={classes.item} align="start">
<Text color="dimmed" className={classes.date}>
{friendlyDate(date, 'dd/MMM/yyyy')}
</Text>
<Flex>
<Markdown options={markdownOptions}>{markdown}</Markdown>
</Flex>
</Group>
)
}
type StreamItem = {
date: string
markdown: string
}
function Search() {
const { classes } = useStyles()
return (
<TextInput
onInput={(event) => {
search.value = event.target.value
}}
my="sm"
size="md"
variant="filled"
placeholder="Search..."
className={classes.search}
/>
)
}
export default function Stream() {
useTitle('Stream')
const { classes } = useStyles()
const results = !search.value
? streamItems
: miniSearch.search(search.value).sort((a, b) => (a.date > b.date ? 1 : -1))
return (
<>
<Header />
<Container size="40em" className={classes.group}>
<Title order={2}>What is this?</Title>
<Text>
This <b>stream</b> is a place for me to think out loud and to share as
I learn. It's not a place for well-formed ideas or for things I'm sure
about. It's a place to explore, to be wrong, and to trust the reader
(and myself) that this is okay.
</Text>
<Search />
<Stack>
{results.map((s) => {
return <StreamItem markdown={s.text} date={s.date} />
})}
</Stack>
</Container>
</>
)
}

42
src/theme.ts
View File

@ -1,42 +0,0 @@
export const theme = {
fontFamily: 'Alegreya, serif',
fontFamilyMonospace: 'IBM Plex Mono, monospace',
headings: {
fontFamily: ['Alegreya Sans, sans-serif'],
fontWeight: 700,
},
lineHeight: 1.5,
fontSizes: {
xs: '0.6rem',
sm: '0.75rem',
md: '1.2rem',
lg: '1rem',
xl: '1.2rem',
},
black: '#24292e',
primaryColor: 'red',
components: {
Anchor: {
styles: (theme, { variant }) => ({
root: {
color: theme.black,
textDecoration: 'underline',
textUnderlineOffset: '0.15rem',
textDecorationThickness: '0.15rem',
textDecorationColor: theme.colors.dark[1],
'&:hover': {
textDecorationThickness: '0.15rem',
textDecorationColor: theme.black,
},
},
}),
},
Text: {
styles: (theme, { variant }) => ({
root: {
marginBottom: '0.6rem',
},
}),
},
},
}

13
src/utils.ts
View File

@ -1,13 +0,0 @@
import { format } from 'date-fns'
export function friendlyDate(dateString: string, format_str?: string): string {
const inputDate = new Date(dateString)
return format(inputDate, format_str || 'do MMM yyyy')
}
export async function getJsonl(file: string) {
const response = await fetch(file)
return (await response.text()).split('\n').map((post) => {
return JSON.parse(post)
})
}

36
tsconfig.json
View File

@ -1,18 +1,22 @@
{
"compilerOptions": {
"target": "ES2020",
"module": "ESNext",
"moduleResolution": "bundler",
"noEmit": true,
"allowJs": true,
"checkJs": true,
"jsx": "react-jsx",
"jsxImportSource": "preact",
"baseUrl": ".",
"types": ["vite/client"],
"paths": {
"@/*": ["src/*"]
},
},
"include": ["node_modules/vite/client.d.ts", "**/*"]
"compilerOptions": {
"lib": ["ESNext"],
"module": "esnext",
"target": "esnext",
"moduleResolution": "bundler",
"moduleDetection": "force",
"allowImportingTsExtensions": true,
"noEmit": true,
"composite": true,
"strict": true,
"downlevelIteration": true,
"skipLibCheck": true,
"jsx": "preserve",
"allowSyntheticDefaultImports": true,
"forceConsistentCasingInFileNames": true,
"allowJs": true,
"types": [
"bun-types" // add Bun global
]
}
}

5
vercel.json
View File

@ -1,5 +0,0 @@
{
"rewrites": [
{"source": "/(.*)", "destination": "/"}
]
}

35
vite.config.ts
View File

@ -1,35 +0,0 @@
import { defineConfig } from 'vite'
import preact from '@preact/preset-vite'
import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill'
import path from 'path'
import topLevelAwait from 'vite-plugin-top-level-await'
export default defineConfig({
plugins: [
preact(),
topLevelAwait({
promiseExportName: '__tla',
promiseImportName: (i) => `__tla_${i}`,
}),
],
assetsInclude: ['**/*.md'],
resolve: {
alias: {
'@': path.resolve(__dirname, './src'),
},
},
optimizeDeps: {
esbuildOptions: {
// Node.js global to browser globalThis
define: {
global: 'globalThis',
},
// Enable esbuild polyfill plugins
plugins: [
NodeGlobalsPolyfillPlugin({
buffer: true,
}),
],
},
},
})