I would have guessed that it means something like "you know how you need to get postgres, redis, and elasticsearch up for a good mastodon install? none of those"
Probably, but these are external dependencies. Whether they are python dependencies or not wouldn't change that.
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 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).
I assume the author means "no [system-level] external dependencies except Python 3.10+ [in order to install the software]". Python then installs the required application-level dependencies.
Python 3.10 is standard even in the latest debian version, nearly every Linux that you would setup today has python >=3.9 preinstalled. Unless you use some sort of "webspace" type of provider that only allows PHP, this should not be an issue (in fact I had a webspace once and it too had python, I just had to ask).
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.
Application-wise this looks awesome. I would love to see way more people using something like this.
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.
In theory this is already the case; Self-hosting only really requires understanding DNS and the basics of running a Unix system if you just rent a VPS at say, Hetzner. Similarly, buying domain names is as easy as buying a phone number, probably even easier since ID legislation surrounding phone numbers is much stricter.
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.
I remember a brief period in the early heyday of the LAMP stack where the A meant "Apache" and nothing else it felt like "Just Install Apache" was all you needed to self-host random PHP applications you would find.
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.)
This looks great. Mastodon is not a good choice for a "single-user instance". It has been a pain and a waste of resources, running it for the last few years. If the migration process is easy (and keeps all the previous data), I will definitely consider the move.
I saw that mastodon.technology is shutting down soon. Would this microblog.pub be a good alternative to hosting my own mastodon? I don't have any other users, so it'd just be for me to maybe interact with people on other mastodon instances.
I am a ~single-user Mastodon instance admin. It is a big hassle to get set up, but then I never have to really think about it day-to-day.
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? :)
It probably depends on how it is packaged. I easily deployed it on yunohost, and the updates are done with a few clicks. I do hardly anything to keep it maintained on a RPI. If I start bringing on more people, I might have to actually moderate.
It's not nonsensical. It's not doable, though, either—owing to fundamental assumptions/flaws in the protocol (where "protocol" here refers to the Mastodon-compatible implementations that are in actual [read: majority] use today).
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.
If you want even lower resource usage, try honk[1] (currently using about 80M whilst my Pleroma is using 350M + 500M from Postgres) (although it is considerably more minimal than Pleroma...)
I love software like that, thanks for sharing. I do worry about seems like a single-user contributor project, though. Pleroma and Mastodon have healthy amounts of contributors and activity, so I feel more comfortable about going with them.
Might be a good choice, but it is early days for microblog.pub. I recommend having a look at GoToSocial. Also relatively new, it is developing fast, and made to be easily self-hostable and for best suited small-scale instances.
I use Akkoma (https://akkoma.dev/AkkomaGang/akkoma/) for a single user instance, which is a fork of Pleroma, which is a lot easier to install and maintain. Mastodon was incredibly painful to upkeep.
I can't speak for microblog.pub because I don't use it but it seems to fit the bill. I personally use pleroma, only for myself, and have literally no maintenance besides upgrading the package (and upgrading is a one click operation with yunohost)
There's definitely some weirdness with the @t@hexa.ninja account given as an example of an instance in the wild.
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 does not handle old posts. This post number is the number of posts since at least one person on that instance followed them. Before that, the instance didn't know they existed
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.
> does not handle old posts. This post number is the number of posts since at least one person on that instance followed them.
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.)
Why not just use WordPress? If you're technical, self host using wordpress.org. If you're not, or don't want the hassle, host using wordpress.com. If you do need the ActivityPub side of stuff you can install a plugin [0].
Surprising how many people are misreading the comment/question. Responses range from people answering the question, "What is ActivityPub?", to "What is Mastodon?"
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.
I kind of get lost with the ActivityPub/Fediverse story. When I subscribe to a blog's RSS feed, it's a decentralised and anonymous way of "following" the blog.
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?).
ActivityPub is a common language that allows describing "actors", "activities" and "objects" -- and as such, can describe any kind of social platform, from blog, to forum, to social media site, be it for photo sharing, video sharing, or something -- in your words -- Twitter-like. Not everything that uses ActivityPub will be 100% identical in user-facing functionality and UX, but most platforms have a concept of subscribing to other users, receiving new posts, and replying or re-sharing posts, which is where the interoperability comes to shine.
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).
That's an extremely short sighted opinion.
ActivityPub is an extremely versatile protocol that resembles a lot like speech.
Some guy made a bunch of "smart" devices communicate with eachother through his own GNU social instance. Essentially making his house a "smart" home.
It’s not very surprising. I was looking around for an easy way to set up anythi g using ActivityPub using a single docker instance, and all the big players are ‘check out from source and run directly on your server’. No thanks.
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.
I cannot relate to this way of thinking. That's about the entire city of Manchester. Do dozens of people live in Manchester? 500K is vastly more than any average person can ever hope to have as followers on Twitter; it's not a ceiling anyone debating joining Mastodon can reasonably run into unless they are a celebrity -- and those have the power to pull in anyone from anywhere.
Shameless plug: use HeyHomepage.com with it's Really Social Sites (RSS) functionality. As easy as Wordpress to setup. Already millions of feeds one can subscribe to. A goodlooking website with your own timeline, which you can also use to share (and therefor 'curate') other interesting RSS posts.
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...