Minimal wrapping of a source of posts

[eliemichel]

(My question may or may not make sense, I am new to AT proto and BlueSky)

As an experiment of syndication, I would like to turn my personnal blog into a source of bsky posts that one can follow. I am looking for an as minimal as possible solution, provided that I do not need this blog to react, get notifications, etc. I only need to emit content for now (as I would do with atom/RSS feeds).

I started considering writing my own PDS and only implementing a subset of xrpc methods, but after pulling one string after the other it feels I have to implement the whole PDS mechanism for this, which feels like I did not take the problem correctly.

Questions are:

• Is this something that make sense?
• How would you do it?
• Are there tools in this spirit already existing?

[snarfed]

Sounds like you may want an RSS bot? Eg https://www.bentasker.co.uk/posts/blog/software-development/automatically-posting-into-bsky-threads-and-nostr-from-python.html

[eliemichel]

It could be a workaround, but I am really interested in self-hosting! This blog post is about querying the API of the bsky.app instance as far as I understand. (And I am also taking this as an exercise to get started with AT proto self-hosting in general.)

[snarfed]

Ah ok! You're a bit early for self hosting, they haven't enabled federation in prod yet, they're aiming for early next year: https://atproto.com/blog/2023-protocol-roadmap

And you're right, you have to implement the full ATProto to build your own PDS - MST, repo chain, keys and sigs, websockets, event stream, etc. There aren't really any shortcuts other than starting from their official PDS codebase or a third party one like https://github.com/snarfed/arroba or https://github.com/DavidBuchanan314/picopds .

[eliemichel]

Yeah I know federation is still only in sandbox no worry! Thx for the pointers

[bnewbold]

As a longer-term idea, we think it would be cool if it was possible to host atproto repositories as static files on the web.

The way this would work is that software like wordpress or a static blog framework would compile a CAR file the same way they generate sitemap.xml or RSS files, updated when a blog post is created or updated. That CAR file would be signed by the repo signing key, then could be hosted at any URL on the public web. The blog server would send a crawl request notification to one or more BGS instances when the file is updated, as a latency optimization. The CAR could also be referenced from the account's DID document. BGS implementations would check if the CAR is updated (eg, ETag?), ingest the whole file (or maybe only new bytes appended to end? or some other network efficiency optimization?) and emit regular firehose delta events.

This is something we are pretty enthusiastic about, but is unfortunately far down the current timeline, probably later 2024 at earliest.

One of the motivations for this idea was difficulty in incorporating ActivityPub in to simple blogging system, eg: https://macwright.com/2022/12/09/activitypub

(no shade on ActivityPub; plenty of other folks have figured out ways to incorporate ActivityPub with blogging)

[eliemichel]

You use the conditional tense: does it means something is missing in the current state of the protocole in order to be able to achieve this? Or is it "just" tooling that is missing at this stage? I say "just" in the sense that I may write code by myself, but I may not change the protocole by myself. ;)

(Would love to give it a shot technically, but is there a way to get invite codes for the sandbox? I though the sandbox was invite-free but I cannot create an account on the dev instance for some reason)

[bnewbold]

The protocol doesn't support this today. We would need to add functionality to the BGS (crawler/aggregator) and document that in the protocol specs. And likely a new DID document "service" type, and generally better support in spec/implementations for accounts which don't have a "live interactive" PDS instance.

(the sandbox is for self-hosted PDS instances, not accounts on a PDS that Bluesky hosts. here are tips on getting started: https://github.com/bluesky-social/pds)

[bnewbold]

To directly answer your question, I think the best options today are:

• write a plugin for your blog software which works similarly to classic Twitter or Mastodon update plugins: when a new post is published, it does an API call to a full PDS instance with an announcement. This could be a self-hosted PDS, or connect to a hosting platform like bsky.social
• implement a minimal PDS instance in to your blog software. the PDS "role" in the network is smaller and simpler these days than in the past, but it still needs to implement all of the repo sync endpoints, including updating MST trees, signing content, emitting a websocket subscription feed, and servicing "getRepo" requests, which may be "since" some earlier revision of the repository. that's a bunch of work! and you'd still need to wire up the blog software to insert the content in to the repo.

As an analogy, how would you get blog content in to a git repo (if it wasn't already stored in git)? implementing git from scratch would be a lot of work.

[eliemichel]

Writing git from scratch is too much work, but writing a basic versionning system has good educational value. I'm interested in playing around with the protocole at first for my own personnal usage for now, and as a way to stress test the flexibility of the federation mechanism. :)