So I added CalDAV and CardDAV servers to the task and contact management tools. It took a little back and forth to get it all working, but it is now, so I get decent mobile interfaces, “Hey Siri” to make new tasks, and my contacts live in a standard store there are plenty of tools to manage, not out on an island.

Which lets me get back to the bigger project, which is the lifting the abstraction layer and graph for tasks, contacts, mail, events, notes, etc. into its own service.

v1 was a hard-coded hairball of personal apps and external services. This version has an Archetype/Provider model for tasks, contacts, messages, and notes that can accept standard Oauth/API connections, MCPs, or piggyback on a local daemon if you need to get at your stuff with a local script via a tunnel.

The external provider coverage is thin right now: Google Mail, Google Calendar, and Fastmail. Last night I went ahead and signed up for Todoist so I can build my first external task provider with a standard API. Obsidian recently released a CLI, so that’s a candidate for a daemon-driven notes provider PoC. Apple Messages is another candidate for a daemon provider, too.

I also moved the idea of “receptors” — inference-driven behavioral interpreters that consume metadata from the task, contact, event, and note archetypes — into a Markdown/YAML-driven spec you can build with a skill. There are some out-of-the-box ones:

• priority inflation
• task avoidance
• contact neglect
• task staleness

When they’re triggered, they propose some kind of action: resetting the priority, bumping the deadline, reaching out to someone you haven’t, or deciding something doesn’t belong on the list after all.

Those all seem like useful things anyone could benefit from, but I think other people have other struggles particular to them, so the SKILL.md that helps you build a receptor has an interview component, and can introspect the system to understand what archetypes/providers are enabled and available to help with your particular thing you’re trying to deal with.

It was interesting to see someone else pulling on this thread a few days ago.

aCloud is my project-in-transition for keeping track of tasks, contacts, ideas, and previously notes. It doesn’t really do anything with notes anymore, because I don’t have any particularly strong ideas about notes, and how I keep them has changed a lot over time.

I do have ideas about how I want to process tasks that is less a breakthrough idea than it is a reflection on years of having tasks, and years of not liking most of my options for one reason or another. And I have an idea about managing contacts that comes down to, “I’m bad at it, and I’d like a tool that makes it easier to manage relationships.”

I also have an idea about all these things, which is that I’d like them to live in some kind of graph, that I’d like the graph to be agnostic about which tool I’m using to manage these things, and that I’d like to be able to surface the graph in whatever tools I’m using to interact with the graph.

The “in-transition” part is that aCloud started life as a kind of all-in-one productivity app, and then I layered in some ideas that leverage inference to do … stuff … that I don’t really feel like writing about right now, and then my thoughts about a tool-agnostic graph converged with that, and then I got tired of my mediocre notes implementation.

So I’ve started to tear out the interesting-to-me parts of aCloud’s inference layer into a service that manages just the graph, the inference layer, and the heartbeat for all of it.

The objects in that service’s graph all belong to a small collection of Archetypes:

• Notes
• Tasks
• People
• Ideas
• Events
• Logs

Because I worked where I did for a decade, the things providing the objects for each archetype are called Providers:

• Gmail messages & calendar events
• Fastmail messages & calendar events
• Notes
• aCloud tasks
• aCloud ideas
• Apple Messages

Some providers are ingested into the graph via standard APIs, some are driven by scripts running on my local machine with a secure tunnel to the service, and some are consumed via MCPs.

Other things could easily become providers: Tasks from Todoist, OmniFocus, Google Tasks, Jira, or Things; notes from Apple Notes, contacts from Apple or Google Contacts, messages from Slack. If it has an API you can talk to, or if you can figure out a command line tool to get its data out of its service, it’s a candidate.

The service isn’t really there to manage these things (that much). It’s just there to make associations between them, keep an eye on them, and (where inference comes in) make suggestions about them when it’s appropriate.

It’s not quite as easy to get these tools to surface the graph, at least the ones I don’t own. aCloud has an API for all this, and it’s a first class participant in the service. But I can’t tell Apple Messages to do anything with my graph, for instance.

But I do have a few notes-related tools for making or surfacing connections:

I made an LSP that lets me make inline wiki-style links by starting to type [[idea:]] or [[task:]] or [[person:]] and get an autcomplete that finishes a link. In Helix I can follow the reference to get to the web version of any of those things.

I also made an Obsidian extension that likewise surfaces these connections in a sidebar panel and also understands this link format:

If I’m working on a note that has associated people, tasks, or ideas I can see them in the panel and click a link to follow them to their aCloud versions. If I’m editing a document, I can create a link to any object in the graph. Regular Obsidian wikilinks still work, and the links are legible/human readable.

There’s no reason, over time, I couldn’t provide that for messages, etc. or use other providers. The service knows where all these things live.

So, onward with this.

Credit for ideas where they’re due:

I’m building toward something very much like the Emacs Remembrance Agent, and I think Hookmarks is pretty neat.