The process of integrating with standard.site has definitely been interesting.

My first attempt was using a tool called Sequoia, which is intended to let you take a static site like a blog and upload all of your content into standard.site. It handles the core use case reasonably well, but I ran into a few limitations as I pushed beyond the basics.

Issues with Sequoia

At the moment, it doesn’t seem to support having multiple publications on a single site. More specifically, it doesn’t appear to handle generating a subdirectory publication structure, which makes some workflows awkward. Long-term, I want multiple publications:

• A notes publication for articles and writing
• A projects publication for long-lived project writeups
• A ramblings publication for the kind of artifact you're reading right now

That doesn’t feel like a particularly unusual setup, but it’s not something Sequoia is currently designed around. I also had some trouble getting it to consistently respect custom slugs, which seems tied to the same directory-handling constraints. Because of this, I’ve been thinking about writing my own integration tool at some point.

Linking and URL problems

There’s another problem: sites like Leaflet will try to reference the content ID of your standard.site documents when they’re linking. Even though there is a path in the spec that should be used, Leaflet encodes both their path and content IDs. That’s fine for Leaflet, but I don’t want that because I like having pretty URLs. It also shouldn’t be just using the content ID, because that’s not how the spec works. Because of this, I’m thinking about finding Leaflet’s code and trying to fix that.

Other sites like Greengale will use the proper path, but because Sequoia isn’t setting those paths up the way I expect, links still don’t always resolve correctly.

Frontmatter parsing issues

Sequoia also seems to struggle with some frontmatter edge cases.

I have descriptions in my notes defined as multi-line strings. In spec-compliant YAML, these start with a pipe (|) and a new line, and then the whole description is indented so you can read it like a big block. In my case, Sequoia reduced those descriptions down to just the pipe character, which obviously isn’t ideal.

Understanding the lexicon (and its gaps)

I do think I now have a much better understanding of how the standard.site lexicon works and what needs to be done to integrate with it. I also think that the overall integration story could be a bit more polished.

One thing I’ve been thinking about is text content. When Sequoia pushed my posts into my PDS, it took the raw text contents of my posts (which were all in Markdown) and stored them directly as-is.

That’s not really what we want:

• There are many kinds of text formatting
• We don’t necessarily want raw Markdown everywhere

What we actually want is facets.

Facets confusion

I don’t currently know what facets I need to use. I know that Leaflet has facets that they use, and I know that Pocket has facets that they use, but I cannot find a comprehensive list of all the facets that are in standard.site right now.

I’d like to try querying them, but I’m not sure there’s a good way to do that.

Astro, rendering, and source of truth questions

I think I’d like something that integrates better with Astro, which is what I’m using, so I can have proper text formatting.

I don’t want to embed AT URIs in my blog. I don’t think. I mean, I probably should — or maybe I need to — because there’s the <link> tag you need to embed in your document pages to have standard.site verify that it’s the correct place for the content.

But I think I want my blog to be the authoritative source of truth.

Well… maybe I don’t. I don’t know.

I don’t know if I want my blog to be an app view, or if I want my blog to be the actual thing. Markdown is super easy to write, but if I did things correctly, I could just have the published version of my blog be an app view over my PDS that says “what posts are here?” and then renders whatever you have.

I don’t know. It’s weird.

Open questions about structure

I also don’t know if I can do things like:

• Featured content
• Series
• Other structural groupings

…if everything lives strictly in standard.site documents, unless there’s a way to extend them. Maybe I could make my own facets that I render myself or something. I don’t quite know.

Where I’m landing (for now)

Remaining able to author content on my blog and post it is important to me, and I want to keep that functionality.

At the same time, I want the ability to publish that content to my PDS without rough edges that I then have to clean up afterward.

Maybe I can improve Sequoia so it better supports these use cases, or maybe I’ll just do it myself. I know how to fix this; my problem is mostly figuring out what will work best for more people.

Contributing to Sequoia would be ideal, but I need to know what facets I’m using beforehand if I’m going to do that. It feels like a solid foundation that’s currently optimized for a fairly specific workflow, and expanding it could make it useful for a lot more people.