Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Instance only statuses #8427



Copy link

@renatolond renatolond commented Aug 25, 2018

This is a WIP PR for instance-only statuses. This is largely based on the glitch-soc implementation of instance-only to make it easier to incorporate back into glitch-soc.

This assumes that clients are still unaware of local-only statuses and to avoid leaking replies outside, if the local_only flag is missing, replies to local_only posts are posted as local_only.

As in the glitch-soc implementation, local_only statuses can only be seen by users that are logged in, logged out users do not see the local_only statuses in hashtag timelines or in the "take a look inside" one. local_only cannot be fetched by the other instances, even with the link. The default option is to federate the toot

Fixes #861, #896, #1761, #2698, #3285

What is missing:

  • Refactor "local_only" into something else to avoid confusion with "local", maybe "instance_only"
  • Change icons into something more meaningful
  • Add customization in preferences to which federation status is preferred.
  • Add "local_only" indication in moderations screens
  • Fix react privacydropdown warning, probably something is duplicated since the federationdropdown component is copied over from the privacy one.
  • Run i18n, add pt-br translations


@renatolond renatolond added the expertise wanted Extra expertise is needed for implementation label Aug 25, 2018
@renatolond renatolond force-pushed the instance_only_statuses branch 2 times, most recently from dcb0e6b to 7242a68 Compare August 25, 2018 13:00
Copy link

Gargron commented Aug 25, 2018

I think it introduces very real centralization dynamics into the software. Our selling point is "pick whatever server you like, you can talk to your friends from anywhere". With this it becomes "unless you want ALL of their content, in which case you better sign up on the same server as them". So imagine gets this feature, and suddenly signing up somewhere else is not an option because you'd be missing out!

Mastodon works on a simple principle: Your posts go to your followers. Why is that not sufficient? You could block all followers from other servers you might have, and achieve the same result.

I know that there are some benefits to this feature, such as letting admins announce things for their own users only (you could add UI for mass e-mail announcements instead?) but I think the long-term effects of this feature could have catastrophic consequences.

Please explain why you think I'm wrong about this.

Copy link

With this it becomes "unless you want ALL of their content, in which case you better sign up on the same server as them".

I guess the difference then is I'm cynical in that I think most people will want to blast their content to as many followers as possible and I think people will be lazy and ignore it if it's default-off, and I'm also trusting in that I think most people will post local-only only when they're posting content that is truly not relevant to other servers - like, "wow our instance is slow today, huh?" or "I think [new feature] on could be cool, what do you think?"

I've also seen people setting up instances for particular towns, cities, universities and colleges. So if someone was a member of one of those, they might want to post "hey, bake sale in the student union foyer at 2pm today!" or "does anyone know where I can get a wide-screen TV near Main Street?" or whatever, without bothering people who would not be anywhere near those places.

I don't think Mastodon is diminished by allowing people to be insular. I feel like if you're going to promote Mastodon as being many small, safe communities focused on particular interests or geographical locations then it absolutely makes sense to allow people to post to only their own instance. I think this is a good idea, and I like having it on even though I have only used it a couple of times.

But Mastodon is already pretty insular compared to similar centralised services so I can see why you're concerned and not wanting it to be more insular.

Copy link

trwnh commented Aug 25, 2018

Would it be possible to instead treat this as a targeting issue than a federation issue? If the aim is to have a certain post visible to users of an instance, then could there be a Collection of all the users on the instance that could be cc'ed, in the same way that the #public is cc'd on public posts? It sounds like it would be better long-term to support this as a specialized case of arbitrary audiences, rather than make an entirely new feature for basically the same concept.

Copy link

nightpool commented Aug 25, 2018

my main concern is that this adds yet another layer of complexity when explaining the privacy settings to users. people already make serious mistakes because they don't understand the existing privacy levels (like set their account to locked and then posting publically because they use a third party client that doesn't respect default privacy settings).

adding yet another checkbox doubles the level of complexity.

I think the usecase here would be better served by having an "announcements" feature for admins that gets stickied to the top of local user's feeds and doesn't federate. this would be analogous to "pinned posts" on Discourse or other forum stickies.

Copy link

I think the usecase here would be better served by having an "announcements" feature for admins that gets stickied to the top of local user's feeds and doesn't federate. this would be analogous to "pinned posts" on Discourse or other forum stickies.

I do agree that this is a good idea, but it wouldn't help the non-admins who want an instance-only visibility setting for their posts, I think it serves a different purpose.

Copy link
Contributor Author

Mastodon works on a simple principle: Your posts go to your followers. Why is that not sufficient? You could block all followers from other servers you might have, and achieve the same result.

Not the same result, since it could happen that I share a public post on my instance and it gets boosted out of it by other users.

The thing for me is small instances work differently than big ones. Not only for instance-only banter, as the ones that @Cassolotl suggested, but sometimes people want to be on smaller instances and trust the admin and other users of that instance, but maybe not the wider fediverse.

I don't think it breaks federation, even if a user only posted locally and allowed for other users to follow them from the outside, it would look like they were never posting anything as from the outside it would look like a blank profile.

Also, the feature exists in glitch-soc, there's some considerably big instances running glitch-soc and we still interact with users on those instances, if they use local-only posts I don't notice any holes in their posting.

Copy link
Contributor Author

renatolond commented Aug 26, 2018

adding yet another checkbox doubles the level of complexity.

That's why the help needed tag on this one. Frontend is not my thing and I added in a way that I think it's consistent with the rest of the UI while still explaining the option (a button like the CW option I think it's not ideal because it does not explain the option) but maybe there's a better way to integrate this, maybe it can be more hidden while still being somewhere in the compose box.

Copy link

I liked the buttons you used, Lond, because they feel in-keeping with Gargron's intentions! A linked chain to federate, a broken chain to break the link from the rest of the fediverse - so the broken chain of not federating has negative connotations and is a little discouraging. It's like, only do this if you understand what it means and you're sure that's what you want.

Copy link
Contributor Author

Would it be possible to instead treat this as a targeting issue than a federation issue?

I think it could be the case, but I don't think adding the cc'ed features for groups with meta-groups like local is such an easy change, and if we integrate this into mastodon and later change this into groups, I believe this could be changed in a migration to work with such a feature.

Copy link
Contributor Author

A linked chain to federate, a broken chain to break the link from the rest of the fediverse - so the broken chain of not federating has negative connotations and is a little discouraging.

I think the link/link broken is good, but I would like even more something like this one:
And one with the relations broken for the local only, I think it would convey better and avoid associations with links, but there's nothing like that in fontawesome, that's why I went for the link ones.

Copy link

I think the link/link broken is good, but I would like even more something like this one:

Ohh that's a great one. Maybe in time fontawesome would have something like that. :)

Copy link

ggtea commented Aug 28, 2018

Is post-to-local bad because only instance's user can see them and other instance's users can't see them?
I feel LTL have same problem and is already there.
It seems that root problem is other instance's user can't join to instance's LOCAL.
I wish I could join other instance's LOCAL from mine and remote follow and post to other instance's LTL.

Copy link
Contributor Author

Local timelines are not private, they have all the public posts by local users and there are tools to browse them from outside the instance (I think at least one mobile app also implemented a similar function recently)

Local-only/instance-only posts would only be viewable, according to this implementation and glitch-soc one, to logged in users.

Copy link

PaperFixie commented Aug 29, 2018

I am a member of multiple instances, one of which is purely for communication with my local community geographically. I think it would be beneficial to have local only posts for those of us who use another instance for socializing across the fediverse, but use a different one for talking to our literal neighbors.

Copy link

I think this is beneficial and would improve my experience with Mastodon immensely. Also recently learned about a hostile instance where the admin may be using the DB to look at followers-only tweets (where the toot in question is on another instance, followers only, and the tooter follows/is followed by someone on the hostile instance. Instance only would be a barrier to such behavior. Especially for meta toots that have to deal with instance moderation this would be really nice.

Copy link

I am in favor of this feature.

imagine gets this feature, and suddenly signing up somewhere else is not an option because you'd be missing out!

Why would someone make effort to post local-only content that I, a user at some other instance, need to see?

Imagine users on sending DMs to other users -- am I missing out? Imagine users I want to follow who have privacy settings requiring approval. Imagine posts that are locked.

Your posts go to your followers.

If I have a private account and approve follow requests, that means everyone who wants to follow me doesn't get to see all my content.

That's a restriction based on personal privacy consideration, which is good and important, but it doesn't serve the same purpose as instance-only toots would, which I feel is also a good and important option to have.

If for some reason I do an instance-only toot that seems so great it should go beyond my instance, I can always re-toot it, or someone on the local can always copy/paste it.

Much like private toots that one might later decide to make public, no one ever gets things perfect on the first go. It'd be nice to have this option available for use.

Copy link

a-dows commented Aug 29, 2018

I run a geographically-oriented instance, and this would provide massive utility to us.

"Instance-only + followers" toots would help me make administrative announcements, and give peace-of-mind to users so they can feel comfortable posting classifieds or other personally-identifiable content, and in general facilitate the growth of a class of instance that is popping up all around the world.

I understand that it adds complexity, but if the feature is opt-in on an administrative level, it would improve my users' Mastodon experience tremendously.

Copy link

I'm a member of a regionally-focused instance, and there are many in the instance that would like a local_only feature. Personally, some posts are either more appropriate to the instance because they are very regionally-specific (meet-up, organizing, and local advocacy toots) or are related to trust issues from lessons learned from birdsite. I like to keep most of my toots in the federated timeline and my followers, but there are times when I simply want to avoid it but want it to be readable by the entire instance.

Copy link
Contributor Author

"Instance-only + followers"

In this case you mean that the post doesn't leave your instance, but only goes to all the followers on your instance?

Copy link

a-dows commented Aug 29, 2018

In this case you mean that the post doesn't leave your instance, but only goes to all the followers on your instance?

Yes, 100%.

Copy link

a-dows commented Aug 29, 2018

If this feature is implemented, my followers who are not on my instance won't be bothered by locals-only content that doesn't apply to them—my general-interest toots will reach them, while my administrative and locals-only content won't. This is a better experience for both poster AND follower.

With this it becomes "unless you want ALL of their content, in which case you better sign up on the same server as them".

My followers have permission to see my toots; they do not have the right to see absolutely everything I post. With local-only posting as an option, my federated followers will still get 100% of my general-interest content.

Copy link

I am in favour of local-only statuses. It does not remove functionality from the core idea of Mastodon. It does add functionality that allows a more diverse set of use-cases. Including, what I believe is essential, allowing a user to not federate a message if they don't want to, thereby controlling its distribution. This can be critical for privacy and safety purposes. Please implement this function.

Copy link

The privacy levels on Mastodon are already a bit tricky, and I don't think this makes them any harder to understand. I see more benefit in the comfort of knowing one's posts won't leave their instance at all than detriment of more privacy confusion. Plainly explaining the feature is enough. Geographic instance users will love this.

Copy link

t54r4n1 commented Aug 29, 2018

Instance only meetups are fun and I want to plan more of them, as a mod of a geographic instance please let me have a tool to do this!

Copy link

rtxanson commented Aug 29, 2018

I'm not on a region-specific instance, but follow a ton of people on a region-specific instance because I live in that region. I'd be in favor of "instance only + followers" if "followers" could also mean followers on other instances. Alternatively, would there be a way for me to filter a timeline to only see instance-specific tweets, meaning I could potentially make an account for the sole purpose of making sure I'm not missing important stuff?

I can see how there's a difference between a need for admins and mods of instances to communicate information that is only relevant to people on the instance (server updates, downtime, etc.), I see the need to address privacy concerns people laid out here, but what to do about regionally relevant information for people who aren't on a regional instance? I guess it might be up to posters to determine if their target audience also includes a selection of people who might need to see that content too.

Copy link

I admin (170 registered accounts). Here's my case for local-only status privacy:

  • It's intuitive. We have a local timeline, but currently no way to post to it without also posting to the federated timeline. My users ask how to do this frequently, and I have to explain they can't.
  • It gives users choice. More granular privacy controls are better, as a general rule, and add value for users who choose to take advantage of them.

The lack of local-only compels people to share posts more broadly than they would like to serve a network purpose ("feed more content to the federated timeline"). However,

  • Local-only will make the federated timeline better and more useful in most circumstances. The federated timeline on large instances is almost useless because it has too much content. Do users on other instances really need/want to wade through posts about parking in Poughkeepsie, or the level of bus service in Boston, or the weather in Walla-Walla? Why shouldn't the author of those statuses have the discretion to spare the world things that are not of general interest?

Mastodon has largely grown out of the need to programmatically generate content for the federated timeline. Some of it could be spared everyone's eyeballs and nobody will feel the loss. And I have no doubt that a lot of stuff that could be local only will still be posted under the default world-readable setting.

  • Adding the option puts the choice of whether to publish that information more widely in the hands of the author, not the code. Nobody would be required to post local-only. It would simply be an option so a user could avoid cluttering feeds with information unlikely to be of interest.

I'm neutral about whether it should be implemented as local-only or local-and-friends-only, but I suspect one or the other has deeper implications for the way federation works, so if that's the case the simpler implementation would be better than none at all.

ClearlyClaire and others added 12 commits October 19, 2020 15:39

* Change content-type to be always computed from file data

Restore previous behavior, detecting the content-type isn't very
expensive, and some instances may serve files as application/octet-stream
regardless of their true type, making fetching media from them fail, while
it used to work pre-3.2.0.

* Add test
* Fix contrast calculation for thumbnail color extraction

Luminance calculation was using 0-255 RGB values instead of 0-1 sRGB values,
leading to incorrectly-computed contrast values.

Since we use ColorDiff already, just use its XYZ colorspace conversion code
to get the value.

* Require at least 3:1 contrast for both accent and foreground colors

* Lower required contrast for the accent color
* Add support for inlined objects in activity audience

* Add tests

* use custom private boost icon for detail status

* only use className

Follow-up to mastodon#14359

In the case of limited toots, the receiver may not be explicitly part of the
audience. If a specific user's inbox URI was specified, it makes sense to
dereference the toot from the corresponding user, instead of trying to find
someone in the explicit audience.
* Add support for latest HTTP Signatures spec draft

- add support for the “hs2019” signature algorithm (assumed to be equivalent
  to RSA-SHA256, since we do not have a mechanism to specify the algorithm
  within the key metadata yet)
- add support for (created) and (expires) pseudo-headers and related
  signature parameters, when using the hs2019 signature algorithm
- adjust default “headers” parameter while being backwards-compatible with
  previous implementation
- change the acceptable time window logic from 12 hours surrounding the “date”
  header to accepting signatures created up to 1 hour in the future and
  expiring up to 1 hour in the past (but only allowing expiration dates up to
  12 hours after the creation date)
  This doesn't conform with the current draft, as it doesn't permit accounting
  for clock skew.
  This, however, should be addressed in a next version of the draft:

* Add additional signature requirements

* Rewrite signature params parsing using Parslet

* Make apparent which signature algorithm Mastodon on verification failure

Mastodon uses RSASSA-PKCS1-v1_5, which is not recommended for new applications,
and new implementers may thus unknowingly use RSASSA-PSS.

* Add workaround for PeerTube's invalid signature header

The previous parser allowed incorrect Signature headers, such as
those produced by old versions of the `http-signature` node.js package,
and seemingly used by PeerTube.

This commit adds a workaround for that.

* Fix `signature_key_id` raising an exception

Previously, parsing failures would result in `signature_key_id` being nil,
but the parser changes made that result in an exception.

This commit changes the `signature_key_id` method to return `nil` in case
of parsing failures.

* Move extra HTTP signature helper methods to private methods

* Relax (request-target) requirement to (request-target) || digest

This lets requests from Plume work without lowering security significantly.
Copy link

blaine commented Nov 5, 2020

Just bumping this - I want to add that most of the concerns here seem to be around forcing people to be on a single instance, and breaking the federated model. I want to add two things that haven't been discussed as possibilities on this issue as far as I can tell:

  1. A clear use-case for this feature beyond small niche networks is intra-company networks; if I wanted to set up a mastodon instance for my company, I would need to not federate, since clearly the goal would be to share private or commercially sensitive content. However, with local-only posts, it would be possible for employees to share some things publicly, but most things privately.

  2. If people are concerned with that loss of federation means that multiple accounts need to be maintained to access multiple networks, set up the activitypub equivalent of email forwarding. There's nothing in federation model that prevents this (indeed, it was a core design goal when we created webfinger). Where forwarding doesn't work (e.g., if you want to create a "local" community that is composed of people who are distributed across a variety of mastodon instances), the "Groups" model that has been mentioned in the comments on this issue and works for virtually all chat applications would be a logical extension of this behaviour.

There are plenty of legal and commercial reasons to implement this, and I'm happy to discuss those if it's relevant or interesting. I for one firmly believe that the Fediverse can only be truly successful if it manages to dislodge the incumbents' control over online sociality. The only way that can happen is if it's both possible and supported for the fediverse to be used in commercial contexts, and I sincerely hope that's coming. I'd rather a world without capitalism, but honestly I don't think that's Mastodon's fight to win.

If there's a better way to implement this sort of site-specific functionality, possibly through some plugin infrastructure or similar, I'd be keen to explore that. I'm not up to date with the current state of mastodon so it's entirely possible that I've missed something, but I need this or similar functionality and would prefer to not diverge massively from mainline mastodon, precisely for the reason of continuing support for federation! It'd be easy to run a non-federating instance to achieve my goals, but the downside is immense.

Copy link

I am in favor of this feature, for these reasons here: #861 (comment)

I agree with @Gargron that it doesn't make sense for general-purpose instances (e.g. and would be counterproductive there, but it would allow local communities (in my case a local sports club) that have internal/irrelevant stuff and public toots. Thus, why not having this feature (built-in or as add-on) and disabling it by default, but the admin of an instance can switch it on?

Copy link
Contributor Author

I've merged the latest tag on this :)

Base automatically changed from master to main January 20, 2021 10:31
Copy link

stale bot commented Sep 26, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status/wontfix This will not be worked on label Sep 26, 2021
@stale stale bot closed this Oct 11, 2021
Copy link

I would still like this feature

Copy link

grahhnt commented Jun 25, 2022

This feature would still be a nice feature to add to Mastodon

Copy link

unitof commented Nov 21, 2022

For those who aren't aware: this feature has been implemented in (and is one of the few diverging features) of the fork of Mastodon, which runs,, and others.

Copy link
Contributor Author

This branch is still kept up to date as well, since I also implement it on the fork that I use for my instance and some other Brazilian instances use too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
status/wontfix This will not be worked on
None yet

Successfully merging this pull request may close these issues.

Add a "Local timeline" privacy option