d7e2a5c6e7
While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional. |
||
|---|---|---|
| .circleci | ||
| .devcontainer | ||
| .github | ||
| app | ||
| bin | ||
| chart | ||
| config | ||
| db | ||
| dist | ||
| lib | ||
| log | ||
| public | ||
| spec | ||
| streaming | ||
| vendor | ||
| .browserslistrc | ||
| .buildpacks | ||
| .codeclimate.yml | ||
| .deepsource.toml | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.production.sample | ||
| .env.test | ||
| .env.vagrant | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .foreman | ||
| .gitattributes | ||
| .gitignore | ||
| .haml-lint.yml | ||
| .nanoignore | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .profile | ||
| .rspec | ||
| .rubocop.yml | ||
| .ruby-gemset | ||
| .ruby-version | ||
| .slugignore | ||
| .yarnclean | ||
| AUTHORS.md | ||
| Aptfile | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Capfile | ||
| Dockerfile | ||
| FEDERATION.md | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| Procfile | ||
| Procfile.dev | ||
| README.md | ||
| Rakefile | ||
| SECURITY.md | ||
| Vagrantfile | ||
| app.json | ||
| babel.config.js | ||
| config.ru | ||
| crowdin.yml | ||
| docker-compose.yml | ||
| ide-helper.js | ||
| jest.config.js | ||
| jsconfig.json | ||
| package.json | ||
| postcss.config.js | ||
| priv-config | ||
| scalingo.json | ||
| stylelint.config.js | ||
| yarn.lock | ||
README.md
Hometown: a Mastodon fork
Photo by Joana Mujollari, CC0 / Public Domain.
Mastodon is a free, open-source social network server based on ActivityPub. This is not the official version of Mastodon; this is a separate version (i.e. a fork) maintained by Darius Kazemi. For more information on Mastodon, you can see the official website and the upstream repo.
Hometown is a light weight fork of Mastodon. By "light weight" I don't mean more efficient; I mean this fork is 99.999% identical to Mastodon with a few key tweaks. This project is based on the principle of: minimum code change for maximum user experience change. This makes it easy for the basically-one-person who runs the project to keep it up to date. By our best understanding, our major changes are not wanted by the Mastodon project, hence maintaining this fork instead of trying to commit the changes to Mastodon.
Please check out our wiki for a list of Hometown-exclusive features. Some but not all of these are covered in this document.
You can also find a list of running Hometown instances, don't hesitate to open an issue to add yours!
Support this project
Please consider supporting Hometown by pledging to my Patreon, which supports all my open source projects including this one!
Of course this project couldn't exist without Mastodon so maybe support the Mastodon project Patreon too.
Migrating from Mastodon to Hometown
Please see this article in the wiki for directions on migration from Mastodon to Hometown.
Local only posting
Mastodon right now is designed to get your messages out to the entire fediverse. This is great, but there is a huge need for more private communities. And in a federated network I think it makes the most sense for your home server to be that community (hence "Hometown").
In the context of Hometown, local only posting is a per-post security option that lets you set whether that post can federate out to other servers or not.
I've been running Friend Camp, a Mastodon fork with local only posting, for about a year. Being able to have conversations with people on your server that don't federate is a hugely liberating thing. It allows inside jokes to develop. It allows people the freedom to complain about things that they wouldn't necessarily feel comfortable leaving a trusted server (cops, employers, etc). It also lets us do things like have a server-wide movie night where we flood the local timeline with posts about the movie, and it doesn't pollute the rest of the Fediverse.
This feature is based on the work of Renato Lond, which is itself based on a feature in the Mastodon Glitch Edition fork.
Reading more content types
Mastodon is microblogging software, meant for Twitter-style shortform posting.
Hometown is microblogging for writing, but its goal is to accept many content types for reading. So while I don't plan to let Hometown users publish massive blog posts, I would like your Hometown instance to be your one-stop shop for viewing all sorts of things on the Fediverse.
For Hometown this means if you subscribe to a service that sends out Article objects over ActivityPub (such as a blog on Write As), then those full articles render in your home timeline, behind a cut for length. Also, Hometown will render a variety of rich text like italic and bold.
Click on this GIF for a brief video demo:
This is based on rich text work by Claire Girka, and my own work on Article support.
It's more than just reading more stuff
Reading more content types also helps make the fediverse better. ActivityPub supports all kinds of content, but most ActivityPub servers shoehorn all their content into Note because that's the type that Mastodon treats as first-class. This has important implications for the fediverse and also on your day to do user experience.
Take the "quote tweet" debate for example.
Twitter has a feature called "quote tweeting" that lets you embed what someone else tweets, with your own comment right next to it. It's really useful for provide commentary in context, like this, where I point people to a sale and they can read both my comment on the sale and the original tweet about the sale in one post:
Hometown doesn't support quoting articles yet... but it will.
Better list management
If Hometown is going to be a universal reader, you're going to need better control over organizing your feeds than mainline Mastodon provides.
I've introduced a new kind of exclusive list. In vanilla Mastodon, if you add an account to your "friends I like" list, posts from people on that list appear on that list. But they also appear on your home timeline, and maybe you don't want that! You'd rather treat your "friends I like" list as your "real" home timeline, and then check your home timeline when you're bored. Check out more details about exclusive lists on the wiki.
Better accessibility defaults
Look, right now this pretty much just means that we underline hyperlinks by default. I'm of course open to implementing other obviously beneficial accessibilty defaults that Mastodon itself doesn't implement.
Hometown is still 99.999% Mastodon
I don't intend to stray very far from mainline Mastodon with this fork. If you want something that provides a ton of new features and widgets and stuff, the Mastodon Glitch Edition fork is a wondrous kitchen sink of major and minor tweaks.
Part of why I don't want to stray far from mainline Mastodon is that this project is going to be just me for the foreseeable future, and I'd like to keep it up to date with new Mastodon versions as easily as possible. The less code I change from Mastodon, the easier that is. Hence the principle of "minimum code change for maximum user experience change."
Versioning
Hometown uses semantic versioning and follows a versioning convention like v1.0.0+2.9.3. The 1.0.0 part is the actual Hometown version number, and then the 2.9.3 after the + sign is what's known in semantic versioning as "build metadata". It just means that a particular release is synchronized with Mastodon version 2.9.3, so for example an upgrade from v1.0.0+2.9.2 to v1.0.0+2.9.3 would upgrade Mastodon but not provide any new Hometown features or fixes.
Contributing to Hometown
Setting up your Hometown development environment is exactly like setting up your Mastodon development environment. Pull requests should be made to the hometown-dev branch, which is our default branch in Github.
You can open issues for bugs you've found or features you think are missing. You can also submit pull requests to this repository or submit translations using Crowdin. To get started, take a look at CONTRIBUTING.md. If your contributions are accepted into Mastodon, you can request to be paid through our OpenCollective.
IRC channel: #mastodon on irc.libera.chat
License
Copyright (C) 2016-2022 Eugen Rochko & other Mastodon contributors (see AUTHORS.md)
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see https://www.gnu.org/licenses/.