[WIP] Instance only statuses #8427
Conversation
renatolond
added
the
expertise wanted
renatolond
force-pushed
the
instance_only_statuses
branch
2 times, most recently
from
dcb0e6b
to
7242a68
Compare
|
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 mastodon.social 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. |
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 glitch.social 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 dev.glitch.social 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. |
|
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 |
|
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. |
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. |
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. |
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. |
|
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. |
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. |
I think the link/link broken is good, but I would like even more something like this one: https://www.iconfinder.com/icons/175933/connections_graph_network_relations_structure_icon |
renatolond
force-pushed
the
instance_only_statuses
branch
from
7242a68
to
694640e
Compare
Ohh that's a great one. Maybe in time fontawesome would have something like that. :) |
|
Is post-to-local bad because only instance's user can see them and other instance's users can't see them? |
|
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. |
|
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. |
|
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. |
|
I am in favor of this feature.
Why would someone make effort to post local-only content that I, a user at some other instance, need to see? Imagine users on mastodon.social 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.
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. |
|
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. |
|
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. |
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%. |
|
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.
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. |
|
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. |
|
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. |
|
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! |
|
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. |
|
I admin mspsocial.net (170 registered accounts). Here's my case for local-only status privacy:
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,
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.
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. |
) * 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
…#14471) * use custom private boost icon for detail status * only use className
…odon#14656) 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 https://www.ietf.org/id/draft-ietf-httpbis-message-signatures-00.html - 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: httpwg/http-extensions#1235 * 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.
|
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:
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. |
|
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. mastodon.social) 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? |
|
I've merged the latest tag on this :) |
|
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. |
|
I would still like this feature |
|
This feature would still be a nice feature to add to Mastodon |
|
For those who aren't aware: this feature has been implemented in (and is one of the few diverging features) of the https://github.com/hometown-fork/hometown/ fork of Mastodon, which runs https://weirder.earth, https://realsocial.life, and others. |
|
This branch is still kept up to date as well, since I also implement it on the https://github.com/masto-donte-com-br/mastodon/ fork that I use for my instance and some other Brazilian instances use too. |
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: