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.