per activitypub: ActivityPub
Activities may additionally be addressed to the special “public” collection, with the identifier
https://www.w3.org/ns/activitystreams#Public[…] Activities addressed to this special URI shall be accessible to all users, without authentication.
in other words, Public is public. even so, softwares such as mastodon and pleroma have features like AUTHORIZED_FETCH to require authorization as an actor, using a valid http signature on the GET request, or else the GET will fail. i don’t think this is something you can enforce network-wide unless you proposed another pseudo-scope other than Public, which has also been done before in as:Authenticated proposal · Issue #339 · w3c/activitypub · GitHub and similar discussions. the problem, of course, is that creating your own activitypub actor and keypair to perform http signatures is not actually a significant barrier to scraping, unless you also implement an allow-list on who can fetch. a deny-list alone will not be sufficient, as objects and resources may be fetched on behalf of some other unknown actor via a “trusted” actor.
alternatively, you can use audience to refer to some (pseudo-)collection and rely on inbox forwarding (assuming support for both the audience property and for inbox forwarding). such posts will probably appear to be “private” on remote sites; this would be fine if you didn’t care to have remote sites understand additional semantics beyond the explicitly delivered-to actors as Public implies, or as a hypothetical Authenticated collection might imply, or even as the followers collection implies in current fediverse interpretations – these are considered “magic collections” for the purposes of federation, and current implementations are expected to “know” who is following without being explicitly told who is following. (personally i think such “magic collections” are a big mistake, but that’s a different discussion.)
it’s important to consider that the vast majority of documents are actually delivered and not fetched – if you want to stop people from doing things you don’t want with them, then you need to vet your followers and not just impose access controls on fetch.
insofar as these conditions are made known and are understood ahead-of-time, then… maybe? i doubt an “i agree to the terms and conditions” for machine parsers would be particularly useful, but some indication of what you expect might help. consider a hypothetical “origin only” flag or scope that indicates that the author doesn’t want their posts to be redistributed. in such cases, perhaps you could respect that flag by not rendering their posts in threaded contexts. the post would instead be shown only as a link or URL (which must be fetched or loaded like a web page). but to extend this to an entire framework of expectations and behaviors, it would be necessary to first define those expectations and behaviors.