do-not-federate option

[ghost]

the ability to mark a post of any privacy level to Not federate to other instances. this enables local-timeline-only posting, and allows other interesting interactions, like unlisted posts to only people you trust on a private instance that's just yr closest friends.

[wolfteeth]

I love this idea.

[ekiru]

So, I've said I'll implement the user-facing side of this (server-side support for it, currently applied to all toots ending in the eye emoji, has already been implemented by @beatrix-bitrot ), and I've done a little work toward that. This comment is going to summarize some Discord discussions from earlier this week on how the UI for this should work and provide a checklist of things that have been and should be done to implement this feature.

The conversation in #design-input in the Discord included at least @Hoodiek and Alice (I don't know if they're on github/what their username here is so not @ ing them) and @beatrix-bitrot and covered what the UI should look like. We were initially looking at this mockup from the related tootsuite issue: https://github.com/tootsuite/mastodon/files/975229/Mastodon.Local.pdf . I think we decided to not use that approach: instead Hoodie suggested (and Alice agreed with) a button that would activate an Advanced Options menu which could include both the local-only/do-not-federate toggle and any other advanced post visibility/etc. features we might add. Hoodie's idea was for it to drop down from the bottom of the compose for like the visibility/privacy setting dropdown. I initially misunderstood that but was going to implement it initially that way for simplicity's sake because I didn't know how to do the thing I misunderstood that as.

(I haven't done as much work on this yet as I'd like for various distraction-related reasons.)

Steps for actually implementing this:

• Add an ellipsis button to the compose form and a dropdown below it.
• Make the Advanced Options dropdown actually drop down (my current plan is to crib stuff from the dropdown for post privacy level)
• Optionally, extract out a React component for drop downs to be used by both this and the visibility setting.
• Add a local-only toggle inside the Advanced Options dropdown.
• [Edited to add:] Pass down which toggles should be active from the ComposeForm.
• When a toot is posted with local-only toggled on, automatically end it in a 👁
• [Edited to add:] Come up with a better way of indicating whether an option is on or not in the dropdown.
• Optionally, modify the POST /api/v1/statuses endpoint to accept an additional field to mark local-only toots (in place of the eye). This would have the disadvantage of getting rid of the visible indication of a local-only toot that we currently have.
• Optionally, if we do the previous thing, modify the UI to set that when the option is enabled instead of adding an eye.

I'm hoping to get the second bit done tonight, and then the rest of the non-optional bits tomorrow night or the following day. Please do comment, anyone, if you have objections, questions, comments, or concerns about this approach. Thus far everything's just going on in my local branch. I'll push a branch once things are further along.

[DJSundog]

I think this all sounds excellent, except for the last bits:

Optionally, modify the POST /api/v1/statuses endpoint to accept an additional field to mark local-only toots (in place of the eye).

While I dig the intention, at the very least this would need to be /api/v2/statuses in order have api versioning mean anything, and I would imagine we would want to avoid forking the api except in the most dire of situations.

[ekiru]

Would it? It is a backwards-compatible change. I don't remember what guarantees, if any, the docs make about API versioning, though. But it's a fair point that we may want to avoid gratuitously modifying the API.

[marrus-sh]

If it's backwards-compatible then we don't need to switch to /api/v2, and just between you and me I've seen Masto implement non–backwards-compatible changes that still didn't bump up the API version number.

That said, if we're going to make our API have more and/or different endpoints than upstream, then we should probably provide a means for frontends to check what software they are talking to. Right now the Mastodon versioning is set in lib/mastodon/version.rb and available through the API from /api/v1/instances/, but GlitchSoc should perhaps use its own versioning scheme ? ?? ???

[wolfteeth]

I'd advise against tying anything to version numbers. Why not implement an /api/capabilities endpoint? Call the endpoint, if it doesn't exist (or the feature you want isn't listed), the client can assume it's not there.

…

On Jun 30, 2017, at 1:18 AM, Gô Shoemake ***@***.***> wrote: If it's backwards-compatible then we don't need to switch to /api/v2, and just between you and me I've seen Masto implement non–backwards-compatible changes that still didn't bump up the API version number. That said, if we're going to make our API have more and/or different endpoints than upstream, then we should probably provide a means for frontends to check what software they are talking to. Right now the Mastodon versioning is set in lib/mastodon/version.rb and available through the API from /api/v1/instances/, but GlitchSoc should perhaps use its own versioning scheme ? ?? ??? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[DJSundog]

Yeah, I can see not bumping the version number since it is non-breaking.

Still not sure we want to fork the API from upstream in any real way but I won't object any further.

[marrus-sh]

api/capabilities would be great (or we could just stick that information in api/instances) but I feel like it would require much better documentation and specification of features than Masto currently has.

Which is not to rule it out at all. But it might be more of a long-term goal.

[beatrix-bitrot]

my thoughts on this issue are as follows:

• I dig the advanced options dropdown
• I think refactoring it into its own component can/should have its own issue/PR after this one
• Let's not modify the API for now (though I'm not against it, just want to keep these tasks small), and so stick with the eye, as silly as it is

thanks everyone for your input and @ekiru for your work on this~

[ekiru]

I have a branch at https://github.com/glitch-soc/mastodon/tree/feature/local-only-toot-ui that does most of this now! The big uncertainty is how to display enabled/disabled status. The branch currently does it in a not v. good way (@beatrix-bitrot was confused by it and also it's inconsistent with the privacy dropdown) involving border colors and stuff around the options.

[ekiru]

Screencaps of a few different approaches to displaying that.

how privacy dropdown works, active and hovered are displayed the same https://surinna.me/scrtch/8069ef418f457b7b9887f58e3851ab1e53821ffbcdcc3833f827872f96926baf.png

approach with borders and stuff (currently in the branch):

• not active, not hovered https://surinna.me/scrtch/d3394e0cda5109dabe58df42e15f3f3e015c16e24a6c69ef998c06e7ce713c5b.png
• not active, hovered https://surinna.me/scrtch/6ec07c63ce516673437c39c6cc18db8a8d64e0fdc7db8d2f008ff35dc075bd12.png
• active, not hovered https://surinna.me/scrtch/fc2026700b9a4ad87a686c1a84684dc972178866a1db3bd0b9802941ca20d23a.png
• active, hovered https://surinna.me/scrtch/632896278d8f62a0fc87b582a2ad6d85be6a3cd0dc32ddbbef8b0dc8ab91990a.png

like the privacy dropdown for hovering, but with toggles for activation (in my local branch)

• not active, not hovered https://surinna.me/scrtch/91bb14e887de7bd9caf974d1b9bee24bdfc4e6e0b446968ac8f16ab9f48ccd0c.png
• not active, hovered https://surinna.me/scrtch/78cdcb59f5f5ab1f3f6ffd795dad00ead0b8b1714ecf565778f6f4bdaae03469.png
• active, not hovered https://surinna.me/scrtch/4b14c332feb88520b7b432ef2f59dd2e199c808c6c5d42c2290459bc4ebb5b89.png
• active, hovered https://surinna.me/scrtch/9b3f9debf9f67a8cbafb1d303f46b2b88d4a677f05bc3d661c2a44cbc7381ec1.png

[beatrix-bitrot]

@ekiru toggles good 👍

[nightpool]

minor, but these rounded corners are awkward:

[nightpool]

Honestly if I wanted to implement this, I would just make it a fifth privacy option. we've already got four of them....

this loses some flexibility, but I don't think it's a big deal in the long run.

[beatrix-bitrot]

@nightpool it's orthogonal to visibility tho and there's plans to further refactor the existing options

[ekiru]

oki, merging in master fixed the rounded corners (and also changed the button highlighting behavior???), and I made the advanced options button highlight whenever the option is enabled even if the dropdown is closed. I pushed all that to the branch and am about to create a PR for that branch.

[ekiru]

The PR was merged, but there's a few subordinate issues we've noticed (some code cleanliness/optimization concerns, some user-facing functionality ones) that still need to be fixed.

Some of those have issues or comments on the PR elsewhere but I'll just make a little checklist here to keep everyone apprised:

• make replies to local-only toots automatically enable local-only
• make the whole menu item toggle local-only and not just the little toggle switch
• make a special toggle component that will be more efficient for the advanced options
• rename changeComposeAdvancedOption to toggleComposeAdvancedOption
• update the character counter to take account of the 👁 so that people are less likely to be confused by errors if they try to make 499/500 char local-only toots

[ekiru]

I did all those little tweaks now. not sure if there's anything else we wanna take care of here before we close this?

[beatrix-bitrot]

There's nothing I can think of since piggo has documented the feature already. I am closing it. Nicely done!