hometown-fork / hometown Goto Github PK

Expected behaviour

Post status (either publicly or privately, federated or local-only) from Hometown/Mastodon interface.

Actual behaviour

Internal server error pop up appears in interface. Sidekiq job for status posting fails leaving stack trace. Partial stack trace from systemd:

Jul 08 11:54:42 sad-earth-prime bundle[1718]: 2019-07-08T11:54:42.475Z 1718 TID-owormn9r6 WARN: {"context":"Job raised exception","job":{"class":"DistributionWorker","args":[102405676040986322],"retry":true,"queue":"default","jid":"
c1c8052ef30731286e6c48fe","created_at":1562586609.5981352,"enqueued_at":1562586882.3866012,"error_message":"undefined method `activity_pub_type' for #<Status:0x00007fd11ab53c48>","error_class":"NoMethodError","failed_at":1562586609.
810376,"retry_count":3,"retried_at":1562586725.5024107},"jobstr":"{\"class\":\"DistributionWorker\",\"args\":[102405676040986322],\"retry\":true,\"queue\":\"default\",\"jid\":\"c1c8052ef30731286e6c48fe\",\"created_at\":1562586609.59
81352,\"enqueued_at\":1562586882.3866012,\"error_message\":\"undefined method `activity_pub_type' for #<Status:0x00007fd11ab53c48>\",\"error_class\":\"NoMethodError\",\"failed_at\":1562586609.810376,\"retry_count\":3,\"retried_at\":
1562586725.5024107}"}                                                                                                                                          
Jul 08 11:54:42 sad-earth-prime bundle[1718]: 2019-07-08T11:54:42.475Z 1718 TID-owormn9r6 WARN: NoMethodError: undefined method `activity_pub_type' for #<Status:0x00007fd1165be480>
Jul 08 11:54:42 sad-earth-prime bundle[1718]: 2019-07-08T11:54:42.476Z 1718 TID-owormn9r6 WARN: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activemodel-5.2.3/lib/active_model/attribute_methods.rb:430:in `method_missing'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/serializers/rest/status_serializer.rb:65:in `activity_pub_type'                
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:387:in `read_attribute_for_serialization'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer/field.rb:25:in `value'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:340:in `block in attributes'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:337:in `each'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:337:in `each_with_object'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:337:in `attributes'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:400:in `attributes_hash'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model/serializer.rb:368:in `serializable_hash'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/adapter/attributes.rb:9:in `serializable_hash'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/adapter/base.rb:61:in `as_json'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/serializable_resource.rb:10:in `as_json'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:71:in `block (3 levels) in notify'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:109:in `block in run_callbacks'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:24:in `block (3 levels) in instrument_rendering'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:81:in `block in notify_render'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/notifications.rb:170:in `instrument'                                                             
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:80:in `notify_render'           
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:23:in `block (2 levels) in instrument_rendering'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:97:in `block in tag_logger'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/tagged_logging.rb:71:in `block in tagged'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/tagged_logging.rb:28:in `tagged'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/tagged_logging.rb:71:in `tagged'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:97:in `tag_logger'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:22:in `block in instrument_rendering'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:118:in `instance_exec'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:118:in `block in run_callbacks'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:136:in `run_callbacks'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/active_model_serializers-0.10.9/lib/active_model_serializers/logging.rb:70:in `block (2 levels) in notify'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/lib/inline_renderer.rb:23:in `render'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/lib/inline_renderer.rb:27:in `render'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/services/fan_out_on_write_service.rb:67:in `render_anonymous_payload'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/services/fan_out_on_write_service.rb:9:in `call'
Jul 08 11:54:42 sad-earth-prime bundle[1718]: /home/mastodon/live/app/workers/distribution_worker.rb:9:in `block in perform'
[... snip ...]

Expected behaviour

When I add a filter, such as for @twitter.com, to remove content from my Home timeline, I'd expect that such a toot also doesn't show up in an exclusive list.

Actual behaviour

The filter that's applied to the home timeline (and public timeline) doesn't work in an exclusive list.

Specifications

Hometown v1.0.5+3.2.0

Expected behaviour

A local-only post set to public remains local-only when pinned to the user's profile.

Actual behaviour

All public posts, local-only or federated, appear on a user's profile when pinned, even to logged-out viewers.

Steps to reproduce the problem

Posted a local-only public status. Pinned status to profile. Visited profile in private browser window, saw status.

See: lawremipsum#14

This feature by @divergentdave on MSP Social has been a popular and useful one. It allows all users to see, immediately, if an image has a description. It is a very lightweight quality-of-life customization that is popular with our users with and without sight impairments.

This promotes image description use on the server, makes users conscious of the feature, and allows them to easily do things like decide whether or not to engage with posts that don't have image descriptions.

(One way the implementation could be improved from what's currently running on MSP Social would be to make the description pop up when the icon is clicked, right now on hover it just displays a notice that there is a description.)

I'm posting this as a feature request simply because I don't have the git skills to offer it as a PR. If someone wants to walk me through how to make a patch to offer as a PR I'm happy to do that.

For instances utilizing managed hosting services, this would really help.

Not a huge deal as the only information sent out is "user deleted post of ID xyz at time abc" but needs squashing for next release.

On certain mobile devices, Mastodon adds a share button on public statuses. However, as i understand, local-only toots are not really “public” and so should probably not have a share button attached.

For detailed statuses, the line controlling this is here (L178):

https://github.com/hometown-fork/hometown/blob/master/app/javascript/mastodon/features/status/components/action_bar.js#L178

And for ordinary (timeline) statuses, the line is here (L246):

https://github.com/hometown-fork/hometown/blob/master/app/javascript/mastodon/components/status_action_bar.js#L246

This is an option that is currently available in the home timeline, but not in user-created lists.

I think this would grant additional versatility to user created lists, in addition to the exclusive lists. Sometimes you just want to see what your friends themselves are saying, and not what they are boosting!

Upstream mastodon underlines links only on hover, including hashtags and mentions. When it does this, it only underlines the contents of the hashtag or mention (not including the #/@ prefix).

Hometown underlines links always. However, when it does this, it underlines the entirety of the hashtag or mention (including the #/@ prefix).

This produces inconsistent underlines, which may or may not include the prefix depending on whether or not the link is currently being hovered.

The relevant lines are here: https://github.com/hometown-fork/hometown/blob/hometown-dev/app/javascript/styles/mastodon/components.scss#L803-L811

For consistency, the text-decoration: none should be moved outside of the :hover (so that it always applies, and only the inner <span> is underlined), or it should be deleted (so that the whole thing is underlined always).

(Note the .mention class is used for both mentions and hashtags presently.)

Pitch

TL;DR: glitch's threaded mode

This would add a UI element to the compose UI that would enable "threaded mode". When a post is posted, the compose UI is immediately setup to reply to that post.

(This is similar to Twitter's thread creation, except this proposal does not hold the posts until the thread is complete as Twitter does.)

Motivation

I most notice the lack of this feature when I'm scrolled down in my timeline (and want to retain that position) and want to send a sequence of posts. After I send the first one, I am left with the choice of either hitting Home (and losing my position), or opening up my profile (or timeline) in a separate tab and continuing my thread from there. This is clunky.

The two scenarios where I most run into this: I've just boosted something and want to share my (lengthy, apparently) thoughts on it before resuming my scrolling, or I'm scrolling my timeline while watching something that I want to comment on (whilst keeping all of my posts about DS9 S5E27 or whatever in a single thread).

Pitch

glitch-soc provides a checkbox in settings to warn a user before they post an image with no caption:

Hometown should implement this feature.

Motivation

This opt-in feature encourages users to remember to caption their images. Popular Mastodon client apps, like Toot, support this feature as well.

Mastodon just released new versions for the 2.9.x, 3.0.x, and 3.1.x lines that include security fixes.

Since the latest Hometown version is based on 3.0.1, it makes sense to at least merge the 3.0.2 changes that contain the security fix: https://github.com/tootsuite/mastodon/releases/tag/v3.0.2

Pitch

Change exclusive list behavior so that it ignores the mute settings for accounts in the list. More complicated solutions would be: a per-list setting that ignores/enforces mutes of all its accounts, a per-account, per-list setting that ignores/enforces mutes of each account.

Motivation

Our hometown instance has a bot account that posts often, and I added it to an exclusive list, so that I could see its posts in a column on the web UI. Unfortunately, when I followed it, all of its previous posts were added to my home timeline. Muting the account prevented me from seeing its new posts in the exclusive lists. In the end, the instance admin cleared out all previous posts, so home timelines aren't cluttered.

This appears to be an issue with the Mastodon base code, but since I am experiencing it on Hometown on https://skull.boutique (screenshot from Hometown attached here) I figured I would post here also. See Mastodon issue: mastodon#14916

I followed the instructions here to get my install going:

https://computingforgeeks.com/install-mastodon-on-ubuntu-with-letsencrypt-ssl-certificate/

So, rubyenv is in play here, if that matters.

Trying to update to the most recent version, this is the output I get:

mastodon@mastodon-01:~/hometown$ bundle install
/home/mastodon/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/rubygems_integration.rb:200: warning: constant Gem::ConfigMap is deprecated
Fetching gem metadata from https://rubygems.org/............
NOTE: Gem::Specification#has_rdoc= is deprecated with no replacement. It will be removed on or after 2018-12-01.
Gem::Specification#has_rdoc= called from /home/mastodon/hometown/vendor/bundle/ruby/2.6.0/bundler/gems/nilsimsa-fd184883048b/nilsimsa.gemspec:10.
Could not find sidekiq-unique-jobs-6.0.18 in any of the sources

Googling has availed me nothing and I'm not a Ruby on Rails dev, so I don't know what's going on here. I have tried deleting the Gemfile.lock, which seems to be common advice for this broad category of issue, but I get this complaint when I try to be a wiseass:

The deployment setting requires a Gemfile.lock. Please make sure you have checked your Gemfile.lock into version control before deploying.

I have no idea how to proceed from here.

Hello,

I tried to find search around for some answers on this but it seems I might be missing something. When I run git merge v1.0.1+2.9.3 an error is returned. It looks like git fetch --tags is pulling the tags from mastodon not hometown. Is this correct? Any guidance is appreciated!

Thanks.

Pasting terminal commands and responses below:

mastodon@localhost:~/live$ git status
On branch hometown-v1.0.1+2.9.3
nothing to commit, working tree clean

mastodon@localhost:~/live$ git fetch --tags

mastodon@localhost:~/live$ git merge v1.0.1+2.9.3
merge: v1.0.1+2.9.3 - not something we can merge

mastodon@localhost:~/live$ git describe --tags
v2.9.3

mastodon@localhost:~/live$ git remote
hometown
origin

Expected behaviour

Migrate from my own mastodon instance.

Actual behaviour

Showing the error message «fatal: Not a git repository (or any of the parent directories): .git»

Steps to reproduce the problem

Execute a command from the «initial migration» page.

Specifications

Commit: Master

Pitch

I'll be moving my instance from a lonesome, dedicated VPS to one that hosts a bunch of stuff via docker soon. The lack of docs for getting started with a docker-based setup in the past motivated me to just throw money at the problem and spin up a brand new VPS entirely for the Hometown instance.

The Mastodon docs themselves offer a detailed guide to installing and setting up a Mastodon instance. As the upstream devs say, a bare-machine install does offer a lower barrier to setup (for them and for the users). I followed the Mastodon docs and set Hometown up the last time around.

Motivation

My argument is that docker itself can offer an even lower barrier when documented properly. I'll be outlining steps I take with my migration of sorts, but in the meantime I'm opening this issue/feature request as a placeholder for others using Hometown's compose file to run instances to pitch in with:

• an introduction/overview of the setup,
• a step-by-step guide for first-time setup,
• any tips and gotchas to make note of while setting things up, and,
• any limitations or pain points to be aware of when opting for the docker-based setup over a system-level install.

Hi,

additional to local only toots it would be awesome to have group visibility (for local only toots?) to build different independent groups on a local hometown instance?

Regards

Implement new feature, tentatively called an "exclusive list", which is a list where posts from any account you add to it no longer show up in your home timeline.

Mastodon v3.2.0 has been out for a couple weeks now and contains several useful changes and a ton of fixes.

Portrait Photos should upload as they appear in the iPhone gallery. I believe this info is in the exif.

vertical images are rotating -90 degrees. Different angle than in my phone

Hometown 3.1.4
Ruby 2.6.6p146
PostgreSQL 9.6.16
Redis 5.0.7

Brave 1.17 for iOS
iOS 13.5
6s plus

Hi there! If this is not an accurate description of expected behavior, please feel free to close this issue. Alternatively, it might be worth a documentation update, as I believe this behavior might be unspecified. I may have also just missed this detail.

Expected behaviour

1. A Hometown user's boost of a local-only post from their home instance should not appear in the boosting user's outbox.

A similar expectation, to help determine if this is indeed expected behavior:

2. A Hometown user's boost of a local-only post from their home instance should not appear in the home timeline of a user on another server who follows the boosting user.

Actual behaviour

A Hometown user's boost of a local-only post from their home instance does appear in the boosting user's outbox.

I haven't been able to verify if expectation 2 listed above is actually occurring.

Steps to reproduce the problem

1. Hometown User A posts something with local-only privacy
2. Hometown User B (on the same server) boosts the local-only post
3. A request for Hometown User B's ActivityPub outbox (i.e. https://hometown.server/users/userB/outbox?page=true includes the local-only post

Specifications

I saw this behavior on Friend Camp, which I believe is running the latest version or maybe edge?

Happy to provide the specific example I saw more privately if the steps to reproduce aren't working; I just don't want to share someone's less-than-public post here.

Thanks!

Sorry for the minor aesthetic quibbles, but I figure I might as well bring them up :P.

Right now the Local-Only indicator appears right next to the dropdown, not spaced like the other things in the status bar:

The reason for this is because the dropdown button is not a .status__action-bar-button (which has a right margin), but rather a .status__action-bar-dropdown (which does not). The code for styling that is here:

https://github.com/hometown-fork/hometown/blob/hometown-dev/app/javascript/styles/mastodon/components.scss#L1107-L1110

If you add margin-right: 18px to that ruleset, you can get equal spacing (see the rules for .status__action-bar-button on the immediately preceding lines):

Alternatively, you can use margin-right: auto to right-justify the Local-Only icon:

(This is easier to miss on wide screens, but has the advantage of not looking like an actionable button.)

I think either of these approaches would be much clearer than the current one.

I recently noticed that Hometown fork wraps the “Show More” button on toots with CWs (spoilers) in a <div>: https://github.com/hometown-fork/hometown/blob/hometown-dev/app/javascript/mastodon/components/status_content.js#L226.

This makes the “Show More” button always appear on the line following the spoiler content, instead of inline with it.

I actually like this behaviour, but there is a problem: Nesting a <div> inside of a <p> tag is non­‑conforming HTML. <span style={{ display: "block" }}> should be used instead.

(For reference, upstreamʼs equivalent code is here: https://github.com/tootsuite/mastodon/blob/master/app/javascript/mastodon/components/status_content.js#L221.)

One of the locked dependencies has been yanked and needs to be updated (mastodon#13292)

As a hometown admin, it should be possible to set it so that by default new users default to local only posting.

Pitch

This enables admins to create more inwardly facing hometown instances, and seems in line with the core values of the Hometown fork.

Motivation

I think that for instances that really emphasize local posting this would be a huge win. This feature was originally suggested here: https://weirder.earth/@bound/105725986691505694

Hi,

Mastodon v3.2.1 has been out for some time already, @dariusk would you consider releasing Hometown v1.0.6+3.2.1?
This minor release bring a lot of fixes that are needed by many users.

Thanks in advance

Hi,

Mastodon v3.1.5 is out now, with three different security fixes:

• mastodon#14254
• mastodon#14253
• mastodon#14252

Let's prepare a pull request to merge this into Hometown's code and make a new release ASAP.

Expected behaviour

An exclusive list should stay exclusive in the event it is renamed.

Actual behaviour

I had changed a list name earlier today. This was already marked as an exclusive list. Later (that is, now), I saw that toots from a user account showed up on my Home timeline. It looks like after the rename action, it became a non-exclusive list i.e. toots would appear both in the Home TL as well as the list TL.

Steps to reproduce the problem

1. Create a list
2. Mark it as exclusive
3. Add someone (optionally?)
4. Change the title of the list and hit the checkmark for saving the changes
5. The flag for exclusive list stays on
6. Close the list dialog box
7. Go to Home
8. Open the list and click preferences -> edit for this list
9. The exclusive list toggle is off, and toots leak into the Home timeline

Specifications

• Hometown v1.0.5+3.2.0
• Firefox v85.0.1 on Pop!_OS 20.04 LTS

Tried poking around but not much luck, unfortunately. Would love to see what solution anyone interested in tackling this comes up with.

The reply count on local-only posts is not functioning

I should see the number of replies on every post so I can know to click on the post and view replies

I only see reply count on federated posts.. Local-only posts remain at 0 replies, even with long threads

Photo shows 0 replies

In fact, there are many..

Hometown3.1.4
Ruby2.6.6p146
PostgreSQL9.6.16
Redis5.0.7

In my preferences "Allow my posts to reach other instances by default" (default federation) is not enabled:

Expected behaviour

When I make a post from a third-party client like Tusky (which doesn't allow specifying whether a post should federate) that is not in reply to another post and the above "default federation" setting is disabled, the status should not federate.

Actual behaviour

Status posted from Tusky that are not in reply to another post will always federate.

I'm not super familiar with Ruby but if I had to chance a guess I'd say nil is returned and the rest of this method is never reached (and thus the default federation setting is never checked) when a client doesn't specify local_only and the post isn't in reply to anything.

Note that this is a distinct issue from #23; the latter concerns a path for third-party clients to better support local-only posting, whereas this issue is about sensible default behaviours for third-party clients in the absence of that support.

Specifications

Hometown v1.0.3

Service 'web' failed to build: The command 'bash -c cd /opt/mastodon && bundle config set deployment 'true' && bundle config set without 'development test' && bundle install -j$(nproc) && yarn install --pure-lockfile' returned a non-zero code: 16

modified the Dockerfile to break apart these commands, the command causing problems is

The command 'bash -c bundle install -j$(nproc)

with this error

Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break this application for all non-root
users on this machine.
Could not locate Gemfile

I believe this is to do with installing the gem bundle? Not that familiar with ruby.

fails on release 1.0.5 (latest stable release as of this comment) and on Ubuntu server 20.04, if that helps.

Edit: changed this comment due to errors in my initial write up.

Article type posts should be able to be quoted a la "quote tweets" from Twitter. Since Article is intended for long form publications I think it makes sense to give people this contextual kind of way to comment.

We recently migrated weirder.earth to Hometown, and would love to be included in the list of instances running Hometown on the wiki.

While following the v1.0.3 release instructions on git fetch && git checkout v1.0.3+3.0.1 the following occurs:

error: pathspec 'v1.0.3+3.0.1' did not match any file(s) known to git.

That happens when people have multiple remotes (as would be the case when having migrated from vanilla masto as per the instructions on the wiki).

The solution is to update the remotes first:
git remote update

The command given is

pg_dump -Fc -U postgres postgres > name_of_the_backup.dump

but this actually backs up only the "postgres" database (which I think is the default DB; it only produces a 1.8 kilobyte dump file). My Mastodon database is called "mastodon_production" so

pg_dump -Fc -U postgres mastodon_production > name_of_the_backup.dump

is what I want (and produces a 55MB dump, which seems more apropos).

(Maybe I did something unusual during my installation, in which case I apologise for the noise!)

Local-only posting is not well supported on mobile apps.

The problem is that the local-only posting has no way of "advertising" that it exists as a feature. Or if it does, it's not really documented! This bug will track my ongoing work on this issue.

Hello hometown-fork
I am trying to add hometown features to my mastodon but not sure this is happening.

Hi,

The Hometown remote mentioned in the initial migration wiki page doesn't exist, it needs to be replaced by this one: hometown-fork/hometown.

Actually it links to hometown-fork/mastodon, which doesn't exist.

Thanks,

Summary
I'd like my hometown servers (including mine rage.love) to let me know what instances are blocked programmatically.

Rationale
I'm currently looking at ways to automate part of the instance moderation I do routinely.
So checking instances to see if they blocked already or to compare against a #fediblock post.
Without such endpoint, it is really hard to do because one needs to scrape the data from the about/more page.

Background/History of the feature
When I asked around I've been pointed at two PRs [1] [2] from tootsuite.
I've also had some code provided to me on how to implement it, see bellow.

Implementation
This code implementing this function has already been done and the author is ok to have it used elsewhere, like in hometown.
This commit will add domain allows and blocks to /nodeinfo/2.0.json and /api/v1/instance if the "show blocks to" option in your Site Settings isn't set to "To no one".
This commit adds API endpoints for /api/v1/admin/domain_allows and /api/v1/admin/domain_blocks, along with the respective OAuth2 scopes admin:read:domain_allows and admin:read:domain_blocks.

Pitch

You should create an official site with a list of available hometown instances (or at least indicate it in your github page).

Motivation

It would be more practical than browsing countless pages in search engines to maybe find an instance among results.

Expected behaviour

The feed regen task bin/tootctl feeds build --all should complete successfully

Actual behaviour

The task bin/tootctl feeds build --all crashes with the following stack trace:

Traceback (most recent call last):
	32: from bin/tootctl:5:in `<main>'
	31: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
	30: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	29: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	28: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	27: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor.rb:238:in `block in subcommand'
	26: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:115:in `invoke'
	25: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	24: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	23: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	22: from /home/mastodon/live/lib/mastodon/feeds_cli.rb:39:in `build'
	21: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/batches.rb:135:in `find_in_batches'
	20: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/batches.rb:222:in `in_batches'
	19: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/batches.rb:222:in `loop'
	18: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/batches.rb:238:in `block in in_batches'
	17: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
	16: from /home/mastodon/live/lib/mastodon/feeds_cli.rb:44:in `block in build'
	15: from /home/mastodon/live/lib/mastodon/feeds_cli.rb:44:in `each'
	14: from /home/mastodon/live/lib/mastodon/feeds_cli.rb:45:in `block (2 levels) in build'
	13: from /home/mastodon/live/app/workers/regeneration_worker.rb:10:in `perform'
	12: from /home/mastodon/live/app/services/precompute_feed_service.rb:5:in `call'
	11: from /home/mastodon/live/app/lib/feed_manager.rb:129:in `populate_feed'
	10: from /home/mastodon/live/app/lib/feed_manager.rb:129:in `loop'
	 9: from /home/mastodon/live/app/lib/feed_manager.rb:135:in `block in populate_feed'
	 8: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/delegation.rb:71:in `each'
	 7: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/delegation.rb:71:in `each'
	 6: from /home/mastodon/live/app/lib/feed_manager.rb:136:in `block (2 levels) in populate_feed'
	 5: from /home/mastodon/live/app/lib/feed_manager.rb:164:in `filter_from_home?'
	 4: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/core.rb:167:in `find'
	 3: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/querying.rb:5:in `find'
	 2: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/finder_methods.rb:69:in `find'
	 1: from /home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/finder_methods.rb:435:in `find_with_ids'
/home/mastodon/live/vendor/bundle/ruby/2.6.0/gems/activerecord-5.2.3/lib/active_record/relation/finder_methods.rb:447:in `find_one': You are passing an instance of ActiveRecord::Base to `find`. Please pass the id of the object by calling `.id`. (ArgumentError)

Steps to reproduce the problem

From the project root, run bin/tootctl feeds build --all.

Specifications

This was found in v1.0.1+2.9.3, running on Ubuntu 16.04.6 LTS

I've got a fix for this that I'm going to post shortly

Pitch

This is the obvious question: Have you considered to upstreaming your changes to Mastodon?

Have you already tried it? What is the status?

Motivation

I'm curious why a fork is needed. README is lacking this information. Please add it :)

When users receive their initial email confirmation or notifications, the sender name is displayed as ‘Mastodon’.. this has been a big point of confusion for my users. We should utilize the server name and use that as the sender name for emails.

Especially for those of us using managed hosting, this simple personalization is very helpful.

Pitch

Original pitch from @[email protected]:

I've been wishing for friends groups like what LiveJournal had - you create a group and you can set a post's privacy to that group only. Since Masto has a lists feature already, is that something that can be utilized into a post privacy setting?

Motivation

Fine-grained control over who gets to see your posts.

Considerations

• big UI/UX undertaking
• additional complexity added to the Compose Post interface that already has lots of security toggles
• privacy/security: need to deliver these messages to users in as private a way as possible, probably making sure to hit individual inboxes rather than global inboxes on other servers. Should be handled more or less like a locked post in terms of transit and delivery.
• figure out the activitypub semantics for doing this, make sure that it's going to be different from whatever Mastodon uses for group DMs or any upcoming "groups" like feature

I want people to be able to try out Hometown and not worry about what happens if they don't like it or if something happens to the project. This means providing comprehensive documentation and also some kind of DB migration for moving from Hometown back to Mastodon.

The main problem with this is figuring out what happens to any local-only messages that have been posted on Hometown when the migration happens. I think that the initial version of this migration will simply delete all the local-only messages. This is the most secure and foolproof option, though it only truly addresses the case of an instance that migrates and decides after a short period that they want to go back to regular Mastodon.

For an instance that has been running Hometown for, say, years but wants to go back to Mastodon, I'll need to provide something more robust. Thoughts include:

• instance wide notification system and an ability for individuals to back up their local posts
• somehow converting all local only posts to DMs, so that at least the authors and anyone mentioned will be able to see them if they go to the canonical URI for the post

I should add a page to the wiki about the general workflow and tips for updating Hometown to the latest Mastodon version. That way people who aren't me (like @mthld) can try their hand at releases.

see #552

The step git pull hometown hometown-v1.0.1+2.9.2 fails because it points to a branch that doesn't currently exist. Going by the existing branches in this repo it should be git pull hometown hometown-v1.0.0+2.9.3.