@supakaity @ada
> In terms of inbound federated AP objects which do not support these new fields, we will try to infer the intent based off existing AP fields and other metadata when present.
> Specifically, we will be using the Mastodon Account Lookup API (GET /api/v1/accounts/lookup?acct=) to get and store the noindex flag during actor creation/refresh. This will also allow us to put the noindex meta tag on any HTML pages containing that actor’s posts.
I guess if the default is not to index. If either an Instance dont use Mastodon or does not implement those flags, one should assume that the user dont want to be indexed. If its intended like this, then im happy.

I dont have an opinion about the Searchability rn but i do have one about Interactivity:
> The other problem is that at the moment you can’t control who can reply, boost, vote and/or react to your posts.
If you look at the protocol rn, it doesnt make sense to have something like this in the protocol. The current "Interactivity" is built upon the bounds of the protocol... For example the visibility:
Public: anyone can fetch the post
Follower Only: only servers with followers on it can fetch the post
DM: only servers with mentioned accounts can fetch the post
Local: the post isnt federated

The only (quite weird) exception here is unlisted: it will get pushed to followers but not to relays and the post wont be shown in lists... That one actually surprises me that it got implemented on a relative wide range tho...

So back to the Topic: Imho is a flag to constraint the replys and Interactions a very bad thing tho. You cant be sure that the receiving server does use the flag correctly or even implement the functionality in the first place. Either that can be intentionally (There were servers which rewrote posts from DMs to Public) or it can be unintentionally like Wildebeest did it or that they just didnt implement it yet. So therefore you need to assume that servers ignore those flags and you need to check those constraints on the local server... In such a case it would lead to a toxic system, like all could fetch a post but the creator wont see all messages... It would lead to way more broken threads than today already exists... And if we talk about beeing in control of the own posts, how do you plan to constraint replys of a thread? Beside of that, how do you wana explain the downside of such things to a user which has no idea how federation works?
I hope i could show you why i dont like the Idea of these Proposals... I would prefer to have the protocol as a boundary and not some flags.

I dont feel like talk about Licensing rn but let me add a few words to Crawlability:
The same issue with the flags above does also exist within the Crawlability and the Searcheability (mentioned as first Topic)... If you look it the way like Security Peoples does, you need to assume that every public Post will be crawled at some point. It can be a Hint/Flag for a Publicly available Fedi Search Engine and Users could be in control what actually is indexed by them... But dont forget that you need to assume that fedi is crawled and that such Flags also can lead to false assumptions.

So, now to the last thing: Quotability
I guess i do have a kinda strange View on this Topic: Quotability is a UI Feature. You cant control that people take Screenshots or Post links to other Posts. A good UI just resolves the link to a different Post and shows the original Post like they generate a Preview of any other link to any other Webresource...
If you look at it from this perspective, it is incredibly naive to think that such a flag will ever catch on in the whole network.

All in all, such flags could work on a limited reach tho: Take mastodon.social as an example... If there is a big server and users dont communicate with the rest of the network, such Features and (other Features like Closing Threads and other stuff what Gargron wants to implement) they could be used to moderate and control things but only limited to the local server. I would even consider that realistic, but not for the whole network.