Comment by cxr
4 years ago
I'd like to see more attention put into carving out a subset of Mastodon's functionality that would allow you to host your fediverse node on a static site, à la blog feeds powered by RSS/Atom.
The discovery problem can be handled pretty straightforwardly: if you want notifications of replies to your posts, then that's just another feed that you subscribe to—a separate service. You don't exactly need an always-on "instance" providing an inbox endpoint to relay notifications to you.
You give up private channels (DMs), but you gain a lot more flexibility. It's a shame that there are so few server (and client) implementations for "the fediverse". We should have at least half as many options as we have in static site generators themselves. (In fact, with this approach, your preferred static site generator could become part of your "client"...)
Imagine your corner of the fediverse being reachable at $YOURNAME.github.io.
Prior art: Fritter <https://github.com/beakerbrowser/fritter>
Ey, I made Fritter. The “fr” shamelessly came from my last name. Actually the cooler thing was Rotonde, which Devine of 100 rabbits fame made. Beaker has the ability to duplicate somebody else’s website, which we called forking. So Devine made a social website where the whole application was the website software itself.
Bear in mind that beaker sites are like mutable torrents. They’re just collections of files. The fun is that you can read and write those files by an API. The js in Rotonde would detect if you owned the site, and then present a text input which would write a new text file in the posts folder. The site would then use js to read all its own post texts and the post texts of followed users to produce a feed. To create a new “account” you would fork an existing site, copying all the application software. This meant the software itself was literally viral. It was really cool.
If you think a bit about it, you can probably guess the problems we ran into (both with rotonde and fritter). Most of it had to do with scaling - as all this occurred in the frontend of these p2p sites - and multi device coordination. There was, however, a pretty intense zen simplicity in the pattern of websites that wrote their own files with JS, and I wouldn’t write the idea off entirely.
> Most of it had to do with scaling - as all this occurred in the frontend of these p2p sites
You didn't say it, exactly, but just in case anyone who's reading casually misses it: this need not be the case with the static fediverse. I didn't mention JS or any sort of fully in-browser aggregator; nothing here requires client logic running on the "frontend" (i.e. in a Web browser). You'd be free to make whatever client choices are appropriate for you, including managing the whole thing via shell scripts (as many people choose to with their static sites).
I think a static site hosted on git is the sweet spot for the fediverse. It's realistic to expect an HTTPS 1.1 static endpoint and openssh to have << 1 unauthenticated remotely exploitable bugs per year.
This opens up a whole new world of hosting options. Think a raspberry pi that auto backs up to github/gitlab/git, with an ACME / let's encrypt client.
Stick it behind the right CDN and it could even host podcasts / video.
Enable automatic OS upgrades and give it a maintenance window and it's zero maintenance until the $35 hardware fails.
Edit: Or be lazy and stick the static site in s3.
The difference is that dat, fritter, rotonde, and friends are p2p. There's no frontend in the traditional sense, just like there's no backend. It's all static files executed by a process. Imagine the same with .sh files and a shell executing them, all on your machine.
The static fediverse requires an always-on, network-available machine that is your data storage, your interaction with other people, and your data manipulation center, all in the same place
3 replies →
> your fediverse node on a static site, à la blog feeds powered by RSS/Atom.
I'm aiming for such called #Seppo! There's a proof of concept https://demo.mro.name/shaarligo and funding application paper in german for now https://mro.name/o/2022-03-08-201643-prototypefund12-037.pdf
Would you pay a doller per month for such?
Oh, I came across this long ago and forgot about it. Thanks for the reminder! Hope you will find funding via Prototype Fund too!
> Would you pay a doller per month for such?
For what? Hosting or development? I'd definitely pay $1 for development. :)
BTW, you say #Seppo, but the repo says ShaarliGo. Are you considering a name change?
> For what? Hosting or development?
development. Hosting will be strictly decentral under your responsibility.
> you say #Seppo,
indeed, the other is a proof of concept and will remain as is.
1 reply →
> 2. download https://mro.name/Linux-x86_64/shaarligo.cgi[...]
That doesn't sound like a static node to me, just another backend-heavy design.
Can I deploy this to GitHub Pages? NeoCities? Netlify (sans Functions)? If the answer is "no", then it really doesn't have anything to do with what I'm talking about.
If the target node can host static files it can serve as a mirror, if it can execute CGIs you can edit.
How do you tell 'backend-heavy'?
3 replies →
To allow people to review their followers before accepting them ("follow requests") all subscriptions in ActivityPub require the followed actor to send back an Accept activity. This, and the Webfinger requirement to confirm the username@domain address that predates ActivityPub, preclude plain static sites from being followable actors as seen from Mastodon. Although nothing prevents you from publishing a static feed in the ActivityStreams format, this would require a different, feed-like subscription mechanism where the publisher is not aware of subscribers and the subscriber has to poll the publisher periodically.
"Follow requests" are typically used for sharing private posts in existing social networks: that's why there is a "request and accept" flow. They seem like they should be irrelevant to users who only post content publicly. Does Mastodon require users with public posts to "approve" each of their subscribers?
Not in the UI unless the user's enabled it, but ActivityPub server implementations send an Accept activity in response to a Follow activity.
1 reply →
Yes. These are all assumptions of the sort that I'm saying would need to be (and should be) adjusted (i.e. fixed)—in Mastodon and ActivityPub, to better accommodate static nodes (not for the relevant desiderata to be adjusted to accommodate what's currently wrong with the design that Mastodon implements).
> I'd like to see more attention put into carving out a subset of Mastodon's functionality that would allow you to host your fediverse node on a static site, à la blog feeds powered by RSS/Atom.
You could just serve standard ActivityStreams; this can happen statically and is not something that Mastodon itself needs to be concerned with, obviously. A different component (either Mastodon itself or some separate thing) would poll known ActivityStreams endpoints and either expose them directly in Mastodon or relay their content via ActivityPub in a way that a Mastodon instance can support.
this is infeasible until https://github.com/mastodon/mastodon/issues/34 is addressed. Mastodon does not backfill posts or "poll" streams. they need to be pushed.
I'm pretty sure there are tools that allow people to subscribe to an activitypub feed of your private blog similar to RSS, it's been a while since I dived into the world of activitypub community projects and tools but I am certain I saw something like that somewhere.
> there are tools that allow people to subscribe to an activitypub feed of your private blog
Those aren't relevant here. You're saying, essentially, "static sites/blogs, squeezed through a Mastodon-/ActivityPub-shaped hole". I'm saying, "Mastodon profiles, squeezed through the static site/blog hole (in a typical staticgen pipeline)". They have some words in common, but the resemblance ends there, at the superficial level; they are otherwise completely opposite ideas.
> I am certain I saw something like that
Assuming that "that" means the thing that I'm describing: you wouldn't have seen that, because the relevant Mastodon-interoperable parts of ActivityPub as they currently exist are fundamentally at odds with the ability to do this, for reasons mentioned in part by Gargron upthread.
The WebFinger thing is a big part of it. Mastodon's not alone here; there are other WebFinger-dependent protocols (like remoteStorage) that also suffer. This is covered in <https://github.com/konklone/jekyll-webfinger/tree/9bcb46bbab...>. (Mastodon has taken off in a way that we could probably say it has reached critical mass, even if it's still not as mainstream as Twitter, but remoteStorage not so much.) This is a design flaw at the protocol level, and my contention is that it impacts further adoption more than people realize. There's no good reason, for example, why when I encounter a remoteStorage-compatible app where I only ever intend to grant it read-only access, I shouldn't be able to give it the URL for a dataset hosted on a static site. Presently, however, you cannot—unless the application author deliberately implements some workaround. But they shouldn't need to.
It is indeed a thing.
https://news.ycombinator.com/item?id=21470099
Have you seen twtxt or yarn.social? It's a text-format feed you can absolutely statically host.
I don't want another Twitter-but-reinvented. I want a Mastodon-interoperable "profile" to be enshrined in a standard that projects currently focused on compatible ActivityPub-based client/server implementations agree to support because it's a good compromise that allows people to participate with nothing more than the ability to publish a static site.
ActivityPub is so poorly/vaguely specified that basically every real world implementation follows what Mastodon does, so good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone.
2 replies →
ActivityPub is supposed to be a generic feed format but in practice it's used mostly for Twitter clones so none of its non-Twitter vocabulary or flows have ever been developed.
do you think what you're envisioning can be bootstrapped through github actions?
4 replies →
Writefreely[1] supports ActivityPub, and are already planning to look at some of the ideas you have.
[1]: https://writefreely.org/
WriteFreely is no more relevant to static sites than Mastodon is. They're both "backend-heavy" servers—not tools for creating the sort of content that can be hosted on GitHub Pages or Neocities or Netlify (sans Functions) or a simple host that serves content from the file system using Caddy/Nginx/Apache/etc.
Who does run the server where the feed of replies to my post lives?
Same as who operates hosted feed aggregators and podcast indexers for you to use: whoever wants to.