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

Open
wants to merge 53 commits into
base: master
from

Conversation

Projects
None yet
@renatolond
Collaborator

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

image
image
image
image
image
image

@renatolond renatolond force-pushed the masto-donte-com-br:instance_only_statuses branch 2 times, most recently from dcb0e6b to 7242a68 Aug 25, 2018

@Gargron

This comment has been minimized.

Member

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 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.

@Cassolotl

This comment has been minimized.

Cassolotl commented Aug 25, 2018

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 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.

@trwnh

This comment has been minimized.

Contributor

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.

@nightpool

This comment has been minimized.

Collaborator

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.

@Cassolotl

This comment has been minimized.

Cassolotl commented Aug 25, 2018

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.

@renatolond

This comment has been minimized.

Collaborator

renatolond commented Aug 26, 2018

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.

@renatolond

This comment has been minimized.

Collaborator

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.

@Cassolotl

This comment has been minimized.

Cassolotl commented Aug 26, 2018

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.

@renatolond

This comment has been minimized.

Collaborator

renatolond commented Aug 26, 2018

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.

@renatolond

This comment has been minimized.

Collaborator

renatolond commented Aug 26, 2018

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: https://www.iconfinder.com/icons/175933/connections_graph_network_relations_structure_icon
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.

@renatolond renatolond force-pushed the masto-donte-com-br:instance_only_statuses branch from 7242a68 to 694640e Aug 26, 2018

@Cassolotl

This comment has been minimized.

Cassolotl commented Aug 26, 2018

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

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

@ggtea

This comment has been minimized.

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.

@renatolond

This comment has been minimized.

Collaborator

renatolond commented Aug 28, 2018

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.

@PaperFixie

This comment has been minimized.

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.

@melissamcewen

This comment has been minimized.

melissamcewen commented Aug 29, 2018

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.

@apiontek

This comment has been minimized.

apiontek commented Aug 29, 2018

I am in favor of this feature.

imagine mastodon.social 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 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.

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.

@a-dows

This comment has been minimized.

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.

@FlamingOntheNet

This comment has been minimized.

FlamingOntheNet commented Aug 29, 2018

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.

@renatolond

This comment has been minimized.

Collaborator

renatolond commented Aug 29, 2018

"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?

@a-dows

This comment has been minimized.

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%.

@a-dows

This comment has been minimized.

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.

@seanmpuckett

This comment has been minimized.

seanmpuckett commented Aug 29, 2018

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.

@giromide

This comment has been minimized.

giromide commented Aug 29, 2018

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.

@t54r4n1

This comment has been minimized.

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!

@rtxanson

This comment has been minimized.

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.

@lawremipsum

This comment has been minimized.

lawremipsum commented Aug 29, 2018

I admin mspsocial.net (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.

ThibG and others added some commits Nov 10, 2018

Fix "tootctl media remove" can't count the file size (#9288)
* Fixed an issue where "tootctl media remove" can not count the file size.

* Fixed the problem pointed out by codeclimate.
Update Nginx config for Nanobox apps (#9310)
The Nanobox files have gotten out of sync, a touch, with what Masto needs for Nginx settings. This PR updates them accordingly.
WebSub: ATOM before RSS (#9302)
Hello,
The ATOM feed contains the hub declaration for WebSub, but the RSS
version does not.
RSS/ATOM readers will typically pick whichever version comes first, and
will thus not see the WebSub feature.
I therefore suggest putting the ATOM version first, as it is more
feature-rich than its RSS counterpart is.

Clients not compatible with ATOM would not pick it anyway due to the
different type attribute.

A more complicated alternative would be to declare the WebSub feature in
the RSS version as well, using something like the following code, and
ensuring that clients subscribed to the RSS version would receive PuSH
updates just like those subscribed to the ATOM version.

````xml
<rss version="2.0" xmlns:webfeeds="http://webfeeds.org/rss/1.0"
xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<atom:link rel="self" type="application/rss+xml"
href="https://diaspodon.fr/users/test.rss"/>
<atom:link rel="hub" href="https://diaspodon.fr/api/push"/>
</channel>
</rss>
```
Touch account on successful response, change char shown when culled (#…
…9293)

Just the color is not enough change since not everyone uses colored
terminals.
Touching the account makes it so that the account is not in the
threshold window in case of running again
Ignore JSON-LD profile in mime type comparison (#9179)
Ignore JSON-LD profile in mime type comparison
Fix connect timeout not being enforced (#9329)
* Fix connect timeout not being enforced

The loop was catching the timeout exception that should stop execution, so the next IP would no longer be within a timed block, which led to requests taking much longer than 10 seconds.

* Use timeout on each IP attempt, but limit to 2 attempts

* Fix code style issue

* Do not break Request#perform if no block given

* Update method stub in spec for Request

* Move timeout inside the begin/rescue block

* Use Resolv::DNS with timeout of 1 to get IP addresses

* Update Request spec to stub Resolv::DNS instead of Addrinfo

* Fix Resolve::DNS stubs in Request spec
Allow hyphens in the middle of remote user names (#9345)
Fixes #9309

This only allows hyphens in the middle of a username, much like dots,
although I don't have a compelling reason to do so other than keeping
the changes minimal.
@bgiesing

This comment has been minimized.

bgiesing commented Dec 5, 2018

I've talked to a lot of people looking to join Mastodon cause the Tumblr situation but they won't because Local-only isn't an option.

They want to post stuff that they would be too embarrassed to post if the wider public across the whole fediverse would be able to see it and use it against them but at the same time, they don't want to make the posts Private or Unlisted since nobody in their instance (which is geared toward the exact thing they would be embarrassed to post) could see it then.

I think the best solution for "local-only" posts is if it was "Local-only" for just the Public timelines. People in other instances could still see the post if they followed you or had the direct link. That way it's a mix of Public and Unlisted, Public for your local instance, Unlisted for everyone else.

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