-
-
Notifications
You must be signed in to change notification settings - Fork 975
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
Update ActivityPub documentation #1183
Conversation
Added more details in several places
@trwnh is attempting to deploy a commit to the Mastodon Team on Vercel. A member of the Team first needs to authorize it. |
|
||
Mastodon generates colorful preview thumbnails for attachments. This is implemented using an extra property `blurhash` on `Image` objects. The property is a string generated by the [BlurHash algorithm](https://blurha.sh). Example: | ||
Mastodon allows users to opt-in or opt-out of discoverability features like the profile directory. This flag may also be used as an indicator of the user's preferences toward being included in external discovery services, such as search engines or other indexing tools. If you are implementing such a tool, it is recommended that you respect this property if it is present. This is implemented using an extra property `discoverable` on objects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit uneasy with the mention of search engines and such, as the scope of this setting was historically just for the profile directory, and is vaguely-defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the description here is unchanged since 2019, i just moved it up from lower in the page (red line 521 in this changeset).
aside from that, it is worth noting that the current definition also says it is applied on "objects" without specifying that mastodon only applies it on actors. the wording is indeed vague, but i believe the original mention of "search engines and indexing tools" was just a generalization of the profile directory (which is an "internal" discovery service). you could envision a "search for profiles" service that would let you find discoverable accounts in a way similar to the profile directory, but with more details like including their bio and featured hashtags. but it doesn't really make sense to define this property only for actors even if it only gets used on actors.
the real contention to me is in whether this account-level preference carries over to posts. i think it generally does not, and therefore i avoided saying this (although i can see how it is still vague). relatedly, this is why i think discoverable
should be attached to posts as well: to remove that kind of ambiguity. if we attach discoverable
at the post level, you no longer need to check the account property. regardless, we might still (may or may not) consider a policy of deferring to the account property if the post doesn't declare whether it is discoverable
. this basically creates the following states:
- if the post is
discoverable: true
, it SHOULD be shown in discovery features - if the post is
discoverable: false
, it MUST NOT be shown in discovery features - if the post is
discoverable: null
or the property is missing:- if the account is
discoverable: true
, the post MAY be shown in discovery features - if the account is
discoverable: false
, the post SHOULD NOT be shown in discovery features - if the account is
discoverable: null
or the property is missing, the post MAY be shown in discovery features if some other mechanism establishes consent, but SHOULD NOT be shown in lieu of any other mechanism
- if the account is
@ClearlyClaire addressed everything except for the bit about
|
Added more details in several places.
Preview: https://activitypub--mastodocs.netlify.app/spec/activitypub/