Standard Site support for Ghost, Discourse forums

Discussion
,
1

I saw a post from @balupton.bsky.social asking for standard .site support for Ghost. I couldn’t find the sort of working version of this that wasn’t a complete hack

We are migrating off Ghost for the community blog, and I produced ghostoff to turn it into Offprint records. Easy enough for someone to make Leaflet or Pckt or other types of recrods.

For Discourse, that’s an interesting one. We do want to show threads from here on https://atmosphere.community. I had thought of simply showing links, maybe even just using RSS, but yeah, making it Standard Site compatible would be nice.

If others want to see Discourse → Standard.Site, write down what your interests / requirements would be.

6 Likes
2

For discourse, I’ve written this several years ago:

Wrote it back in 2020 to render discourse comments for lectures into a custom study lecture player interface prototype with discourse threads for lecture notes, summaries, timestamped comments, etc; as well as for a meeting interface prototype, where discourse threads and comments were for meeting notes and agendas. Could be revived for ATProto exports and syncing.

4 Likes
3

Nice. @essentialrandom.bsky.social something that might work for us.

1 Like
4

Ok here’s the write up I was looking for on how to make this work for Ghost

3 Likes
5

More discussion re discourse imports:

6

Well I have something coming soon here…

image
image940×519 77.4 KB

…but this is a simple Astro content collection with the last 10 threads, no ATproto magic

I’ve been thinking about what would make sense for this + standard site. Something I keep pondering is a feed of content with “latest from the community” merged with “latest Discourse threads”. Standard Site documents can link out to a publication http URL + article path, which could be good for Discourse threads that don’t have corresponding records on ATproto. Atmosphere Community would hold the publication documents (which would be a thread) for the Discourse.

Regarding updating the feed, I wouldn’t want to publish a new entry for each reply, but it’d help to at least keep an eye for any new thread. And since BSky embeds StandardSite, we could always publish a post in the feed that says “4 new comments on this thread! [StandardSite embed]” when a burst of activity happens.

Re: Subaud.io’s write up, that is the other direction—which for us would be Discourse Forum entries become Valid StandardSite. Well, I guess I COULD start writing Discourse plugins, but you’ll have (even more of) my evenings on your conscience then :joy:

2 Likes
7

So, I work at Discourse and am familiar with the Discourse plugin side of things. A little less familiar with the standard.site side, but keen to learn. This is a pretty good for me to start getting involved here.

So I gave this a shot: built a Discourse plugin that exposes public Discourse topics as standard.site documents. The site is one publication, identified via handle/DID and an app password. Each topic OP is published as a document owned by the publication.

This is obviously a simpler approach vs having the topic author be the owner. That’s a possible next step, but the auth/verification flow is likely tricky. it might require changes to how people authenticate to the forum here.

Anyway, here’s the repo, vibe-coded, very much alpha software, but I’m up for updating and maintaining.

Here is an example document: at://did:plc:gatqn2muwdcnjql5lpkf5rof/site.standard.document/3mr4egyq5a6hb

How does this look?

4 Likes
8

this is fantastic! I just started added the list of posts on the main page but if we add this plugin (@bmann.ca? willing) I’d be happy to playing with it more. Could the atUri be exposed from the JSON API? Not sure what I’d do with it yet, but it’d be interesting. Definitely we should have people follow the publication and see how they feel about it!

For next steps I’d consider:

  • Surfacing the DID of a specific thread in its meta tags, so it can be recognized as such (taking a page out of this thread Mapping web pages to canonical AT records )
  • I guess letting people subscribe to the publication from the Astro site would be a thing.

I’m curious whether the auth/verification flow being (sort of) ATproto-powered makes this easier? Like we could assume it’s a pre-requisite for a stronger user <=> thread correspondence, and then worry about “standard Discourse” later.

9

@scottlanoue.com do you have a good process for adding plugins? We should document this in our internal community infra space.

10

Fortunately I didn’t have to install any plugins with our migration, everything we use is already in the base image (save for doc-categories which we dropped). I could be wrong (@musaraj.com please correct me if I am!) but I don’t think it’s a one-line drop into the compose, but instead we need to bake it into the image that’s used by our dokploy.

2 Likes
11

Seems doable, but can you specify exactly on which JSON API? Do you mean for the Discourse topic JSON response to include the atUri?

The plugin currently outputs this:

<link rel="site.standard.document" href="at://did:plc:gatqn2muwdcnjql5lpkf5rof/site.standard.document/3mr4egyq5a6hb">
<link rel="site.standard.publication" href="at://did:plc:gatqn2muwdcnjql5lpkf5rof/site.standard.publication/3mr4egm5pnxbi">

That’s what you meant, right?

@scottlanoue.com the standard site plugin is not part of core Discourse, so you likely do need to add a one-liner to install it after pulling the image. It should be the same process as what you had previously for doc-categories, though. In the usual Discourse installs, it would be something like this:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/pmusaraj/discourse-standard-site.git
2 Likes
12

I’m not super familiar with the terminology, but I would assume that a thread here is a topic and so this is the JSON API i’m talking about :slight_smile:

Yes…and no! We changed the tag types (long story, in the thread) so now this is:

<meta name="at:canonical" content="at://did:plc:gatqn2muwdcnjql5lpkf5rof/site.standard.document/3mr4egyq5a6hb" />
<meta name="at:alternate" content="at://did:plc:gatqn2muwdcnjql5lpkf5rof/site.standard.publication/3mr4egm5pnxbi" />

(the type of lexicon determines the type of information, and canonical vs alternate say which one is the main one and which one is just additional info).

14

Just noting that standard.site hasn’t formally adopted the proposal for at tags yet, but I’ve started a discussion with the team about migrating over to them (and most of the standard.site sites are already using them). My recommendation is to provide both for now.

1 Like
15

How much of a leap would it be to extend your plug-in with support for the Barazo lexicons? I.e. the prototypical atproto-forum lexicon, drafted by @gui.do greatly inspired by Discourse.

Being able to interface with this forum via a Barazo instance would be the main test case for that, though the use case that’s top of mind for me is the prospect of a Threads tab in mu.

1 Like
16

Sorry for the delay folks, I’m on my summer break.

This is now part of the plugin, the topic JSON endpoint (at /t/TOPIC_ID.json) will now include an atUri attribute.

This is done as well, the plugin now outputs both formats.

I will look into this in the coming weeks. I need to first get familiar with the Barazo lexicons.

A Threads tab in mu would be cool, not sure if the Barazon lexicon work will cover all that’s needed for that, possibly.

4 Likes