high level roadmap (looking for collaborators)

[randName]

this will be the central repo for discussions related to both @musakui/fedi and kotori implementations e.g. kotori-netlify

ActivityPub

ActivityPub is the spec that (attempts to) standardize how federated social media should work. There are a few major implementers (Mastodon, Misskey, PeerTube) and forks that try to talk to each other.

For a quick rundown, I reccomend reading this guide on how to read the ActivityPub specs.

For me, the key takeaway is that there are 2 sets of things happening

when you post:

1. you make a post (could be a short note, article or even video) and send it to your server
2. your server takes the post and stores it somewhere, publicly available at some endpoint
3. your server sends it to each of your followers (their inbox endpoint)

when others post:

1. their server sends your inbox the thing (equivalent to step 3 above but from the other viewpoint)
2. your server checks that they actually sent it, then does stuff (if it is an action) or saves it to show you later
3. when you fire up your local timeline, those posts are retrieved and shown

All those steps do not actually require a server running full time, especially if you are the only one. There are implementations that are suited for single person instances (e.g. Pleroma), but they still retain the concept of a server, which costs money

The outbox can just be a collection of statically served files. Since the outbox is only ever updated when you post, it can just be rebuilt together with your action of posting.

The only part that actually requires a server is the inbox endpoint. But all it does is validating the request and perform state changes on some database. This is very well suited for serverless hosting.

Hence the whole idea for kotori is to rethink how to run ActivityPub instances on serverless (and not pay server fees. lol)

fedi

the main aim of fedi is to provide low-level helpers that should be as platform-agnostic as possible.

an example would be the HTTP Signatures library, which has both a node implementation and a browser implementation (albeit slightly lacking).

It will mostly be simple constants, TypeScript types (mainly through jsdoc comments) and defineFunctions (similar to how defineConfig works in vite)

kotori (this repo)

the main aim of kotori is to be a low-config rollup/vite plugin (potentially unplugin) that generates ActivityPub compliant static files that would be served up in a server-based setting.

Also, provide some generic handler interface for the serverless function inbox.

I'm still working on the appropriate level of abstraction, since different hosting providers will need different configurations.

[searls]

(Forgive me, as I'm brand new to all of this and haven't read the specs)

What I am hoping to accomplish with ActivityPub and my static sites is the ability for users of federated social networks (like Mastodon) to subscribe to a blog and receive notifications in their inbox of new and updated posts.

I'm imagining it'll look something like an outbox of static messages, internal files representing followers committed to the repo (for lack of another data store), a job that can be run post-deploy to notify followers, and a severless function to allow for follow/unfollow requests:

Blog publishes a post

1. Push changes to git, kicking off a Netlify deploy
2. Along with the pages of the hugo site, messages are built and stored statically in an /outbox endpoint
3. Whether on a post-deploy hook or as a severless function or a scheduled job, the server notifies each follower by posting to their inbox

Follower subscribes/unsubscribes to the blog

1. A netlify serverless function wakes up, receiving the request
2. Creates/edits/deletes an internal file representing the following and commits the changes to the git repo

Is this feasible? If so, is this the right project to accomplish some or all of this?

[randName]

Yeah, it seems pretty feasible, and I think we are probably on the same page with regards to the end goal. In terms of the size of the generated content it is definitely leaning more towards https://writefreely.org/, but ideally this system would work for any valid ActiviyStreams content (even video)

So based on your workflow:

Publishing

Recently I was looking into Netlify CMS as the main updating frontend, but have yet to look at how posts would be generated and assets would be handled

I will definitely need to incorporate a markdown parser or some other plugin system to convert the posts into ActivityStream objects.

1. Blog publishes a post (using Netlify CMS or something similar like StackBlitz WebPublisher)
2. Build step happens, kotori magic happens and generates all the relevant outbox files
3. If follower counts are low enough it might be possible to send to all of them in the build step (especially with sharedInbox deduplication). Otherwise some sort of delivery status needs to be stored if there is a scheduled job that comes to deliver everything

Subscriptions

pretty much everything there sounds like what I have attempted in a very early prototype.

The repo files were stored over at https://github.com/randName/activitypub-log because re-deploying the inbox and user profile everytime with the content seemed a little overkill.

The commit-based actions thing was a bit messy so I scrapped it (and also stopped work on it due to work).

[searls]

Recently I was looking into Netlify CMS as the main updating frontend, but have yet to look at how posts would be generated and assets would be handled

I use Netlify CMS for my blog justin.searls.co and talked about my current setup in this video. I can't speak for everything it does, and agree that your approach sounds right for publishing.

pretty much everything there sounds like what I have attempted in a very early prototype.

The repo files were stored over at https://github.com/randName/activitypub-log because re-deploying the inbox and user profile everytime with the content seemed a little overkill.

Yeah, that makes sense.

[randName]

watched your vid and just finished trying out Netlify CMS (which I found out was not doing too well but at least there is Static CMS on the horizon)

the step is to get some clean static site working and start converting posts into objects