No Description

ryan rix 06a62f4cc3 Integrate foundation. This was difficult 1 week ago
assets 06a62f4cc3 Integrate foundation. This was difficult 1 week ago
config 6d4834fc0f and some thinking. let's get started. 1 week ago
lib 06a62f4cc3 Integrate foundation. This was difficult 1 week ago
priv 6d4834fc0f and some thinking. let's get started. 1 week ago
test 6d4834fc0f and some thinking. let's get started. 1 week ago
.formatter.exs 6d4834fc0f and some thinking. let's get started. 1 week ago
.gitignore 6d4834fc0f and some thinking. let's get started. 1 week ago 6d4834fc0f and some thinking. let's get started. 1 week ago
mix.exs 6d4834fc0f and some thinking. let's get started. 1 week ago
mix.lock 6d4834fc0f and some thinking. let's get started. 1 week ago


Arcology is an attempt to build a personal information management system. It grows out of a love of Emacs Org-mode and the principles behind it.

Arcology grows out of years of honing a computer down to a shape that fits naturally in my hand and head.

The road here has been slow and steady, and the road ahead stretches years, perhaps my career.

Let us begin.

Ideological in Nature

This software is ideological in nature, it will be designed simply to meet the needs of Ryan Rix.

A set of ideas to keep in mind when reading this code:

  • Arcology is self-sustaining, it is supposed to eliminate reliance on third-party applications
  • where possible, not simply integrate with them. APIs change and are deprecated, corporations cannot be trusted.
  • This is software for a power user, it is not to be trifled with.
  • This is software for an individual and maybe in the future a family.
  • I will assume a narrow subset of devices to support
  • I can make assumptions about deployment, and codify those as the system matures
  • (server-generated WireGuard configurations for privileged interfaces, for example)
  • This software doesn't need to be cheap to operate and it should be simple to operate.
  • Assume something will go viral, frontends scale appropriately.
  • There will be multiple views of the same content.
  • My mail and news client should have a mobile interface and a desktop view.
  • Sharing a news element should be a first-class action, across configurable channels.
  • Content should embed cleanly in other content. A blog post can embed a tweet and those are both
  • objects with their own URI and metadata.

Development Roadmap

Base MVP Components

These initial considerations are built around an MVP of providing an alternate implementation of GNUS Adaptive Scoring algorithm, paired with an RSS news fetching infrastructure for keeping up with subjects I care about across a broad range of topics.

But it's locked in to GNUS, it's locked in to Emacs, and it locks me to a platform that is essentially a Rube Goldberg machine around Emacs. I'm ready to build my own Rube Goldberg machine.

  • A graph database of metadata blobs
  • A full-text index, tagging, and scoring system
  • A set of query APIs which can be used to build data applications
  • Pluggable input and output systems
  • High-fidelity rendering of data objects in metadata blobs, and their relationships on the web.
  • Open web standards like microformats, RSS
  • Outbound email channel, including ability to send to groups
  • (family@arcology.example for example to send to all of your family)

On the horizon

Features, in rough order of priority after news client completion and polish:

  • Streamlined Content creation
  • Edit object in Emacs (as Org-mode, as JSON)
  • Quick web capture templates
  • Micropub client
  • "Applications" of a sort:
  • Task tracking and planning
  • General calendaring
  • Daily schedule reporting
  • Alerting around deadlines
  • Free/Busy viewing on the web and ical
  • Hierarchical inventory system
  • Physical resources supporting:
  • "Things go in other things, recursively"
  • Track serial numbers, resale/insurance value
  • Suggest Tidy-up activities
  • Digital resources (media, mainly)
  • Sensor data collection and presentation
  • ActivityPub support
  • Define arbitrary inboxes and outboxes as frontends
  • Offline actions

To enable these things:

  • Device-to-device of the metadata store
  • A content addressable store, local file system with configurable archive to Backblaze B2
  • Sync handled by Syncthing over a secure network like WireGuard.
  • Time-series database for single-point data
  • Embedded rendering like any other object
  • sparklines, graphs, etc

"But what if..."

Given a closed ecosystem, and a set of basic components like this, I can imagine a world where a set of devices sync their state and provide services to my self and my tribe and enables the lifestyle and values which I want to cultivate.

These things do not need to be in the same location, and they do not need to be homogeneous.

For the most part, we can assume things are freely internetworked using WireGuard.

I've been thinking about Capstone1 again.

I think it would be incredible to have a device like the Pixelbook or the Yoga Book which I could fit in a carry-on bag and take anywhere in the world. It syncs in the morning when I'm on WiFi in the hotel. I do whatever I want through out the day, reading ebooks, writing, creating, and then sync back when I get home. My travails are published to my website and emailed to my family. My server gets a sync of a bunch of metadata and then runs some reports.

What if this thing could program itself?

Store the code of each module in Arcology, with description and metadata like everything else. generate a deployment image from a metadata heirarchy, deploy that render the code on the web with privileged editing.

A fun first pass on this would be rendering ClojureScript to the web frontend in this respect.

Once this happens, what if we built a client delivered in this way, in a framework which can attain near-native performance?

A tablet and a mobile phone running Arcology, as a full-screen application framework, downloading the application code at startup from a local server

It's gonna take a while. I hope I can do it.


What follows for now is the Phoenix README converted to Org.

To start your Phoenix server:

  • Install dependencies with mix deps.get
  • Create and migrate your database with mix ecto.setup
  • Install Node.js dependencies with cd assets && npm install
  • Start Phoenix endpoint with mix phx.server or iex -S mix phx.server

Now you can visit http://localhost:4000 from your browser.

Ready to run in production? Please check our deployment guides.

Learn more