[feature] use :local_only: emoji to mark status non-federated

[noerw]

This pull request enables marking posts as local-only by using a :local_only: emoji.
fixes #301

2 open questions:

• The API (used for the existing status create tests) does not expose the Federated flag on statuses - can you point me how to test this instead?
• The emoji needs to be added manually for this feature to work - not ideal i think, but it works. I'm not sure how to go about adding a default emoji. If you could guide me a bit, I'll implement that too. Spontaneous ideas:
  • hardcode it - where? makes customization / removal of the emoji hard
  • add it via a DB migration - a bit hacky, but enables customization, deletion, without further work
• Is the added documentation actually correct that this flag also disables sending the post to remote servers?

---

aside: In the long run, clients should have a proper GUI for setting flags like federated / boostable / ... - ie servers would expose a well specified™ interface to retrieve post options & how they map to API parameters. This will take a collaborative effort from at least 1-2 client devs, and 1-2 server projects - last i checked (6 months ago), nobody worked in that direction.
Implementing the :local_only: emoji seems like a good stopgap to enable posting things that you don't want to be sent all over the place.

[tsmethurst]

Thanks for doing this work!

Since creating that issue a couple years ago I've sort of been having some second thoughts about such stop-gap measures, since they tend to proliferate rather hacky workarounds (in this case hardcoding an emoji shortcode to have magical side effects) rather than solving the issue properly. It's v. understandable why that measure came about in the first place -- essentially, to get around official mastodon's hegemony -- but I've got some reservations about duplicating it now.

So what I'm trying to say is, I'm not 100% sure about merging this right now, especially since local-only posting currently only has the bare minimum amount of support in GtS, so we need to take a fresh pass at it anyway to make sure it all works properly before we encourage people to use it.

If we do merge this, it should come with a big warning that this is only a temporary workaround, and people shouldn't rely on it to always work, because I'd like to remove it at some point when (as you mention in your aside) we get around to trying to formalize a proper method for setting this flag that multiple server implementations can agree on.

[NyaaaWhatsUpDoc]

Yeah thank you for the input @noerw! Though I'm with @tsmethurst on this one. Hardcoding an emoji for this seems like it's going to tie us into not-ideal behaviour that we may have to support going forwards.

I'm definitely not against local-only posting, but I think there needs to be some thoughts about how we're going to do this and perhaps comms with popular client software to see how they would ideally want to consume whether a status is local-only.

[noerw]

Thanks, your concerns are totally understandable. I don't have more input for a decision if you want to merge this - I'm fine with running this patch on my own instance only.

I'd love to work on specifying an API for this & start coordination, but I'm sure that I'll overload myself with this - especially as I'm not well connected with fedi devs.

I need this feature as i'm not comfortable posting some stuff to the wider fediverse - can you clarify if Federated: false actually does what I think it does? ie. does it only apply to ACLs, or does it really stop putting the post in the non-local inboxes?

[tsmethurst]

Currently if federated = false, then the status won't be sent out to remote inboxes, indeed:

gotosocial/internal/processing/fromclientapi.go

Lines 489 to 492 in 5e2897e

	// do nothing if the status shouldn't be federated
	if !*status.Federated {
	return nil
	}

It also won't be shown in the web view of your profile, even if it's public and would normally be shown:

gotosocial/internal/db/bundb/account.go

Lines 620 to 621 in 5e2897e

	// Don't show local-only statuses on the web view.
	Where("? = ?", bun.Ident("status.federated"), true)

However, we haven't yet tested properly how airtight this is, it could be that if someone knows the URI of the status, they could still dereference it. Like I said, we still gotta do another proper pass on this and make sure it works as expected.

[tsmethurst]

Also, just wanna say thank you for being chill about the fact that we're not sure yet if we wanna merge this work or not. Oftentimes people (understandably) get peeved when they've done work with no prior indication that it won't be accepted, so it's really appreciated when folks are like 'okay no problem!' ❤️

[VyrCossont]

aside: In the long run, clients should have a proper GUI for setting flags like federated / boostable / ... - ie servers would expose a well specified™ interface to retrieve post options & how they map to API parameters. This will take a collaborative effort from at least 1-2 client devs, and 1-2 server projects - last i checked (6 months ago), nobody worked in that direction.

I have Thoughts on this so I've moved them to #1985.

[daenney]

Though the general ability is something we'd like, we're still not sure we want it in this form. So instead of having this hanging in limbo forever, I'm going to go ahead and close this for now.

Thanks again for taking the time to prepare and propose the change. Hopefully we'll get to something like this in the future, with some better all-round support for this in clients and servers.