My first reaction to this was (posted in a chat room):
My daily joke take:
That thing with static sites not supporting ActivityPub is really something the W3C WG needs to fix.
Unfortunately, I make bad jokes. So the problem has been floating around in my head. I actually donāt think any changes to ActivityPub are necessary for this. What one needs is a service to provide ActivityPub functionality. By this, I mean, the ability to use ActivityPub to interact with the site, e.g. given a page, I can like it.
Doesnāt BridgyFed support this kind of functionality? Iāve seen at least one other Fedi discussion about a service like this to support static websites (may have been under development), but unfortunately, I donāt have a link or remember the name of the project.
In other words, is there something that can be done so that ActivityPub gracefully degrades to something like RSS when implemented on static (or should we say āstatelessā) sites?
I like the āstatelessā characterization. The issue I see with degrading to RSS is that ActivityPub is primarily a push transport and RSS is a pull transport. Theoretically, servers could poll an AP outbox and that would be similar to RSS. However, I donāt know of any servers that do that and I donāt think thatās the behavior the AP spec authors intended.
As far as I can tell that requires Webmentions, and thus is not a static feature.
RSS provides the opposite of what Iām interested in. I want to allow people to interact with my site, not allow people to query my site for new content.
Yes, basically I want a way to provide a mechanism to generate a bidirectional link between āStatic Pagesā and āActivityPub objectsā. I actually donāt have an opinion which actor they would belong to.
The ActivityPub objects might be something like Proxy Objects. The big challenge here as with all proxying is feeding back the interactions with the ActivityPub object to the static site.
Iām not sure how relevant these are. Iāve had a curiosity about integrating fediverse into static sites myself.
I have stumbled upon two implementations of using the fediverse as a comment system on static site. They piggy back off of the Mastodon infrastructure. They may be of interest in this case:
You can also see them in use on the blogs themselves.
The cassidyjames blog says this about the comment system:
" Iāll leave a lot of the details for his post, but the super-simplified gist is:
Write a blog post
Post about it on Mastodon
Grab the resulting post ID and plug it back into the static site
The blog uses the Mastodon API client-side to fetch replies to the given post
Those replies are spit out onto the page and styled"
welcome to SocialHub and thanks for your post. I think it puts what I want into perspective:
Yes, one can probably use Mastodon to do what I want. I just feel like that Mastodon is a heavy solution ā¦
Second, if I want to have something like comment control. I will have to add this on top of Mastodon or wait for Mastodon to finally implement it. I would want comment control for what appears on my webpage.
I think I have a philosophical problem with it. Iād like my Fediverse applications to be small, instead of one monolith that more and more stuff gets added into.
I think pixels is the perfect Fediverse application in my eyes. Itās just like 200 lines of codes and does one thing.
My favorite option would be to have an actor listening for comment activities and compile new comments and deploy the site automatically. I mean, if the site is static, better avoid JavaScript integrating comments. But that might be yet another development step. I agree that something minimal like pixels would be a good option.
Welcome @dannymate and thank you for your useful input!
Thanks for the welcome :). I hope my input is always useful. Iām not a particularly talkative person so youāll rarely see me around. I also want to point out that this should be possible. Cactus Comments does something similar for Matrix.
So I think weād need a seperate service (as is mentioned in the OP) to provide extra functionality to static sites. In this case lets focus on a comment system. The blogs I provided before piggy-backed off of Mastodon which isnāt specialised in any way for this task.
Annoyingly thereās a gap in my understanding for Static sites and comments as it isnāt something Iāve implemented before. Iām also not an expert on ActivityPub. But Iāll try my best to break down the requirements.
Weāll want to avoid unecessary compilation so client-side comment fetching would be ideal. Therefore we donāt really want API calls from Fediverse to Blog. I know @how has voiced an opinion otherwise.
An ID system that doesnāt require a Post Blog > Reference Blog in Fediverse > Get post ID > Add ID to Blog Post flow. Though itās not a deal breaker.
Ideally we can use any ActivityPub compatible software. That way we can use Mastodon or something more single-user like bugle? or something custom. This allows people to avoid having to spin up their own server for comments.
We want to be able to control comments. For example, on the fediverse anyone can comment but only certain comments may be accepted onto the site. Or even an explicit approval first comment system.
I wonder if the comment control could be self-hosted seperately from a Mastodon/etc server.
Ideally we could rely on the relation between SocialHub account and Fediverse account to provide an AllowList, and have unknown accounts go into moderation. Most users here have put their Fediverse handle in their profile, and the ActivityPub plugin for Discourse now supports associating the two. So if we create a topic for each page, then replying to the topic (via Fediverse) updates the comments. Discourse has client-side integration of comments in this regard.
I must say that the original topic is about generic ways to add ActivityPub support for static sites, but we, especially I, have been talking about a specific use-case so far, related to the portal. (not that Iām fond of rockets either.)
The ideas & objectives section explains more about the project:
āBe able to share content onto matrix, from an entirely static setup (no dynamic server content generation, no database, just files and folders).ā
āThe purpose is not yet to have DM communication, but more public content from rooms, displayed via other matrix clients, without being able to participate in it.ā
It makes me wonder if something like this is feasible with Matrix why couldnāt it be done with ActivityPub? Well maybe in the end itāll serve to be impossible but itās worth keeping an eye on.
I donāt know anything about the portal but Iām interested in the topic in general. So if this topic is actually intended for the one thing then I doubt I can contribute.
Referencing a toot by Dr. Freemo who got static site AP working, and it is live on flear.org.
[ā¦] you can follow a user, and you get the accept backā¦ it even sends the create push to followers when new articles come out, so you get it in your feed.
Hi, I am the dev on this project. I just wanted to let everyone know that I was adding features and the code was broken for a day or two (though I didnt realize it at first. The code has since been fixed along with a ton of new features. I am also working on making the code easier to reuse, once that is done I will make a separate post about it. In the meantime it seems to be fully working so feel free to snatch the code or follow the account:
@flear@flear.org
Eventually I will move this into its own seperate repo as a boilerplate.
Sadly the firebase and vercel components are where the activitypub magic happens in terms of being able to respond to followers, and sending out create notifications. However if you run it as a purely static site all of the non-dynamic functions should work (for example your outbox will still list the articles and people will see your content from the fediverse but they wont be able to follow you).
I made the code mostly configurable via a toml file and some environment variables. So you can spin up your own version of the site very quickly. I also added very detailed step by step instructions anyone can use to bring up a copy of this site for themselves.
I will make its own post on this shortly, but it should be ready to play with . I just wanted to follow up here since this is where it was first mentioned.
Note the old page (https://flear.org) and itās handle will stay up but it will solely post on the topics it was intended to cover (open-source in ham radio).
Some of the features in the release are as follows:
Moved almost all site-specific stuff into configuration variables to make form easier install.
Organized the layouts/partials so that it is very easy to update the the templates.
Requires Vercel and Firebase for full ActivityPub support but will provide limited support as a purely static site as well. Limited support means the account can be seen, and its posts, but following wont be confirmed.
Wrote detailed step-by-step install instructions to make it easy for everyone.
Supports the following ActivityPub features:
Following confirmation
Notifications in your feed when new posts are made
The various pages show content from the fediverse interacting with it like reboosts, likes, and even replies which show up as comments on the page.
Tags are supported with a few options:
Tags can be configured to automatically be added to every post.
The tags added in the front-matter of a post can be added as fedivese tags. This can be set independently of any default tags.
Tags can be rendered invisibly, not showing in the text of the post on the fediverse yet still contain the tag metadata for searches
An ActivityPub alias can be set if you have other accounts across the fediverse. The alias can also allow you to migrate existing followers to the web page (untested, proceed at your own risk).
Microblog side-panel can be configured to show content from your alias fediverse account.
Multiple categories of blogs can be handled simultaniously and categorized and tagged independently.
Front page is constructed from markdown and broken up into short codes. So the front page can be modified without touching the html.
ActivityPub Rocks Portal: Technical Discussion: