Microblog.pub – A self-hosted, single-user, ActivityPub powered microblog
docs.microblog.pub
docs.microblog.pub
I don't know if it's the way it's been written, but it reads to me that only python is needed, no libraries.
I'm assuming this isn't true though: I can see a lot of libraries: https://github.com/tsileo/microblog.pub/blob/v2/pyproject.to...
If someone writes "no external dependencies except Python 3.10" I'd expect that thing to run out of the box on any system that has Python 3.10 on it. The developer promised after all that this was the only dependency.
When I realize that there are in fact a heap of external python modules you need to install, I loose a lot of trust in the proficiency of the project.
No external dependencies means that you just use the standard python interpreter and you maintain all the code you are using (outside of what the language provides). No external dependencies speaks of a willingness to go the extra mile to reduce size, make the thing universally runnable and easy to install and to avoid having random (potentially unchecked) code running inside your project. So it is a statement to make.
Most projects I work on have external dependencies, but I: A.) try to keep them to a minimum and only rely on vetted and tested ones and B.) I don't claim there are no external dependencies
I see the confusion, I tweaked the README to remove that claim. But I indeed meant "no external dependencies like postgres/redis..".
I personally value a lot not having to install stuff by hand on my system, hoping for the version of the said dependencies in my OS package manager end up working with the software I want to use. Using dependencies managed by the language dependency manager removes 99% of the dependency hassle.
(Yes, I know I could install an complete second distro in docker and run the software there. But I won't, thank you).
It is like talking about storage fragmentation: one layer's internal fragmentation is the next's external fragmentation.
So python 3.10 is not an external dependency here, because external implies you need to install it.
But all the non-standard python modules used (humanize, ...) are definitly external dependencies and that can be an issue if you try to run your service in such a restricted environment.
The problem is self-hosting is too difficult for the average person. But that doesn't have to be the case. Self-hosting shouldn't be any more complicated or less secure than installing an app on your phone. You shouldn't need to understand DNS, TLS, NAT, HTTP, TCP, UDP, etc, etc. Domain names shouldn't be any more difficult to buy or use than phone numbers. Apps should be sandboxed in KVM/WHPX/HVP-accelerated virtual machines that run on Windows, Mac, and Linux and are secure-by-default. Tunneling out to the public internet should be a quick OAuth flow that lets you connect a given app to a specific subdomain, with TLS certs automatically obtained from Let's Encrypt and stored locally for end-to-end encryption.
NAT, TCP and UDP don't come into play unless you also plan on self-hosting your IP assignments or need to configure the firewall, which most people don't need to do (firewalls for webservers are usually already set up by the distro from my experience.)
The problem is that the rest of the process is poorly documented (really... anything surrounding HTTPS; webservers require setting arcane config flags that all make sense once explained but why aren't distros just shipping sane SSL snippets that aim to get a good SSLLabs score/maintain older browser compat as needed, pretty much all these configs are shared across systems, certbot is cool but good luck parsing the documentation and woe be onto you if you do DNS-level verification with an unofficial plugin, the docs are all over the place) which creates this faux idea that you need to be a massive tech nerd to even begin self-hosting.
The closest thing most people can follow is setting up shop at a shared hosting provider with a one-click WordPress installation (or other apps fitting in an AMP stack). That has been automated to the point where the enduser can reliably do it, but that pushes the limit of what you can really consider self-hosting.
It feels like we have all the raw technologies to make it easier than ever, it's just all the "glue" that sucks (or doesn't exist).
- Home IPv6 is so much easier to work with than workarounds I recall doing with IPv4 as a kid. Static IPv6 is actually achievable and AAAA only DNS works in more places than not today.
- Let's Encrypt does make the TLS dance much simpler.
- Docker containers do give you cross-platform sort-of sandboxed virtual environments that can run just about any app you like in any programming language. No more L or P dependencies in the modern LAMP stack equivalent with tools like Docker around.
- SQLite has shifted into being a game changer in database serving. In the old classic LAMP stack installing and maintaining MySQL was three fourths of the "fun" (and just about 90% of the pain) and there's no great way to sandbox a MySQL server other than to spin up multiple servers (which is a bit much for a modest self-hoster), but every application could use its own SQLite DBs easy enough, the SQLite DBs can be embedded in and don't have to leave app containers, and that should scale "good enough" for self-hosters. (SQLite is also the choice of the linked application here.)
In terms of glue, I feel like there's a meta-narrative to explore of "single docker container apps designed to be self-hosted" and maybe a meta-"app server" with an easy to use interface to control them. I don't know what you'd call that pattern or how much interest there would be in this SaaS-heavy world.
Some other half-baked thoughts:
- fly.io's business model is SaaS for obvious reasons, but their tools look "close" to the above desirable "glue", minus the parts that are SaaS for business reasons. Vercel is a similar example of an off-the-shelf tool that might be handy for self-hosting if it wasn't so focused on supporting SaaS business models.
- The last time I did any serious self-hosting on a VPS I really liked Cherokee's [1] configuration approach: it makes sense for a web server to itself be configurable as a web app. Similar to how cPanel got so popular in early LAMP stack SaaS days (is it still popular?) simply because it offered an easy web app UI to manage an application stack. (Looks like Cherokee's documentation hasn't been updated in a few years, and at least from the documentation still doesn't even have Let's Encrypt (ACME) support out of the box, which seems a shame.)
if you have access to a LAMP like your typical shared hosting provider, you could try Gnu Social or WordPress with the AP plugin.
Thanks for the suggestion. I don't really want to run another Wordpress, but Gnu Social looks promising.
Yeah, fair, especially when it has an, uh, esoteric code style.
It wouldn't take much to fix it, though, and it should be fixed. TPTB really should have focused on enabling your use case from the beginning.
Moar discussion here:
Comments for "Mastodon 3.5" (6 months ago)
That said, there are also a lot of other good instances, and I am jealous of folks with a nice local timeline, so the general advice (for anyone else reading) would be to just move instances.
I don't know if this has an ergonomic read-posts-from-other-instances setup. If you try it, write up what you think somewhere? :)
Loading that in Mastodon's "Web" says it contains "4 posts", but consulting the "Posts and replies" tab will reveal the contents of 5 posts. Meanwhile, this number is about half of the expected number, based on the posts that are actually visible on the <https://hexa.ninja/> landing page (i.e. as viewed in e.g. Firefox).
ActivityPub is a publisher/subscriber protocol
That is incorrect. Mastodon is the one doesn't handle old posts[1], because they insist on presenting to the user only what has already been federated with it. See [2] for a more in-depth explanation.
If they would use the protocol as intended, and actually perform requests on the remote Outbox collection when the user wants to view the posts of a remote actor, there would be no issue.
[1] https://github.com/mastodon/mastodon/issues/14017
[2] https://github.com/mastodon/mastodon/issues/14017#issuecomme...
That's not an explanation for the behavior here.
The instance's very first Hello World post <https://hexa.ninja/o/4473c26694414f928466337c1a9e0fc6> appears, while more recent ones don't. There's probably no one actually following this account from this instance. (Hard to check.)
I think there are probably two main groups interested in ActivityPub. The 80% will want to just register on someone else's instance. The rest are nerds who will set up their instances for fun, and will not be massively hindered by the lack of simple set-up options. I would guess that users like you ('curious, but not invested') would likely not gravitate to ActivityPub anyway, and almost certainly not to hosting your own instance.
To the original commenter: yes. This project is using ActivityPub kind of like RSS. Since it's ActivityPub and not merely RSS, the experience when using e.g. Mastodon as your reader, however, is "like RSS, worse". On the other hand, since it's ActivityPub, it also supports all the ways to track followups/replies/threads both from the original poster and people who are not the original poster, a way to dynamically track/display who else is subscribed, and it advertises a channel for you to send notifications to if you yourself wanted to reply or follow. This is its main value proposition—mostly for people who prioritize the gimmick of modern-ish social features over simplicity and economical setup/hosting.
Now if the blog uses ActivityPub and federates with Mastodon instances, then it's not a blog anymore, right?
Or similarly, if Lemmy is supposed to be like Reddit, then it should not federate with Mastodon (everything that federates with Mastodon kind of becomes a Twitter alternative, doesn't it?).
Probably I haven't understood the idea yet.
If your blog uses ActivityPub, it is still a blog. People could just subscribe to it to receive your posts in their home feed, reply to them, or re-share them in a way your blog could process (or choose not to).