Follow

I'm pleased to announce the v1.0.0 release of Hometown, my Mastodon fork! It's up to date with Mastodon v2.9.3, and unique features include:

- Local only posting
- Full support for rendering incoming `Article` posts from federated blogs like Write.As
- "Exclusive" lists that let you follow someone without clogging up your home timeline

For more info, including rationale for each new feature, check out our wiki:

github.com/hometown-fork/homet

And the release itself is here:

github.com/hometown-fork/homet

@darius Does it support greylisted federation, or is it in the works?

@darius Instances aren't federated by default, but when they try to interact a request is sent to the mods to approve or reject

Think of it like locking your account, but it's your instance

@socalledunitedstates I'm not sure how well that works for moderators. I'm planning to implement a "neighborhood" concept, where you can whitelist other hometown servers (it has to be mutual) and then make "neighborhood" posts that are shared among the mutual network.

@darius @socalledunitedstates I am curious what you mean by "not sure how well that works for moderators?" because the greylisting thing does sound nifty to me

@hope @socalledunitedstates moderators would need to approve every incoming federation request, and approval (imo) would involve a system of vetting whether an instance has a CoC, whether it's a real CoC, whether it's something your users want to federate with, etc. It's a ton of work to do responsibly. Of course it would be easy and not a lot of work to do irresponsibly!

@hope @socalledunitedstates basically with a user I can look at their timeline and tell pretty quickly if they really suck but it's hard to do for an instance

@darius @socalledunitedstates obviously if an instance is turning on this option they are choosing this work for themselves. And its way more manageable than trying to sort through every instance on fedi and do this in the current system.

@hope @socalledunitedstates I think my neighborhoods concept plus full whitelisting for "outside" instances is both safer and easier to manage but I will give this serious thought

@darius @hope But it'd replace the work of hearing about, researching, and blocking instances as they pop up. Blocking instances takes time whether or not the instance would ever have tried to interact, whereas greylisting only takes time if they do. And there's the obvious upside that greylisting wouldn't ever let harassment get through if done right, whereas blocking is only reactive

It'd probably depend on the size of the instance. For smaller instances it'd be a great option, since they won't get too many federation requests at once either from good or bad instances

@socalledunitedstates @hope I'm more of a fan of whitelisting, personally. so I get what you're saying re: safety.

@darius @socalledunitedstates I think essentially this ends up being a whitelisting tool where the list of instances to consider whitelisting is generated organically by your users/and their contacts outside your instance.

@hope @socalledunitedstates it's the second part that bothers me and I think could be overwhelming

@darius @hope Greylisting is just automating part of the whitelist process, rather than making people send you an email or something if they want to federate, or getting tons of requests from your users through DM

I know some instances have already put this in place, but I don't happen to know which. If I can find out, I'll let you know so you can talk to them about it

@socalledunitedstates @hope I don't love the idea of allowing outside instances who my users might not even know about to ask to be federated with! I like the idea of it only coming from actions from my own users

@socalledunitedstates @hope I'd rather have it only trigger a moderation request when my user follows an external account, rather than some rando asks to follow one of my users

@darius @socalledunitedstates @hope god that sounds like an amazing way to implement that. that would be such a game changer for me.

@darius @hope Then a toggle could be included to auto-deny requests from outside the instance

@socalledunitedstates @hope maybe! I'll have to think about it. Regardless, I'm doing neighborhoods first, before I tackle any white or gray listing features. Local only posting has been demonstrably a great thing and adding an expanded local scope seems like the right next step for me and my project

@darius @hope This is definitely a great project. I'm planning a new instance with a few other people, and open federation is definitely a no-go for us - but local-only posting would be great, so we're keeping an eye on Hometown for sure

Thank you for doing what you do, and good luck!

@darius
@bedap @squeakypancakes @GwenfarsGarden ☝ this is what we discussed switching to a few days ago. I'll take a more in-depth look tomorrow but the local-only posts will be very useful.

@squeakypancakes @puffinus_puffinus @bedap @GwenfarsGarden FYI I can see your follower counts from here (it may not be rendered on the profile page but the metadata is still broadcast to other instances)

@squeakypancakes @bedap @GwenfarsGarden @darius Personally, I thought that was a useless and performative move anyway. It's nice to make the effort to move away from the whole concept of a follower count, but I don't feel SBC promotes competition anyway and regardless, it's very easy to see your count.

@darius I am a bit confused - are these merge requests that have been agnored upstream or what has made it necisary to do this work in a fork? I mean I would love the possibility of instance-restricted posting. :)

@uniporn Instance-only posts have been an ignored PR in Mastodon for almost a year. Including that PR is the primary reason for the fork. github.com/tootsuite/mastodon/

@darius Then it is very good to hear of this fork, thanks for the work :)

@darius

I have a minor recommendation about your version number.

I understand wanting to keep the version on-par with Mastodon, but right now you're missing out on the usefulness of having a real Hometown version.

I suggest adding an additional number, after the Mastodon version, for the Hometime release.

So, if you had three patch updates to Hometown during Mastodon's 2.9.2 release:

Mastodon: 2.9.2
Hometown: 2.9.2.3

You want to make it easy for folks to know they have important patches.

@yam655 @darius The Hometown release is "1.0.0+2.9.2", so there is certainly a real Hometown version.

@yam655 @clacke what doc did you read? I include an explicit note about it in the release notes

@darius

I totally missed it on the page you referenced. On the readme.md in the "Versioning" section:

"Hometown follows Mastodon versioning, so Hometown v2.9.2 is up to date with Mastodon v2.9.2."

That implies it's just the same version number.

@clacke

@darius out of curiosity, why didn't you used glitch-soc or florence forks? (I think monster.pitch also have a fork)

Not that you should, I'm just curious

@bram glitch is way too heavy for me (too many "kitchen sink" features) and Florence doesn't have a full release yet (and is also, I think, going to be heavy). I did PR one of my features to Florence so they can launch with it.

@darius
@mastohost any chance MastoHost can add support for #Hometown? I'd be interested in using it.

@stevenroose @darius sorry, currently I only support Mastodon. Maybe in the future, if things evolve positively.

Sign in to participate in the conversation
Friend Camp

The decentralized web is about trust. You should only join Friend Camp if you personally trust Darius Kazemi with your social media data. You probably only have that level of trust if we are IRL friends or have been internet friends for a long time. Generally speaking this is a small, closed community. In the end, Darius is the arbiter of what is allowed here. If you don't have a good idea of the kind of behavior that flies with Darius, again, you probably shouldn't join this instance. In the interest of specificity, we do have a code of conduct and privacy policy which you should read. Friend Camp features several modifications that were requested by our users. * you can log in via any subdomain, which means you can log in to multiple accounts in the same browser session (for example, log in once on friend.camp and then as another user on alt.friend.camp) * they are no longer called "toots", they are now "posts" * if you have a locked account and you get a follow request, a reminder appears under your "post" button (on normal Mastodon mobile it is otherwise buried in a sub-menu and you might not see it for a long time) * the emoji dropdown is a neutral smiley face instead of the cry-laughing smiley @mentions are rendered as "@user" for a Friend Camp user and "@user@domain" for remote users. This helps clear up when you follow two people who have the same username on different servers. * there is a "never ask me again" checkbox on the confirmation for clearing your notifications -- more info here * When an mp3 link is in a post, we also embed an inline mp3 player. git commit here * 500 characters of profile text git commit here, requested by @deerful Important Bit from the Privacy Docs: If you want decent privacy (the info doesn't leave this server), the only way to do that is to set your account to private, only accept friend requests from other friend.camp users, and only ever @ mention other friend.camp users. Once you start talking to people on other servers, all bets are off. Any private message you send to someone on another server could be looked at by the admin of a different server. This is kind of like email: if you are on a private email server, and you send an unencrypted email to a gmail account, congrats, Google now has the content of that email. But also, you do this every day, so, hey. The internet! Our beautiful icon is based on photo3idea_studio from www.flaticon.com, licensed CC 3.0 BY. It has been modified by @casey@friend.camp!