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

Add a "Local timeline" privacy option #861

Open
alex73630 opened this Issue Apr 4, 2017 · 45 comments

Comments

Projects
None yet
@alex73630

alex73630 commented Apr 4, 2017

It would be useful for instance admins to send toots only to instance users.

It would look like this:

image

Is it possible in Mastodon ?


  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
@yiskah

This comment has been minimized.

Contributor

yiskah commented Apr 5, 2017

It's possible but undesirable as it would promote users siloing and piling onto the same instance. This centralizes what should be a de-centralized distributed system. Users should not be afraid of migrating accounts due to missing out on particular content, this defeats a major point of federation.

@alex73630

This comment has been minimized.

alex73630 commented Apr 5, 2017

Well, I would like to have this to toot when I'm doing an update without "spamming" federated timelines, as this only concerns my instance and not other ones.

@seascape

This comment has been minimized.

seascape commented Apr 11, 2017

As a user (not admin) I would very much like the ability to occasionally post content only to users of my instance. This feels like an obvious missing feature to me.

I see your criticism, yiskah. Two thoughts:

  1. I don't think the existence of such a feature would lead to a sudden huge movement toward local-only posting. People, myself included, love Mastodon's federation; it's one of its key strengths and differentiators.

  2. Allowing that some instances did choose to turn insular... why not? A few instances of many. The software can be used different ways by different people with different needs/wants/desires.

My own use case: marginalized identity, and fear external (originating outside Mastodon) harassment. I want to participate more openly (posting selfies I wouldn't want widely disseminated, for example) but hesitate to do so on an essentially worldwide basis.

But my instance? It's small, well run, and I feel enough trust there. Local posting reduces tens of thousands of randos to tens of hundreds of self-selected people who tend to be more like me, sympathetic to me, supportive of me.

Is my local-only content totally safe from bad actors? Of course not. But there would still be an overall increase of safety and trust (less randos) and I'd be able to feel pretty OK about the risk profile of sharing sensitive content when the occasion arises.

@zyphlar

This comment has been minimized.

zyphlar commented Apr 12, 2017

I think this is a critical feature of federation: choosing how far to broadcast certain stuff. Otherwise certain sensitive or insular groups (think: an instance for a church, or for an addiction support group) will be forced to completely de-federate and/or block all other instances, which is an overreaction.

Essentially, Facebook is currently great at creating hidden/secret/private groups and networks like Google+ have recognized this need (with Circles) -- without this ability, privacy controls will not be fine-grained enough and sensitive users/use-cases will not find Mastodon useful.

@rmrmadani

This comment has been minimized.

rmrmadani commented Apr 12, 2017

@aral

This comment has been minimized.

aral commented Apr 15, 2017

More use cases in support of this:

  1. A family instance: parents want to tell the family something.
  2. A school instance: a notice for all students and faculty in a school.
  3. Any instance: administrative messages affecting people on that instance (“server will be down for maintenance between the hours of X and Y today’’).
@Gargron

This comment has been minimized.

Member

Gargron commented Apr 15, 2017

Federation happens user-to-followers, not server-to-server, so stuff like this is hard. Like, you want to post something to your followers, but only followers from your own instance?

@datn

This comment has been minimized.

datn commented Apr 15, 2017

No, the idea is it's a public but unfederated post. In the same way that posts from people you don't follow appear on the PTL of your instance, but limited to the instance itself.

@nightpool

This comment has been minimized.

Collaborator

nightpool commented Apr 17, 2017

@Gargron The idea is that it would be useful for admin announcements and similar intra-community stuff. It would be a public toot, just prevented from federating to any other instance.

@kepstin

This comment has been minimized.

kepstin commented Apr 17, 2017

As far as implementation, my thoughts are that with this setting:

  • the toot would appear in the local timeline on the instance (possibly also in the federated timeline on local instance only)
  • when the toot is sent to another instance via federation, it would be marked in the same way as a "private" toot - i.e. followers would see it, but it wouldn't be put into the federated timeline on that instance.
@seascape

This comment has been minimized.

seascape commented Apr 17, 2017

@kepstin, regarding your second bullet, I'm not sure why a hypothetical local-instance-only toot would be federated at all? The point would be that it's only local, and not sent out everywhere.

@kepstin

This comment has been minimized.

kepstin commented Apr 17, 2017

I don't think the local-only toot can/should really be "private" to the instance completely (after all, you could still browse the user's profile or use e.g. mastoview to see it), so the main purpose of this would be to make it not go into the federated timeline on other instances.

If someone's explicitly following another person, they might be interested in seeing even their "listed locally only" toots.

This also fits in with the position of the option in the list in the mockup in the first post. Preventing followers on other instances from seeing the toot is simultaneously more private that private and less private than unlisted.

@seascape

This comment has been minimized.

seascape commented Apr 17, 2017

I don't think the local-only toot can/should really be "private" to the instance completely (after all, you could still browse the user's profile or use e.g. mastoview to see it), so the main purpose of this would be to make it not go into the federated timeline on other instances.

Yes, some randos could still stumble upon it via mastoview or a potential instance public timeline feature. So be it. Seems hard to avoid.

If someone's explicitly following another person, they might be interested in seeing even their "listed locally only" toots.

But I might be interested (ok, I am) in that outside follower not seeing (easily, by default) my instance-only toots. I made them local (home instance only) for a reason. My intent would be "only people on my instance can (easily, by default) see this."

Maybe I question the point of adding local posting if it only partially works as the average user would expect. To me it's pretty clear that "local" does not mean "also on all federated servers." Local means local. Local, in the way I am describing, gives the user another tool to control a toot's audience.

(In a related case I was very surprised that "private" toots do not go out to federated followers, only local ones. I think a lot of users expect otherwise. But that's a different issue and I am not privy to the history that lead to that situation. Just seems similar.)

@zyphlar

This comment has been minimized.

zyphlar commented Apr 17, 2017

@Resosphere

This comment has been minimized.

Resosphere commented Apr 28, 2017

Hi, I registered mostly to say I would love that possibility to become a reality. Fediverse is nice, little community are nice too. That I love in mastodon is the possibility to interact with a "little" group of person, and thoses only. Sometimes I wish to speak to peoples of my instance only too.

@hipparkhos

This comment has been minimized.

hipparkhos commented Apr 29, 2017

I'd like this feature a lot. The toot would appear only in the local timeline and not to remote federated ones. This can be useful for users of a thematic instance, and It would still allow to choose to send toots worldwide, or to followers on any instance.

@rtucker

This comment has been minimized.

Contributor

rtucker commented Apr 30, 2017

This feature is essential for local administration discussions, as right now the only way for an admin to post a message to local users is to post it globally. This results in matters of local governance turning into global discussions, which is very undesirable.

@alex73630 alex73630 referenced this issue May 2, 2017

Closed

do-not-federate flag #2698

1 of 1 task complete
@latrani

This comment has been minimized.

latrani commented May 4, 2017

Just had some good discussion about this on the Discord. I put together a rough sketch of some UX options here, the consensus in discussion previously was that the 'tabs' option is clearer than the 'switch' option.

Mastodon Local.pdf

We also discussed a concerning edge-case regarding mentioning off-instance users in local toots. In some cases, this is at best confusing (A direct local toot to an off-instance user will never arrive) and at worst may leave users open to abuse (by allowing them to be easily talked about and linked to, before switching a conversation to federating)

As such it seems reasonable that mentioning an off-instance user in a local toot should always be treated as an error and prevent posting. This allows the behavior to remain consistent across privacy types.

@jmfcodes

This comment has been minimized.

jmfcodes commented May 21, 2017

i'd love to see this. i totally respect that it's a complex ask, too, but i think this would help foster safer spaces for those who need or want them, and also it would build a lot more community. building smaller communities that can also interact globally might help nurture the close-knit family feeling that's sort of faded away a bit as the userbase has grown exponentially. (the growth isn't a bad thing! i see this more as adapting to the needs of as many people as possible.)

@Cassolotl Cassolotl referenced this issue May 24, 2017

Closed

Toot only to the local timeline. #3285

2 of 2 tasks complete
@jmfcodes

This comment has been minimized.

jmfcodes commented Jun 24, 2017

gonna nudge this in the hopes it'll happen sometime :)

@deusofnull

This comment has been minimized.

deusofnull commented Sep 29, 2017

This issue thread came up in conversation on a node im on and im happy to see it being discussed.

I think the value of federation is that it is decentralized and allows for diverse, distinct groups to exist, not only that it distributes the server load onto thousands of different community run nodes. Allowing for nodes to have "private" discussions allows for the distinctness of the node to develop.

I don't believe this would discourage ultra-private communities however. If anything, a node that wants to have the option to be private sometimes would be pushed towards not federating if it meant they couldn't.

I'd love to help out as I learn more about mastodon. I'll check in on this when im up to speed.

thx y'all

@Cassolotl

This comment has been minimized.

Cassolotl commented Sep 29, 2017

If anything, a node that wants to have the option to be private sometimes would be pushed towards not federating if it meant they couldn't.

Absolutely!

@ghost

This comment has been minimized.

ghost commented Oct 11, 2017

Since version 1.6 it's possible for new users to auto-follow e.g. an admin account. This partly solves the case in the original post. If somehow it would be possible to let pre-1.6 users auto-follow the admin, it would be a lot easier for admins to inform their users. Of course it must always be possible for users to stop following admins.

@wxcafe

This comment has been minimized.

Contributor

wxcafe commented Nov 7, 2017

This is still needed, be it for admins to users communications or for community-only posts.

@jmfcodes

This comment has been minimized.

jmfcodes commented Nov 7, 2017

I'd also still like to see this issue implemented too.

Right now, when there's an instance issue, my instance is setting up chats on other services for our members to discuss it. We shouldn't have to rely on other social network services to manage and moderate this social network.

And, as always, I recognize that I'm a non-tech person making a very tech-intensive request, but y'all have been great with making the impossible happen for the improvement of the fediverse. <3

@alice-sawatzky

This comment has been minimized.

alice-sawatzky commented Nov 8, 2017

If anyone is part of a Secret Group on facebook, the value of this feature becomes apparent. This is a great way to provide smaller, safer spaces to marginalized groups without requiring admins to fully disable federation. Overall, providing this feature would IMO actually improve federation and reduce "siloing".

@PubliqPhirm

This comment has been minimized.

PubliqPhirm commented Nov 15, 2017

Similar to the idea that devon suggested, a good use for instance-only posts are instances that wish to be like a private commons where the users can optionally connect to the broader fediverse (unlike the siloed forums of yesterday, where each forum was always a separate account with little to no cross-pollination). This technically could be done today with an agreement between members of an instance to lock their account, follow all the other users on the instance, and post followers-only, but this is unrealistic and unmanageable once you have a significant number of users on your instance.

@PubliqPhirm PubliqPhirm referenced this issue Nov 16, 2017

Open

Granular Post Privacy #5723

1 of 2 tasks complete
@fsnk

This comment has been minimized.

fsnk commented Nov 29, 2017

I like the idea of the OP which as I understand it is an admin option to do a local broadcast about issues only relevant to the server. (e.g. maintenance downtime)

It might be more useful if this was something handled through the admin interface, though, and with a pin function (which users could unpin from their column) so that it could attach it to the top of the local timeline feed so that important announcements don't get swept away in the timeline.

Regarding some of the use cases for normal conversation/users, it seems like the assumption is the local timeline is a discussion group, and that posts should have a "group only" privacy setting. That may work ad hoc on some smaller instances, but as @PubliqPhirm pointed out, it becomes unrealistic as more users join.

abcang added a commit to pixiv/mastodon that referenced this issue Mar 1, 2018

Merge pull request tootsuite#861 from pixiv/snowflake
Remove Snowflake migration code from FeedManager
@fsnk

This comment has been minimized.

fsnk commented Mar 30, 2018

I know this has been dormant for a while, but I think Switter is a good use case for why a "local timeline only" posting option is potentially useful.

The concern here is not so much privacy expectation, but giving instances the ability to be good neighbours when their content policies differ from much of the wider Fediverse.

Right now there's no visibility setting that allows Switter users to discover each other in their local timeline without also broadcasting to the wider fediverse..

Obviously "local only" wouldn't stop users on other servers who may follow a Switter user from boosting a post that violates their local content policy into the timelines of their instance, but that would be an issue for local admins to handle with those users boosting the content, not with users from another server violating it inadvertently because someone follows them.

I also suggest that admins be able to configure a global default visibility setting for posts and sensitivity setting for media posted on their instance.

@Gargron

This comment has been minimized.

Member

Gargron commented Mar 30, 2018

Obviously "local only" wouldn't stop users on other servers who may follow a Switter user from boosting a post

Well, no, they wouldn't receive those posts even if they follow the Switter user... Which is my main issue with the desire for this feature: It violates the expectation that if you follow someone, you get their posts. This is so integral to Mastodon: "You can follow & interact with anyone regardless which server they are on!" If this is implemented, then we'll get a situation like "You have to sign up on Switter to interact with Switter users" and voilà, we have growing silos. :(

@fsnk

This comment has been minimized.

fsnk commented Mar 30, 2018

@Gargron Oh that's a good point. I hadn't thought of it being implemented like that. My expected behaviour was that "Local" would fall somewhere between "Public" and "Unlisted" and apply to the public timelines where the post appears; visibility to followers would be the same as "Public" or "Unlisted". That might not be what everyone expects though.

It would be nice if there was some way to allow Switter users to post publicly to each other without the end result being a silo, either defacto because they're widely silenced or suspended, or self-imposed, because they don't have adequate controls for their content visibility. They're trying to be super nice and respectful, which is great, but part of their purpose is to be able to advertise services, which means they need discoverability too.

@alex73630

This comment has been minimized.

alex73630 commented Mar 30, 2018

Actually, I always wanted this feature to still allow remote followers to see those local posts, like an unlisted post but that still appears in the local timeline.

The end goal isn't to lock a post on an instance, as it kills the social and sharing experience.

It's been a year since this issue have been created, a lot of comments pointed the fact that it's a good feature that should be implemented, if remote followers can still see those posts. Maybe the basic idea wasn't explicit enough and leading to misunderstanding and then to a full year of discuss.

Tldr : Local post are "unlisted post" that are still listed in the local timeline (and so in remote followers timelines)

@steckerhalter

This comment has been minimized.

steckerhalter commented Jun 12, 2018

I'm hitting this issue as well, not as an admin but as a user of an instance that revolves around a local community. The problem is this: when we have matters to discuss that only concern the local community it means that we spam the timelines of all the remote followers with things they have nothing to do with. So to use Mastodon for such a community is not ideal and yet that's where I see the most of the potential. Hence I think it would be important to find some kind of solution for this use-case.

@Gargron

This comment has been minimized.

Member

Gargron commented Jun 12, 2018

Local post are "unlisted post" that are still listed in the local timeline (and so in remote followers timelines)

Is that actually what everyone here would be okay with? I had the impression this was more about not letting a post leave your server at all, this is how the glitch-soc tried implementing it as well.

@jmfcodes

This comment has been minimized.

jmfcodes commented Jun 12, 2018

@Gargron when i say "local post," I mean it in the way you describe: instance-only posts.

However, I thought that this would include the users who are following you by default. It is my impression that many users feel this way-- followers can see everything that isn't a direct message, and every other permission change (instance-only, unlisted, public/federated) would all be in addition to that basic "followers see everything" idea.

@steckerhalter

This comment has been minimized.

steckerhalter commented Jun 12, 2018

I don't understand why "followers see everything" is a criteria. They don't see direct messages as @jmfcodes points out already. And when someone does an "instance post" he doesn't want remote people to see it for a specific reason (mostly I would say because it concerns just the local instance, for example, what do I care if admin X on instance Y is doing a server maintenance which doesn't affect me?)

it doesn't have to be so that the messages don't federate, but only that they don't appear in the timeline of remote users

@alex73630

This comment has been minimized.

alex73630 commented Jun 12, 2018

My point of view was that those "local posts" would still federate but wouldn't be shown in the Federated timeline. Outside of the instance, they would only appear in followers TL.

The concern for a lot of users was that feature would lock users toots in one instance and kill the federated concept of Mastodon, and so be against the project philosophy.

I've suggested that we could add an option to choose to not federate a "local post", but as I said, a lot of people here were against this feature.

Now, I think the choice is now down to @Gargron, if a "local post" can not be federated if the user want it to. And, the "local post" still makes sense and a lot of users still want this feature, even if it's federated.

@steckerhalter

This comment has been minimized.

steckerhalter commented Jun 12, 2018

The concern for a lot of users was that feature would lock users toots in one instance and kill the federated concept of Mastodon, and so be against the project philosophy.

I see the concern, here's an idea, federate the messages unlisted and let the user on remote instances choose if he wants to see the "local" messages from other instances in his timeline.

@zcdunn

This comment has been minimized.

zcdunn commented Jun 13, 2018

Pleroma has a chat feature that is used for instance-specific communication, but I think it uses a different message delivery mechanism to avoid the federation issues. Maybe that's a possible solution.

@pwFoo

This comment has been minimized.

pwFoo commented Jul 15, 2018

Instead of instance private messages I would need private group communication (#139). Should be a solution here too with a group with all the locale User, but more flexible?

@renatolond renatolond referenced a pull request that will close this issue Aug 25, 2018

Open

[WIP] Instance only statuses #8427

4 of 6 tasks complete
@manedfolf

This comment has been minimized.

manedfolf commented Sep 7, 2018

I concur with what appear to be a few similar ideas here:

Local + followers might be a better compromise to avoid siloing.

@steckerhalter

This comment has been minimized.

steckerhalter commented Sep 7, 2018

so yeah, I had this idea that one could do @instance.social which would make it possible to target specific instances, e.g.

@local.instance the server is going down for 5 min

foreign:

@mastodon.social how would you rate your server?

or multiple servers:

@local.instance @maki.taki we'd like our two communities to have a regular meeting, what do you think?

abcang added a commit to pixiv/mastodon that referenced this issue Oct 12, 2018

@Gargron Gargron added suggestion and removed enhancement labels Oct 20, 2018

@caliboy557

This comment has been minimized.

caliboy557 commented Dec 5, 2018

Why has is this feature so contentious? Many users of marginalized groups who participate in instances that are considered "Safe spaces" would love to post publicly within the instance, but may not necessarily want to publicly post on the entire federated timeline.

Example: An LGBT group

With current settings, you can either choose to blast the entire federated timeline with your posts, unlist your posts completely, which means people literally can't even find your content, or post only to followers, which is pretty much the same thing. I don't want random people seeing posts that are geared toward a specific audience.

This invites instances of abuse, harassment, doxing, etc from outside groups who see these posts, don't agree with them, etc. It's not so much about "Siloing" content, it's more about giving users the ability to control who can see their content.

FB allows groups to be public, private, or even secret. There are public LBGT groups, there are private LGBT groups, and there are secret LGBT groups. Users of course want to be able to control who can see their content. I don't want a group of homophobic neo-nazi's to see LGBT content and be able to share it, comment on it, etc. For marginalized groups, this control is ESSENTIAL to creating a safe space for users to comment and participate openly.

Why is it such a controversial feature to simply give people the CHOICE to do what they want?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment